| Time |
Nick |
Message |
| 00:09 |
|
DFeniks joined #minetest-dev |
| 00:18 |
|
yang2003 joined #minetest-dev |
| 00:22 |
|
Tmanyo joined #minetest-dev |
| 00:26 |
hmmmm |
paramat PTAL https://github.com/kwolekr/minetest/commit/46d46a0535189a9e7468b89bddf101d2b79e409c |
| 00:30 |
|
Tmanyo joined #minetest-dev |
| 01:17 |
|
Void7 joined #minetest-dev |
| 01:36 |
|
Miner_48er joined #minetest-dev |
| 02:13 |
|
gregorycu joined #minetest-dev |
| 02:15 |
|
Zeitgeist_ joined #minetest-dev |
| 02:53 |
|
Void7 joined #minetest-dev |
| 03:01 |
|
gregorycu_ joined #minetest-dev |
| 03:01 |
|
gregorycu joined #minetest-dev |
| 03:07 |
|
Sokomine joined #minetest-dev |
| 03:51 |
|
nore joined #minetest-dev |
| 04:36 |
|
eriix joined #minetest-dev |
| 05:06 |
|
Puka joined #minetest-dev |
| 05:43 |
eriix |
I've been writing an LMDB backend for Minetest, and I was wondering if anyone would have any interest in this. It presently works very well for my needs, but I've only tested on AMD64 Linux. |
| 05:46 |
|
Megal_ joined #minetest-dev |
| 06:36 |
|
JBB joined #minetest-dev |
| 06:56 |
|
nrzkt joined #minetest-dev |
| 07:09 |
|
Hunterz joined #minetest-dev |
| 08:06 |
|
Icedream joined #minetest-dev |
| 08:41 |
|
Krock joined #minetest-dev |
| 09:18 |
Calinou |
LMDB? |
| 09:23 |
kahrl |
it's the storage backend that openldap uses by default (I think) since recently |
| 09:24 |
kahrl |
previously it was bdb |
| 09:27 |
celeron55 |
why are there infinite databases and why does someone want to use each and all of them with a _game_? |
| 09:28 |
kahrl |
databases are well-studied in academia |
| 09:28 |
kahrl |
perhaps writing a database is a popular subject for final-year projects and theses |
| 09:31 |
kahrl |
but yeah, the question about using it for a game still stands :P |
| 09:33 |
kahrl |
what I would like to see is a ldap-based authentication handler for minetest |
| 09:33 |
kahrl |
should be pretty useful for corporate minetest servers |
| 10:29 |
|
paramat joined #minetest-dev |
| 10:30 |
paramat |
hmmmm code looks good |
| 10:45 |
|
gregorycu joined #minetest-dev |
| 10:47 |
paramat |
please any reviews for #4163 ? |
| 10:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/4163 -- Sky: Darker, bluer sky and improved horizon haze at night by paramat |
| 10:51 |
|
jomat joined #minetest-dev |
| 10:52 |
|
ElectronLibre_ joined #minetest-dev |
| 10:54 |
|
Calinou joined #minetest-dev |
| 10:55 |
|
Fixer joined #minetest-dev |
| 10:55 |
|
johnnyjoy joined #minetest-dev |
| 11:00 |
|
BrandonReese joined #minetest-dev |
| 11:01 |
|
pozzoni joined #minetest-dev |
| 11:08 |
paramat |
^ kahrl nore sfan5 |
| 11:14 |
kahrl |
paramat: weird, on my monitor it looks like the PR makes the midnight sky lighter, not darker |
| 11:17 |
paramat |
it's a little darker, but certainly bluer. you will need a darkened room to judge those screenshots |
| 11:18 |
kahrl |
true. It's noon here so it's a bit difficult |
| 11:19 |
|
eeew joined #minetest-dev |
| 11:21 |
celeron55 |
the dark end gamma of monitors tends to be literally completely all over the place |
| 11:21 |
celeron55 |
it would be better to visualize night by making things monochrome or something instead of very dark |
| 11:25 |
paramat |
my night sky here is monochrome, it's maximum saturation blue, and it's fairly light to look like atmosphere lit by full moon |
| 11:35 |
paramat |
but of course the horizon differs. i find the horizon needs a little haze to look right, just as in daytime |
| 11:48 |
|
troller joined #minetest-dev |
| 11:51 |
celeron55 |
the horizon is supposed to have roughly the same color as the clouds in order to fit the clouds on the sky to begin with |
| 11:52 |
celeron55 |
when there are no clouds, it doesn't need the hazy color, but generally there are |
| 11:56 |
|
Wayward_One joined #minetest-dev |
| 12:00 |
|
damiel joined #minetest-dev |
| 12:06 |
paramat |
yes. i discovered that day horizon has the same hue as day sky, just less saturation so lighter. so i did the same for night horizon |
| 12:46 |
|
jin_xi joined #minetest-dev |
| 12:48 |
|
rubenwardy joined #minetest-dev |
| 13:08 |
|
Thomas-S joined #minetest-dev |
| 13:14 |
|
edgrey joined #minetest-dev |
| 13:31 |
|
Player_2 joined #minetest-dev |
| 13:33 |
|
jomat joined #minetest-dev |
| 14:09 |
|
paramat joined #minetest-dev |
| 14:39 |
|
est31 joined #minetest-dev |
| 14:56 |
|
JBB joined #minetest-dev |
| 15:05 |
|
hmmmm joined #minetest-dev |
| 15:09 |
paramat |
will merge #4185 in a moment |
| 15:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/4185 -- Biomes: Add biome-definable riverbed material and depth by paramat |
| 15:10 |
hmmmm |
aah hold on |
| 15:10 |
hmmmm |
you realize that PRs need to be re-reviewed when a change is suggested and a revision is supposedly made, right? |
| 15:12 |
paramat |
ah ok, docs updated |
| 15:12 |
hmmmm |
the message I wanted to get across with the documentation update isn't quite there |
| 15:13 |
hmmmm |
you're saying specific things about specific fields and giving specific details about future plans in a documentation piece on an interface |
| 15:14 |
hmmmm |
just say that the whole biome API is still unstable and subject to change |
| 15:14 |
hmmmm |
it's also possible for rivers to not become biomes |
| 15:14 |
hmmmm |
who knows? |
| 15:14 |
paramat |
ok. no logs for mapgen channel, that's what i remembered |
| 15:15 |
hmmmm |
don't you have IRC client logs? |
| 15:15 |
paramat |
erm maybe |
| 15:15 |
hmmmm |
alright despite the mapgen channel being decent in terms of filtering out interruptions and keeping the discussion focused, maybe it's not the best because of the whole logging issue |
| 15:17 |
paramat |
indeed. and no i don't have any client history |
| 15:18 |
hmmmm |
https://paste.fedoraproject.org/374861/51398981/ |
| 15:19 |
paramat |
ok i remembered wrong |
| 15:19 |
paramat |
thanks |
| 15:20 |
paramat |
+1 for your commit (but untested). it might conflict with 4185 |
| 15:20 |
|
Puka joined #minetest-dev |
| 15:21 |
hmmmm |
why don't you commit yours first and then i'll commit mine |
| 15:21 |
hmmmm |
i can probably handle merge conflicts a little bit better |
| 15:23 |
paramat |
ok. my PR is bigger too |
| 15:32 |
paramat |
updated |
| 15:35 |
paramat |
merging |
| 15:35 |
hmmmm |
and IS subject to change |
| 15:35 |
hmmmm |
[11:10 AM] <hmmmm> you realize that PRs need to be re-reviewed when a change is suggested and a revision is supposedly made, right? |
| 15:35 |
hmmmm |
Biome should be capitalized in that sentence |
| 15:35 |
est31 |
hmmmm, you are sorta right with that sorta not |
| 15:36 |
est31 |
I mean if you ask sb to add a . to the end of some documentation sentencee |
| 15:36 |
est31 |
and they update their 1000 line PR |
| 15:36 |
est31 |
then you dont have to go through the whole 1000 lines |
| 15:36 |
est31 |
nor do you need to wait for an "okay, you placed the dot well" |
| 15:37 |
est31 |
it is different when the requirements are more opaque |
| 15:37 |
hmmmm |
no, you're supposed to review the difference between revisions |
| 15:37 |
est31 |
like "it needs to be faster" |
| 15:38 |
hmmmm |
how do you know that somebody hasn't slipped in an execl("rm", "-rf", "/");? |
| 15:39 |
est31 |
I build on trust |
| 15:39 |
hmmmm |
ideally, all code should reviewed at all times before being merged |
| 15:39 |
est31 |
If I see that some people indeed have such behaviour |
| 15:39 |
hmmmm |
and tested |
| 15:39 |
est31 |
then I re-review the whole thing again |
| 15:39 |
est31 |
hmmmm, the problem is just about time |
| 15:40 |
est31 |
also, hmmmm do you do this yourself when reviewing PRS |
| 15:40 |
hmmmm |
yes |
| 15:40 |
est31 |
do you download each revision of a PR then check the diff |
| 15:40 |
est31 |
and do you check it also when its rebased |
| 15:40 |
hmmmm |
i don't download each revision, no, but i do look at the things that have been changed |
| 15:41 |
hmmmm |
our current setup makes reviewing each exact diff more difficult |
| 15:41 |
hmmmm |
fwiw there's a Gerrit plugin for this |
| 15:41 |
est31 |
hmmmm, how do you know which things have been changed if you don't download each revision |
| 15:41 |
est31 |
github doesnt support looking at the diff between different pr revisions |
| 15:42 |
hmmmm |
so wouldn't the better question be, "how can we make github support this type of feature" |
| 15:42 |
hmmmm |
or "how could we add this functionality on" |
| 15:44 |
paramat |
the 'is' is earier in the sentence, and i don't think biome should be capitalised |
| 15:44 |
hmmmm |
why not? |
| 15:44 |
paramat |
'is X and Y' |
| 15:45 |
hmmmm |
yeah i saw that when i re-looked at it but what about the capitalization thing |
| 15:45 |
paramat |
well it could be considered a name Biome API, or just a biome API |
| 15:46 |
paramat |
i'm already about to merge so can fix it later, it's not a big error |
| 15:49 |
hmmmm |
when would later be? |
| 15:49 |
paramat |
merged, wow down to 125 PRs |
| 15:50 |
paramat |
after now :] |
| 15:54 |
paramat |
maybe i'll do a cleanup of lua_api, it needs it |
| 15:54 |
hmmmm |
i don't get why you'd agree that something is wrong, and then merge it anyway, and decide to fix it after |
| 15:55 |
est31 |
in some times that way of doing things is a good idea |
| 15:55 |
est31 |
but it is a very very bad idea if it affects compatibility in any way |
| 15:56 |
est31 |
so if you have to fix it you need to break compatibility |
| 15:56 |
paramat |
i'll do a cleanup later today then, as my punishment |
| 15:57 |
paramat |
i considered the capitalisation debatable |
| 15:57 |
paramat |
either is ok, but i'll change it to make it more of a 'name' |
| 15:58 |
hmmmm |
i never thought of it that way, about the name vs. generic thing argument, but capitalized titles for things like that are absolutely standard in technical documentation |
| 15:59 |
paramat |
yeah it's probably a little better |
| 16:00 |
paramat |
also i had gone through the whole merging process again and wasn't going to let a debatable single letter stop me :] |
| 16:01 |
hmmmm |
at where i work to make a commit you need to 'git push review <branch>' |
| 16:01 |
hmmmm |
this runs a hook and it does some kind of special magic that i'm not totally sure on |
| 16:01 |
hmmmm |
but it shows up as a new revision in your equivalent to the PR page |
| 16:01 |
hmmmm |
when a new revision is made, it loses all prior approval |
| 16:01 |
hmmmm |
code review, unit tests passing, etc. |
| 16:02 |
hmmmm |
so every single time you fix one god damn letter or add a period or something, EVERYTHING needs to be done again |
| 16:02 |
hmmmm |
you need to go around to all the same people and beg them to re-add their review +1s |
| 16:02 |
est31 |
and this is super annoying to everybody |
| 16:02 |
hmmmm |
and then you need to run buildbot and have it re-create the entire running environment from scratch |
| 16:02 |
hmmmm |
and then compile a massive piece of software |
| 16:02 |
|
STHGOM joined #minetest-dev |
| 16:03 |
hmmmm |
and then run ALL of the unit tests for ALL pieces of software on literally 15 different versions of Windows |
| 16:03 |
hmmmm |
the whole process takes about 3 hours and 30 minutes |
| 16:03 |
est31 |
hmmmm, this is a stupid GAME not a business software where a failure will cost millions of dollars |
| 16:03 |
hmmmm |
now, there's a reason to ignore a minor change |
| 16:03 |
|
Void7 joined #minetest-dev |
| 16:04 |
hmmmm |
oh |
| 16:04 |
est31 |
ah |
| 16:04 |
est31 |
you only talk about work |
| 16:04 |
hmmmm |
and in the case that somebody else committed another PR in between the time it took for your PR to get re-reviewed and unit tested |
| 16:04 |
est31 |
sorry didnt read that |
| 16:04 |
hmmmm |
you need to manually rebase it and then you lose all approval AGAIN |
| 16:04 |
hmmmm |
so you need to go through this entire process before anybody else touches the repository |
| 16:05 |
hmmmm |
i've never wanted to physically harm anything in my life until i had been introduced to this setup |
| 16:05 |
paramat |
oh man |
| 16:05 |
hmmmm |
and then the same people who set this up are telling us that our project moves too slow |
| 16:06 |
paramat |
heh |
| 16:06 |
est31 |
:) |
| 16:06 |
hmmmm |
wanna kill something |
| 16:06 |
hmmmm |
oh and you better make sure you have a JIRA issue created for whatever change it is you're making in the appropriate format |
| 16:07 |
hmmmm |
because in order to commit you need to have the JIRA number included in the commit message |
| 16:07 |
hmmmm |
and this JIRA needs to have been approved by the business analyst, and it needs to have been put into the current sprint |
| 16:07 |
hmmmm |
in order to get a specific JIRA story into the sprint you need approval from the manager and scrum master |
| 16:08 |
|
Lunatrius joined #minetest-dev |
| 16:13 |
Calinou |
<est31> hmmmm, this is a stupid GAME not a business software where a failure will cost millions of dollars |
| 16:13 |
Calinou |
and we should keep legacy protocol support? :P |
| 16:14 |
Calinou |
in the non-free world, almost all online games ship with an updater... |
| 16:14 |
hmmmm |
can you devise a reason why legacy protocol support should be dropped? |
| 16:14 |
Calinou |
it's less work, less code (shorter compile times/smaller binaries) |
| 16:14 |
Calinou |
and we can iterate faster |
| 16:14 |
hmmmm |
but there's no reason why compatibility actually requires being broken |
| 16:14 |
est31 |
LESS WORK: --> it requires work to remove compat |
| 16:14 |
Calinou |
if you didn't understand it already, games in Linux distribution repositories are intended as showcases, not to be usable |
| 16:14 |
hmmmm |
nobody is making any changes that affect compatibility |
| 16:15 |
Calinou |
(even in rolling-release distros, this can be a problem) |
| 16:15 |
est31 |
SHORTER COMPILE TIMES/SMALLER BINARIES: if you take away *one* texture from minetest, you essentially have the same size advantage |
| 16:15 |
est31 |
or make it 10 textures |
| 16:16 |
|
edgrey joined #minetest-dev |
| 16:17 |
Calinou |
textures don't affect compile times :P |
| 16:17 |
est31 |
thats true |
| 16:18 |
hmmmm |
here it's worth repeating |
| 16:18 |
hmmmm |
Jun 04 17:25:43 <hmmmm> the way i change things doesn't necessarily break everything else |
| 16:18 |
hmmmm |
Jun 04 17:25:55 <hmmmm> for some reason it seems like people assume or even want compatibility to be broken between changes |
| 16:18 |
hmmmm |
Jun 04 17:26:10 <hmmmm> there is no correlation between the significance of changes and reverse compatibility |
| 16:18 |
hmmmm |
Jun 04 17:26:58 <hmmmm> people are like cheering on changes that break compatibility for the network because they think that must mean there is a big change and a big change is always for the better, right? |
| 16:18 |
hmmmm |
Jun 04 17:27:25 <hmmmm> and breaking compatibility does not make you more progressive and open to new ideas |
| 16:18 |
est31 |
I rather have somebody spend more time on a format that's solid because once its there its hard to remove, than somebody spend less time on multiple bad formats but "iterating faster" |
| 16:19 |
est31 |
with the excuse "we can re-design it whenever we want to" |
| 16:19 |
est31 |
<Calinou> if you didn't understand it already, games in Linux distribution repositories are intended as showcases, not to be usable |
| 16:19 |
est31 |
I agree this is a problem |
| 16:20 |
est31 |
but even then its the choice of the distros to do it |
| 16:20 |
est31 |
we are an open source project, any distro may take our game and put it in their archives |
| 16:25 |
xunto |
haven't reached 1.0.0 yet @ is caring about compatibility |
| 16:25 |
xunto |
funny) |
| 16:27 |
est31 |
semver is just some stupid file on the internet |
| 16:27 |
est31 |
what matters is if people use the thing |
| 16:27 |
|
amadin joined #minetest-dev |
| 16:32 |
paramat |
mtgame devs, nore sfan5 game#1124 needed soon so might merge later |
| 16:32 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1124 -- Mapgen: Add biome fields for riverbed node and depth by paramat |
| 16:50 |
celeron55 |
xunto: current minetest can generally load worlds that were created like less than half a year after the beginning of the entire project, and we are proud of it |
| 16:51 |
hmmmm |
but the thing is, this discussion is STUPID because there is simply no actual requirement for compatibility to be broken in order to further develop minetest |
| 16:51 |
hmmmm |
there is no superior thing that can't be done without breaking things from the past |
| 16:52 |
hmmmm |
there is an implicit suggestion that breaking compatibility will enhance minetest in some way |
| 16:52 |
hmmmm |
this is totally wrong |
| 16:56 |
celeron55 |
i almost would like to force minetest to start using major version 100 or something so that these trolls couldn't say "haven't reached 1.0.0" |
| 16:57 |
xunto |
>these trolls |
| 16:57 |
xunto |
Sorry) |
| 16:58 |
sfan5 |
paramat: i have no idea about mapgen so that pull looks fine to me |
| 16:58 |
xunto |
It was accidential trolling |
| 16:59 |
celeron55 |
well i don't actually care; it's just a thing you get really bored of and that stops becoming funny at all |
| 17:00 |
celeron55 |
s/becoming/being/ |
| 17:00 |
celeron55 |
make better jokes |
| 17:00 |
xunto |
Next time |
| 17:00 |
est31 |
<hmmmm> but the thing is, this discussion is STUPID because there is simply no actual requirement for compatibility to be broken in order to further develop minetest |
| 17:00 |
celeron55 |
that's a promise, then! |
| 17:00 |
est31 |
+1 to that |
| 17:02 |
celeron55 |
that hmmmm's work PR thing sounds absolutely ridiculous though; it wouldn't take long for me to either change it or show myself the door |
| 17:02 |
hmmmm |
?? |
| 17:02 |
rubenwardy |
<hmmmm> and then run ALL of the unit tests for ALL pieces of software on literally 15 different versions of Windows |
| 17:03 |
hmmmm |
ohh |
| 17:03 |
|
Zeitgeist_ joined #minetest-dev |
| 17:03 |
hmmmm |
i forgot i was talking about that even |
| 17:03 |
est31 |
shrug if its automated why not |
| 17:03 |
sfan5 |
<hmmmm> the whole process takes about 3 hours and 30 minutes |
| 17:03 |
sfan5 |
"why not" |
| 17:04 |
est31 |
oh |
| 17:04 |
paramat |
ok |
| 17:04 |
hmmmm |
celeron, I stick around because i enjoy the subject matter of what i work on and it's a total work-at-home thing, aside from having to go on week-long business trips a few times a year |
| 17:04 |
hmmmm |
the bureaucracy is overwhelming though and i don't feel bad about not being very productive either |
| 17:05 |
hmmmm |
i have less say on that project than literally any project i've worked on in the past... |
| 17:05 |
celeron55 |
i always feel bad about not being productive, no matter the cause, and consider it to be a benefit |
| 17:08 |
hmmmm |
it's a benefit when the productivity is for yourself; not so a faceless, soulless corporation can make an extra buck off of your toil |
| 17:08 |
celeron55 |
i don't work for faceless, soulless corporations |
| 17:08 |
hmmmm |
i need to in order to buy food to live |
| 17:09 |
hmmmm |
fwiw I have plans to retire in 10 years |
| 17:09 |
hmmmm |
not going to live my entire life working |
| 17:10 |
Krock |
work work work until you DIE with hopeless and totally DESTROYED </dramatical sound> |
| 17:10 |
celeron55 |
i work for companies that appreciate me ensuing my own productivity; managed to find one just lately |
| 17:12 |
celeron55 |
it's actually not that great to not have any work at all either |
| 17:13 |
hmmmm |
depending on how i feel i could consider minetest work |
| 17:18 |
|
nnnn20430 joined #minetest-dev |
| 17:19 |
|
rubenwardy joined #minetest-dev |
| 17:30 |
|
nrzkt joined #minetest-dev |
| 17:32 |
hmmmm |
paramat: i was planning a bit more about the mapgen config change |
| 17:33 |
hmmmm |
starting to wonder a bit if it's really a good idea or not from an interface point-of-view |
| 17:34 |
hmmmm |
first i need to define all of the mapgen defaults in defaultsettings.cpp |
| 17:34 |
hmmmm |
lots of work... eww |
| 17:34 |
paramat |
work on other stuff for now then? |
| 17:34 |
hmmmm |
then i need to add some new Settings methods to copy some settings that match a certain prefix or pattern to a new Settings object, namely ones that begin with mg_ |
| 17:35 |
hmmmm |
at this point we have a Settings that is a copy of g_settings that has nothing but settings that start with mg_, plus seed/blocksize/water_level/etc. |
| 17:35 |
hmmmm |
now map_meta.txt gets loaded into a new Settings object |
| 17:36 |
hmmmm |
then i write a new method that merges one Settings into another, overwriting pre-existing entries |
| 17:36 |
hmmmm |
i also am required to maintain a list of settings that were present in the map_meta.txt when it was loaded |
| 17:36 |
hmmmm |
at this point i pass off the Settings to lua to get modified |
| 17:37 |
hmmmm |
you'll have a minetest.set_mapgen_setting("mg_caves_rarity", "some_val_here", true); for example |
| 17:37 |
hmmmm |
it's like setting a regular parameter except it has a third bool parameter, to override the map_meta.txt settings or not |
| 17:38 |
hmmmm |
if false, which is the default, it'll first check to see if the setting being set is present in the list of setting names we loaded from map_meta.txt |
| 17:38 |
hmmmm |
if so then it does nothing |
| 17:38 |
hmmmm |
if it is not present then it overwrites the setting |
| 17:38 |
hmmmm |
if overwrite = true then it'll just overwrite the setting regardless of whether or not it's one of the settings that had been loaded from map_meta.txt |
| 17:39 |
hmmmm |
so now at this point we have a Settings object that has defaults from defaultsettings.cpp, loaded from the main config file, overrides from map_meta.txt loaded, and modifications from lua done |
| 17:39 |
hmmmm |
the Settings object gets passed along to the mapgens/cavegens/dungeongens/biomegens/whatever |
| 17:39 |
hmmmm |
and in the mapgen you just do |
| 17:40 |
hmmmm |
mgsettings->getFloat("mg_cave_rarity"); |
| 17:40 |
hmmmm |
ya dig? |
| 17:41 |
paramat |
i follow |
| 17:41 |
hmmmm |
now we can blow up all the existing "set or get a specific mapgen parameter" lua apis, blow up all the MapgenParams/DungeonParams/CaveParams/BiomeParams structs, and their associated factory methods |
| 17:41 |
hmmmm |
blow up a significant portion of EmergeManager code |
| 17:41 |
hmmmm |
lots of code removed |
| 17:42 |
paramat |
it still sounds good to me |
| 17:43 |
hmmmm |
in order to utilize any of these interfaces, though, it'll require a dependency on Settings |
| 17:43 |
hmmmm |
i wonder if that's a moot point or not, seeing as how deeply entrenched the mapgen code is on the rest of minetest already |
| 17:46 |
hmmmm |
in a perfect world i'd be able to take mapgen_v7.cpp and drop it into another project along with noise.cpp/h and have it work |
| 17:46 |
hmmmm |
:/ |
| 17:47 |
|
Megal joined #minetest-dev |
| 17:55 |
paramat |
seems moot to me |
| 17:57 |
|
Void7 joined #minetest-dev |
| 18:00 |
Fixer |
OldCoder will bring tsundere.fi world up some day :} |
| 18:13 |
OldCoder |
Not long Fixer |
| 18:13 |
OldCoder |
Not someday; hopefully, this month |
| 18:13 |
|
edgrey joined #minetest-dev |
| 18:14 |
paramat |
merging game#1124 |
| 18:14 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1124 -- Mapgen: Add biome fields for riverbed node and depth by paramat |
| 18:16 |
|
edgrey joined #minetest-dev |
| 18:18 |
paramat |
merged |
| 18:20 |
paramat |
wow i'm at 300 commits total now |
| 18:23 |
paramat |
Calinou https://github.com/minetest/minetest/issues/826#issuecomment-223819746 |
| 18:23 |
Calinou |
maybe it's not there anymore |
| 18:23 |
Calinou |
"In third person mode there's a very short and very small 'jump' of the player model when flying up from touching the ground. I suggest a close." |
| 18:23 |
Calinou |
yeah that might be it |
| 18:23 |
Fixer |
Calinou: i don't get that issue |
| 18:23 |
Fixer |
Calinou: what stairs? |
| 18:24 |
Calinou |
there's a thing in Minetest called stair smoothing |
| 18:24 |
Calinou |
at least in the past, it was enabled even while flying |
| 18:24 |
Calinou |
which introduced a slight (but noticeable) delay when flying upwards |
| 18:24 |
paramat |
est31 shall we close that then? |
| 18:24 |
Calinou |
feel free to close it anyway |
| 18:24 |
paramat |
ok |
| 18:24 |
Fixer |
i have no delay |
| 18:25 |
paramat |
it's certainly hugely improved since my first comment there |
| 18:25 |
Fixer |
it just goes up |
| 18:25 |
Calinou |
Fixer: is there a delay when flying up, compared to flying downwards? |
| 18:25 |
Calinou |
if there is, it's that bug |
| 18:26 |
Fixer |
nope |
| 18:26 |
Fixer |
i'm using PR3810 though |
| 18:26 |
paramat |
closed |
| 18:26 |
paramat |
i tested on master |
| 18:30 |
Calinou |
thanks :p |
| 18:57 |
|
Amaz joined #minetest-dev |
| 19:05 |
|
Fixer joined #minetest-dev |
| 19:06 |
|
Void7 joined #minetest-dev |
| 19:15 |
|
blaze joined #minetest-dev |
| 19:16 |
|
decodp-pc joined #minetest-dev |
| 19:17 |
|
MillersMan joined #minetest-dev |
| 19:18 |
|
Tmanyo joined #minetest-dev |
| 19:19 |
|
damiel joined #minetest-dev |
| 19:21 |
|
Void7 joined #minetest-dev |
| 19:22 |
|
decodp-pc left #minetest-dev |
| 19:49 |
Fixer |
https://github.com/minetest/minetest/issues/4151 now has backtrace and verbose debug.txt |
| 19:53 |
hmmmm |
what are those backtraces of? |
| 19:53 |
est31 |
of a stall on the xanadu server |
| 19:53 |
est31 |
essentially the server didnt respond and he did ctrl-c |
| 19:53 |
est31 |
then did a backtrace |
| 19:54 |
est31 |
so the backtrace *may* include the cause for the stall |
| 19:54 |
est31 |
or it may not |
| 19:54 |
est31 |
no way to tell from a simple backtrace |
| 19:54 |
hmmmm |
it's the server that freezes, not the client? |
| 19:54 |
est31 |
yes the server |
| 19:54 |
hmmmm |
okay |
| 19:55 |
hmmmm |
and gdb.txt and gdb_DEbug_3.txt are two different backtraces from this happening two different times? |
| 19:55 |
est31 |
idk |
| 19:55 |
hmmmm |
@ Fixer |
| 19:55 |
est31 |
maybe one is terminal backlog |
| 19:55 |
hmmmm |
help us fix this |
| 19:55 |
est31 |
and the other one is the .log file |
| 19:55 |
est31 |
hmmmm, I've looked at the backtrace |
| 19:55 |
est31 |
it seems to be inside craft recipe getting |
| 19:56 |
Fixer |
hmmmm: sorry, thats backtrace originally posted by tenplus1 from his server that has this elusive server stall problem |
| 19:56 |
est31 |
and I've been told that the position where the ABM runs on is a furnace |
| 19:56 |
hmmmm |
which one |
| 19:56 |
hmmmm |
gdb_DEbug_3.txt or gdb.txt? |
| 19:56 |
est31 |
gdb_DEbug_3.txt |
| 19:56 |
Fixer |
they are the same it seems |
| 19:56 |
est31 |
only looked at that one |
| 19:56 |
est31 |
you will see an ABM being invoked |
| 19:56 |
hmmmm |
they seem to be exactly the same |
| 19:57 |
est31 |
p = {X = 324, Y = 27, Z = -1994} |
| 19:57 |
est31 |
this is where a furnace is according to TenPlus1 |
| 19:57 |
Fixer |
yes, they are the same, one file copied by hand, another made with gdb, they look the same, he attached both to be sure |
| 19:57 |
est31 |
according to him he used mtgame code with the latest version with ABMs |
| 19:58 |
est31 |
(mtgame has been changed to use nodetimers for furnaces since) |
| 19:58 |
est31 |
so I've asked him to disable the furnace abm |
| 19:58 |
est31 |
and it seemed to have worked for him |
| 19:58 |
est31 |
no more stall |
| 19:58 |
Fixer |
est31: we need to wait, it can stall later |
| 19:58 |
est31 |
hmmmm, the stall is reproducible if you go to certain areas on the server. |
| 19:59 |
est31 |
I've tried to download the map via local map saving and installing the mods, but it didnt stall for me |
| 19:59 |
est31 |
most likely because I didnt have the mtgame tenplus1 had |
| 19:59 |
hmmmm |
perhaps not |
| 19:59 |
est31 |
so there is the chance it is an engine problem, it may be a mod problem as well |
| 19:59 |
hmmmm |
that being said, does the problem go away if a newer mtagme is installed? |
| 20:00 |
est31 |
apparently yes |
| 20:00 |
hmmmm |
to be honest this sounds like a bad mod |
| 20:00 |
nore |
est31: have you tried to move items in the furnace locally? |
| 20:00 |
hmmmm |
it takes up too much time in an ABM |
| 20:00 |
nore |
(That will start the nodetimer again) |
| 20:00 |
hmmmm |
does this show up in mod profiling? |
| 20:00 |
Fixer |
est31: wait, he was running 1day old mtg iirc |
| 20:00 |
|
paramat joined #minetest-dev |
| 20:00 |
nore |
hmmmm: problem is that this code has absolutely no loop |
| 20:00 |
est31 |
Fixer, 1 day old mtg has already nodetimers |
| 20:01 |
Fixer |
or 2 days old, i build it yesterday |
| 20:01 |
|
Tmanyo joined #minetest-dev |
| 20:01 |
est31 |
Fixer, the backtrace clearly shows that an ABM is used |
| 20:01 |
Fixer |
ok |
| 20:01 |
est31 |
AND tenplus1 said that he used the last working version with abms |
| 20:02 |
nore |
est31: if you get nothing with latest mtg, it's because the nodetimer is not running |
| 20:02 |
nore |
moving items in the furnace might get it running again |
| 20:09 |
est31 |
https://github.com/minetest/minetest/issues/4151#issuecomment-223834567 |
| 20:09 |
|
JBB joined #minetest-dev |
| 20:10 |
|
Tmanyo joined #minetest-dev |
| 20:12 |
est31 |
hmmmm, tenplus1 is in #minetest-project you can speak with him in that channel |
| 20:19 |
|
Tmanyo joined #minetest-dev |
| 20:23 |
|
tenplus1 joined #minetest-dev |
| 20:23 |
* tenplus1 |
is loitering |
| 20:37 |
tenplus1 |
bye all |
| 20:37 |
|
tenplus1 left #minetest-dev |
| 20:39 |
|
Void7 joined #minetest-dev |
| 21:02 |
|
Puka joined #minetest-dev |
| 22:08 |
|
Tmanyo joined #minetest-dev |
| 22:21 |
|
DFeniks joined #minetest-dev |
| 22:32 |
|
Zeitgeist_ joined #minetest-dev |
| 22:40 |
paramat |
uh finally #4191 (am tired) < hmmmm . if it seems good feel free to merge it |
| 22:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/4191 -- Lua_api.txt: Split long lines. Capitalise 'Biome API'. Minor edits by paramat |
| 22:41 |
|
Void7 joined #minetest-dev |
| 22:47 |
|
Puka_ joined #minetest-dev |
| 22:51 |
|
paramat left #minetest-dev |
| 23:02 |
|
Miner_48er joined #minetest-dev |
| 23:06 |
|
Void7 joined #minetest-dev |
| 23:39 |
|
Puka joined #minetest-dev |
| 23:40 |
|
Puka joined #minetest-dev |
| 23:48 |
|
Puka joined #minetest-dev |
