Minetest logo

IRC log for #minetest-dev, 2015-08-06

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:03 TBC_x est31: I'm refactoring ClientInterface but I need to know when are the SRP packets supposed to be handled
00:04 TBC_x I want to move all the handshake stuff out of RemoteClient
00:04 est31 well, they are at init time.
00:04 TBC_x only at Init?
00:04 est31 and afterwards too
00:05 est31 there are three occasions we can have authentication packets floating around
00:05 est31 1. for init, the usual login
00:05 est31 2. to authenticate for sudo mode
00:05 est31 3. to change the password once inside sudo mode
00:05 est31 3. is only one auth mech for now
00:06 est31 but 2. and 1. are multiple mechs.
00:06 TBC_x I want to move at least the init stuff out
00:06 est31 to where
00:06 TBC_x to Server
00:06 TBC_x atm
00:07 est31 which handshake do you mean?
00:07 TBC_x the init handshake, including client state
00:07 est31 the whole client state?
00:08 est31 whats left in clientiface if you take that away?
00:08 TBC_x the client and its blocks
00:09 TBC_x I don't like accessing the client directly
00:09 TBC_x so I want to hide as much as possible behind the client interface
00:09 est31 so why do you remove stuff from it then?
00:10 TBC_x well... only the stuff that is required for init
00:10 est31 the states are much more than just init.
00:10 TBC_x I'm trying to remove all getClient() methods
00:10 est31 so why are the states obstructing you with that?
00:12 est31 also, why do you think is a file with 3428 lines a better place in your mind?
00:13 TBC_x my goal is to hide RemoteClients behind ClientInterface
00:13 TBC_x and I was not sure whether the srp is needed for the entire session
00:14 TBC_x if it was not, I could move auth out of RemoteClients
00:15 est31 we need it not just for init.
00:16 est31 also, auth data is in the clientiface, no?
00:16 est31 err sorry
00:16 est31 its in remoteclients.
00:16 est31 an abstraction layer which handles all auth would be very good though.
00:16 TBC_x yes
00:17 est31 so if you design it, you should keep in mind, that srp is needed at all those three occasions
00:17 TBC_x current problem is that emergethread may access client when packet handlers have reference to it but not lock
00:17 TBC_x therefore data race
00:18 est31 what's it the business of emergethrea
00:18 est31 d
00:18 TBC_x setBlocksNotSent
00:18 est31 why can't it just have a queue, of outstanding mapblocks to be delivered?
00:19 TBC_x probably someone's optimization?
00:19 TBC_x this is my clientiface.h right now http://sprunge.us/aTAP
00:20 TBC_x I removed all getClient() methods
00:20 est31 perhaps a diff would be better
00:20 TBC_x ok
00:21 TBC_x http://sprunge.us/ODRP
00:21 est31 grr #2885 uses getClient extensively
00:21 ShadowBot https://github.com/minetest/minetest/issues/2885 -- Utf8 based chat by est31
00:22 TBC_x I wrapped some scattered member variables into logical structures
00:22 blaaaaargh joined #minetest-dev
00:22 TBC_x but I need to break HandshakeInfo struct
00:24 est31 eh, why so much Handshake*Info structs
00:24 est31 new struct for just two variables?
00:25 TBC_x this is not final
00:26 est31 also, c++ has constructors
00:26 TBC_x I know
00:26 est31 we dont need createEmpty
00:27 est31 bad descision that rust has no constructors.
00:27 TBC_x rust has default trait
00:28 TBC_x that works like default constructor
00:28 TBC_x i was definitely doing premature optimizations around createEmpty()
00:29 est31 VersionInfo is even good I think
00:29 TBC_x yes
00:29 est31 it should be perhaps used at more places
00:30 est31 perhaps even defined by version.h
00:30 est31 finally something version.h can be used for
00:30 est31 right now it only lives for version.cpp
00:35 TBC_x now tell me, what in HandshakeInfo should not be moved out of RemoteClient?
00:35 TBC_x I wanted to move all of that out
00:37 TBC_x replaced createEmpty with constructors
00:37 est31 I don't think we need separate handshakeinfo and clientnetinfo
00:37 est31 or even separate from clientinfo
00:38 TBC_x I want to minimize packet handlers touching RemoteClient
00:39 TBC_x when some of the stuff is used only once, It could be allocated somewhere else
00:39 est31 we can put that all into clientinfo
00:40 est31 the problem is, right now I know of no criterion why these things live in separate structs
00:40 est31 you should be abled to give a clear criterion why something should be in one struct, something else in another
00:41 est31 otherwise you perhaps should merge them.
00:41 est31 because you cant define a clear line
00:41 est31 "its needed by packet handlers" thats a clear line
00:41 est31 vs "its hidden behind some clientiface logic"
00:42 TBC_x When I was first separating the clientinfo and friends I was thinking that a initialization handler could do its thing and then initialize RemoteClient with those structs
00:42 TBC_x I mean, initialize RemoteClient when the init phase finishes
00:43 hmmmm [07:48 PM] <est31> why an assert now?
00:43 hmmmm i dunn, we have to do something
00:43 TBC_x so the final step would pass the initialized data to RemoteClient constructor
00:43 hmmmm didn't realize it was a pointer at first so yeah i agree it needs to be checked, but i don't think it should persist in a release build
00:44 est31 My comment was more along "compare it with NULL not with 0"
00:44 est31 not "make an assert"
00:45 TBC_x I wanted all the members in HandshakeInfo move away from RemoteClient
00:45 est31 the problem is I think that channel is somehow settable by the client
00:45 est31 or the other peer
00:45 est31 to be neutral
00:45 est31 TBC_x, nothing wrong with that
00:45 hmmmm the channel is selectable by an 8 bit ID number
00:45 hmmmm in the highest protocol layer
00:46 est31 but why did you split it up this far TBC_x? One struct to separate with is enough, no?
00:47 est31 otherwise you just keep around hundreds of pointers an have to remember each of the Info and NetInfo objects and what they contain
00:47 est31 and its unmaintainable too, imagine if something new comes around
00:47 est31 which doesnt fit into the "design" it has been built after
00:47 TBC_x This is not final design
00:47 est31 then all has to be destroyed
00:47 hmmmm yea there's no way the channel pointer can be manipulated by the client into being NULL
00:47 est31 so better to not overengineer something
00:48 TBC_x and I value your input
00:48 est31 hmmmm, there is no way?
00:48 hmmmm nope
00:48 est31 there is a comparison connection != 0 just before the method is called
00:48 est31 so that can be removed, you say?
00:49 hmmmm it could be
00:49 est31 ok.
00:49 est31 then its ok
00:49 hmmmm see the main problem is that these checks are mostly pedantic
00:49 hmmmm they're really not necessary and it would only make sense to explicitly check them if they were intended to be part of a public interface for use by multiple things outside of connection.cpp
00:50 hmmmm and what's more is that they're completely inconsistent
00:50 TBC_x est31, also http://sprunge.us/XNQB
00:50 est31 we don't use channels that much, agreed
00:50 hmmmm there's so much sanity checking on specific functions, even checking the value of a variable right after an if statement returns if it's equal to something
00:50 hmmmm generally connection.cpp is a mess
00:51 TBC_x I think this way it is more readable
00:51 est31 TBC_x, what's the point in adding the ? thing here
00:51 hmmmm i would not recommend adding a sanity_check() whatever if there's some convoluted logic involved with that code where such a condition could conceivably arise
00:51 est31 should that be added to every boolean expression
00:51 hmmmm TBC_x, that is incredibly repetitive
00:51 est31 for (int i = 0; (i < 10) ? true : false; i++)
00:51 hmmmm i don't think it's more readable anyway
00:52 hmmmm yeah really :p
00:52 TBC_x at least to assignments
00:53 est31 ok, then my concerns with the connection.cpp change are gone, +1
00:53 est31 now about the lua error handler commit
00:53 TBC_x more informative messages are good
00:54 est31 have you seen my comment about that you pass the function name pointer through two methods, even if there is no error?
00:54 hmmmm it's meant to give us a better clue about what's happening with those two crashes with no stacktraces
00:54 hmmmm est, yeah
00:55 hmmmm so what?
00:55 est31 first its a repurpose, so the methods should be at least renamed, second its needless jumps and complexity.
00:56 est31 if you want to understand the code, you'll have to travel first to the macro then to the first method, then the second, then only you see the if about the return value
00:56 hmmmm alright, point made
01:01 kaeza joined #minetest-dev
01:03 est31 otherwise +1 to the error msg commit as well.
01:03 twoelk|2 joined #minetest-dev
01:06 est31 ~tell nrzkt can you make test android builds, and perhaps try to find out whether #2973 is because of device, or because of build setup? If its build setup we dont have to patch around. if its device based, we will have to disable iconv usage, this should be cleared now, before the release.
01:06 ShadowBot est31: O.K.
01:07 est31 ~tell nrzkt best to upload them somewhere, so that wayward1 and H-H-H can test it on their devices (they both report the bug, both from self built apks)
01:07 ShadowBot est31: O.K.
01:13 hmmmm est31, did you see the thing about nerzhul's performance optimization
01:14 est31 yes, its for after the release
01:14 est31 imo
01:14 hmmmm good
01:14 hmmmm agreed
01:14 est31 this is why we freeze
01:15 sloantothebone joined #minetest-dev
02:12 est31 twoelk|2, http://irc.minetest.ru/minet​est-dev/2015-08-04#i_4350608
02:12 est31 its how srp has been designed
02:12 est31 it works together with the old password scheme, but new passwords are set as srp verifiers
02:13 est31 so if you log in to a new server the first time, or you change your password with a new client, you will get a srp key in the db, and no hash that would be compatible with old versions
02:13 est31 however, you can ask an admin to set your password
02:16 est31 /setpassword still sets old style hashes, even if all parties are connected with new clients
02:18 twoelk|2 it seems one tries to connect with an old valid password and the server rejects. wether the server is new I cannot say but the password is usually old
02:20 twoelk|2 http://irc.minetest.ru/min​etest/2015-08-05#i_4352539
02:20 est31 The server has to be new (0.4.12-dev) in order to support srp.
02:22 est31 If you have a reproducible bug, it would be interesting.
02:22 est31 I mean, it would be an issue
02:22 twoelk|2 https://forum.minetest.net/vi​ewtopic.php?p=186041#p186041 and simmilar
02:23 est31 I'm more with ABJ's theory here.
02:23 twoelk|2 http://irc.minetest.ru/min​etest/2015-08-05#i_4352315 and here
02:25 twoelk|2 so many password problems is just a bit unusuall
02:25 est31 hrmm, yes
02:25 est31 AAAAAAAAAAAAAAAAAAAAAA <---- thats too much A's
02:25 est31 A's are bad, this is supposed to be the sale
02:25 est31 salt*
02:26 twoelk|2 I think there was similar talk on inchra but I don't think they have logs
02:26 est31 the only place srp changed during the last weeks was a leak fix
02:27 est31 and that other thing, with the default passwords
02:37 est31 damn, since when do we have this salt bug
02:52 est31 I see now how the salt bug happens
03:03 est31 hmmmm, can you review https://github.com/est31/minetest/commit/​e91af8036c7c9a957628e5977f04e20fa3fc25fa
03:04 est31 analogous to https://github.com/est31/csrp-gmp/commit/​44c909e6b4059ee644031c6b8bb95717d2a6ef12
03:04 est31 its that AAAAA issue
03:05 est31 twoelk, I have made a bugfix patch for srp now, but it was only an unrelated bug I've found, I haven't found the case for aerth's reported problem yet
03:12 VanessaE btw is anyone else getting crashes in the client when the server shuts down?
03:13 est31 lets test it
03:13 est31 whats your test port again?
03:13 VanessaE 30007 I think
03:38 hmmmm est31:  yes looks good I suppose
03:39 est31 I tested it, and it works, so I gonna push it
03:39 hmmmm i assume init_random() initializes using the system random generator or at least uses the system random generator as a seed?
03:39 est31 yes
03:40 est31 the system random generator is even used as only source, if available
03:40 hmmmm erm, doesn't this mean that the SRP implementation up until now was insecure?
03:40 est31 there is nothing wrong or slow about /dev/urandom
03:40 est31 only under certain conditions
03:40 est31 the random generator was already initialized for the actual login
03:41 hmmmm mmmmmm
03:41 est31 just if you logged in for a server for the first time, and this was your first contact with a srp server during the execution period of your client, then yes, you have a vulnerable database hash
03:41 hmmmm as for the irc mod - no idea there
03:41 est31 well, its unsalted
03:41 hmmmm i'd have to look into it better to have a well formed opinion
03:43 est31 and that bad db hash stays with you, as long as you dont change your password
03:43 est31 the only vulnerability here is that the server can build rainbow tables, if the server is evil
03:46 blaise joined #minetest-dev
03:54 hmmmm https://github.com/kwolekr/minetest/commit​/2c508f76541065fa017610edfa4edd0739b1ff39
03:54 hmmmm PTAL
04:02 est31 looks good
04:02 hmmmm did you make sure that everything matches up
04:03 hmmmm i looked at it too, but with such repetitive code it's easy to make a typo mistake
04:03 est31 I'll read through it again
04:09 est31 ok
04:09 est31 +1
04:11 hmmmm done
04:11 hmmmm that takes care of all the known security exploits for this dev version i think
04:12 hmmmm now just to take care of the remaining race conditions/crashes
04:14 blaise joined #minetest-dev
04:17 cvtsx1 joined #minetest-dev
04:29 hmmmm est31:  https://github.com/minetest/minetest/pull/3013
04:32 est31 nice
04:32 est31 there is no reason to get this in before the release though, we dont even use it yet
04:32 hmmmm well this doesn't change any functionality
04:32 hmmmm it's just a good thing to have
04:32 hmmmm i actually did this a while ago, never made a pull request for it though
05:00 est31 joined #minetest-dev
05:19 VanessaE hmmmm, est31:  I'm headed off to bed now.  bd0b469d is staged for the 6am reboot.  safe to use that?
05:19 est31 VanessaE, I hope so :)
05:19 VanessaE "hope" heh
05:20 VanessaE well I guess if it ain't, I'll know in about 8 hours, and know who to yell at ;)
05:21 VanessaE nightg
05:22 hmmmm wait
05:22 hmmmm update to bd0b469
05:23 est31 ?
05:23 est31 thats the one she cited, no?
05:23 hmmmm oh
05:33 hmmmm est:  do you know if the android graphical glitches ever got fixed?
05:41 leat joined #minetest-dev
06:04 amadin joined #minetest-dev
06:09 Hunterz joined #minetest-dev
06:11 amadin left #minetest-dev
06:27 hmmmm pushing in 30 minutes: https://github.com/kwolekr/minetest/commit​/8560ece02e36b1e0ee7b86db2a38b8becbb639e4
06:40 celeron55 lol, why is the warning in german too
06:40 celeron55 just to make sure sapier will notice it? 8)
06:40 hmmmm yeah basically
06:41 hmmmm but erm, for whatever reason, germans love minetest
06:41 hmmmm i'd have to estimate that half of our developers are/were german.
06:43 celeron55 nice work though
06:43 hmmmm tbc found it with Thread Sanitizer
06:43 celeron55 that could have ended up being not fixed for forever
06:43 hmmmm Thread Sanitizer is my new favorite thing ever :)
07:07 Miner_59 joined #minetest-dev
07:08 sloantothebone joined #minetest-dev
07:10 Miner_59 Hi, just want to remember to merge #2241
07:10 ShadowBot https://github.com/minetest/minetest/issues/2241 -- Fix for disable_jump group doesn't work on nodeboxes by gregorycu
07:11 hmmmm oh i'm sorry
07:12 hmmmm that other day when PRs were flying around I thought est31 merged yours
07:12 hmmmm I'll do that
07:12 hmmmm oh this is a different PR
07:12 Miner_59 cool thanks, but gregorycu wrote this PR not I
07:12 Miner_59 my PR is already merged :-)
07:13 hmmmm did your own bouncy jump fix get merged
07:13 hmmmm okay good
07:13 Miner_59 the bug is that minetest checks the block under the nodebox, so disable_jump dont work
07:14 Miner_59 nodebox=not a full block high nodebox
07:14 Miner_59 although damage_per_second seems to be affected
07:17 Miner_59 oh I saw its merged thanks!
07:27 rubenwardy joined #minetest-dev
07:30 cornernote joined #minetest-dev
07:30 est31 joined #minetest-dev
07:30 est31 hmmmm, what about #1551 ?
07:30 ShadowBot https://github.com/minetest/minetest/issues/1551 -- disable_jump group doesn't work on nodeboxes
07:30 est31 isnt it fixed by #2241 ?
07:30 ShadowBot https://github.com/minetest/minetest/issues/2241 -- Fix for disable_jump group doesn't work on nodeboxes by gregorycu
07:31 CraigyDavi joined #minetest-dev
07:31 hmmmm I think so
07:31 hmmmm I just didn't close that issue because I wasn't aware of it
07:31 FR^2 joined #minetest-dev
07:31 hmmmm closing 1551
07:31 est31 ok
07:31 est31 np
07:33 est31 didn't know btw that you can't allocate dynamically sized arrays on the stack until c(+?+?)11
07:34 est31 I guess that makes writing a compiler harder, because you dont know until execution how much space on the stack a function will take.
07:35 est31 well, a bit harder
07:36 hmmmm well i'm not really sure about C++
07:36 hmmmm but so-called "VLA"s came into C with C99
07:36 rubenwardy aren't arrays just pointers, so you can malloc the size you mean?
07:36 est31 not stack arrays
07:36 rubenwardy ok, nvm
07:36 est31 they are pointers too, but to the stack
07:37 hmmmm i'm pretty sure VLAs are usually implemented as officially sanctioned, inline-safe versions of _alloca()
07:37 est31 and on the stack, there is no malloc
07:37 est31 you declare it, you allocate it
07:37 est31 out of scope, it gets deleted
07:37 hmmmm Stack?  What is this 'stack' thing you speak of? :)
07:38 hmmmm that's called a variable with the "auto" storage specifier.
07:39 hmmmm C/C++ has absolutely no notion of "heap" and "stack" btw
07:39 hmmmm that's all implementation dependent
07:39 est31 good to know
07:42 hmmmm est:  3014 looks good to me.
07:46 est31 ouch alloca isnt inline safe
07:47 est31 thats a pretty bad system call
07:47 est31 "it might work, but only if your compiler is in the mood"
07:49 FR^2 left #minetest-dev
07:56 rubenwardy lol, sizeof(u16)
07:56 est31 hrmm, on one hand 3014 is a feature, which shouldn't be merged during freeze, on the other hand it would actually benefit server owners with the irc commands mod who have srp problems.
07:57 rubenwardy #3014
07:57 ShadowBot https://github.com/minetest/minetest/issues/3014 -- Add LuaSecureRandom by est31
07:57 est31 also, nothing much can break, if its merged, you can just not use it.
07:58 rubenwardy Are floats always 4 bytes on all devices? https://github.com/kwolekr/minetest/commit​/2c508f76541065fa017610edfa4edd0739b1ff39#​diff-ca07aa642678d1d0c23dd61b842741f7L264
07:59 est31 yes
07:59 est31 I mean no
08:00 est31 but we serialize them always as 4 bytes
08:00 est31 thats precisely why its bad to have sizeof(float) for serialisation considerations
08:00 Gael-de-Sailly joined #minetest-dev
08:01 Calinou joined #minetest-dev
08:01 Yepoleb_ joined #minetest-dev
08:04 est31 perhaps I merge it after lotsa tests
08:04 est31 finally something I can use mtt for!
08:05 est31 the main argument here would be that its a completely new feature which is totally isolated, and therefore can't break anything existing.
08:08 rubenwardy #2094
08:08 ShadowBot https://github.com/minetest/minetest/issues/2094 -- Fix offset being ignored by inventory bar HUD by rubenwardy
08:27 OldCoder joined #minetest-dev
08:29 andy___ joined #minetest-dev
08:47 Amaz joined #minetest-dev
09:18 wischi joined #minetest-dev
09:20 Darcidride joined #minetest-dev
09:25 paramat joined #minetest-dev
09:34 OldCoder joined #minetest-dev
09:41 kilbith joined #minetest-dev
09:53 paramat sfan5 any comments on game#607 ? including the extra stuff i propose in comments, i think spores need a clearer name
09:53 ShadowBot https://github.com/minetes​t/minetest_game/issues/607 -- Biomes: Improve biome system and v6 mushroom spawning WIP by paramat
09:58 cvtsx joined #minetest-dev
10:47 paramat left #minetest-dev
10:51 Mine joined #minetest-dev
11:05 Gael-de-Sailly joined #minetest-dev
11:21 SopaXorzTaker joined #minetest-dev
11:22 Puma_rc joined #minetest-dev
11:28 Puma_rc joined #minetest-dev
11:34 Lunatrius` joined #minetest-dev
11:42 SopaXorzTaker joined #minetest-dev
11:44 Puma_rc joined #minetest-dev
11:45 Ritchie joined #minetest-dev
11:52 Zeitgeist_ joined #minetest-dev
12:11 Puma_rc joined #minetest-dev
12:20 Puma_rc joined #minetest-dev
12:33 SopaXorzTaker joined #minetest-dev
12:34 Puma_rc joined #minetest-dev
12:37 H-H-H joined #minetest-dev
12:43 alket joined #minetest-dev
13:00 Amaz joined #minetest-dev
13:01 Amaz joined #minetest-dev
13:28 kilbith joined #minetest-dev
13:34 crazyR joined #minetest-dev
13:48 Puma_rc joined #minetest-dev
13:57 Gael-de-Sailly joined #minetest-dev
14:10 werwerwer joined #minetest-dev
14:16 nrzkt joined #minetest-dev
14:30 RealBadAngel https://imgrush.com/BgJ5_VrYDNgh.png
14:30 RealBadAngel i just made swimming pool on Skyblock server :)
14:32 sfan5 are those lots of tiny skyblock islands?
14:47 proller joined #minetest-dev
14:48 VanessaE sfan5: yep, they are
14:48 sfan5 sounds interesting
14:48 VanessaE nice-looking pool, RealBadAngel
14:48 RealBadAngel come see it
14:49 RealBadAngel theres teleporter next to your house
14:50 VanessaE impressive.  where the hell did you get so much obsidian?
14:58 RealBadAngel recipes allow to get that as much as you want
14:58 RealBadAngel craft one shard + stone to get obsidian
14:58 RealBadAngel obsidian to 9 shards
14:58 RealBadAngel and you have shitload of it
15:14 Hunterz joined #minetest-dev
15:16 VanessaE ok, official request for minetest-game et al.  PLEASE go back to the old, darker junglewood color
15:16 VanessaE RealBadAngel: oh right, forgot about that recipe in skyblock
15:17 Amaz Yes, please can we have the old dark color junglewood back?
15:18 VanessaE this lighter color just plain suicks
15:18 VanessaE sucks*
15:19 Gael-de-Sailly joined #minetest-dev
15:20 kilbith the chocolate-y junglewood even worse
15:21 kilbith (ie. the old one)
15:21 VanessaE no, what's really worse is the old OLD wood texture (still used in "minimal" I think :) )
15:21 kilbith for you maybe
15:22 VanessaE similarly, for YOU the "chocolate" junglewood is worse :)
15:23 alket joined #minetest-dev
15:24 kilbith no, for the _game maintainers that decided that
15:27 VanessaE ...
15:27 VanessaE [08-06 11:20] <kilbith> the chocolate-y junglewood even worse   <--- pretty sure that's your opinion
15:28 kilbith ofc, but if it has been replaced it was for the same reason
15:28 kilbith well, stupid bikeshedding anyways
15:30 hmmmm joined #minetest-dev
15:31 luizrpgluiz joined #minetest-dev
15:33 VanessaE actually the color of the texture affects general usefulness (think contrast relative to regular and pine woods), and directly affects at least one mod also (building_blocks creates "hardwood" from jungle wood + regular, and it's dark like junglewood used to be)
15:34 kilbith i agree that junglewood color should be more distinctive though
15:34 Amaz Was there actually a pull for that texture change? Or was it just discussed here?
15:43 VanessaE I think there was bug damned if I remember which
15:44 VanessaE er wtf?>
15:44 VanessaE that came out way wrong
15:44 VanessaE I think there was pull request, but damned if I remember which
15:44 VanessaE that's better :P
15:54 Zeitgeist_ joined #minetest-dev
15:54 luizrpgluiz left #minetest-dev
16:05 nrzkt joined #minetest-dev
16:38 Puma_rc joined #minetest-dev
16:57 MinetestForFun joined #minetest-dev
16:58 MinetestForFun joined #minetest-dev
17:00 RealBadAngel joined #minetest-dev
17:14 MinetestForFun joined #minetest-dev
17:15 FR^2 joined #minetest-dev
17:32 kilbith joined #minetest-dev
17:50 twoelk joined #minetest-dev
17:53 Zeitgeist_ joined #minetest-dev
18:20 Gael-de-Sailly joined #minetest-dev
18:22 Gael-de-Sailly joined #minetest-dev
18:52 VanessaE has anyone fixed the problem with jungle tree and pine trunks replacing other nodes when they grow from a sapling?
18:53 VanessaE (the server I'm playing on has this problem, but I don't remember if that's since been fixed)
19:24 nore joined #minetest-dev
19:35 lag01 joined #minetest-dev
19:49 paramat joined #minetest-dev
19:50 paramat VanessaE yes, it was mgv6 pine trunk replacing nodes, i have added a check for air or ignore
19:50 RealBadAngel accacia too
19:51 VanessaE paramat: jungle trees do it too.
19:51 RealBadAngel also default trees sometime do not replace saplings
19:52 RealBadAngel tree grows on top of a sapling
19:52 paramat v6 jungletree trunk and roots check for air or ignore
19:52 VanessaE paramat: either the jungle trees check is failing or stormchaser's server is doing something weird then
19:52 paramat i'm preparing a PR to not force-place the acacia root
19:53 RealBadAngel i saw accacia failing on singleplayer world
20:03 AnotherBrick joined #minetest-dev
20:12 Gael-de-Sailly joined #minetest-dev
20:13 lag01 joined #minetest-dev
20:29 alket joined #minetest-dev
20:58 WSDguy2014 joined #minetest-dev
21:06 proller joined #minetest-dev
21:12 H-H-H joined #minetest-dev
21:16 paramat left #minetest-dev
21:32 alket_ joined #minetest-dev
21:35 diemartin joined #minetest-dev
21:49 OldCoder /opt/minebest/src/core/server​/minetest/src/server.cpp:505:
21:49 OldCoder void Server::step(float): A fatal error occurred: error in error handlin
21:49 OldCoder Um?
21:49 OldCoder WTH is error in error handling?
22:03 GunshipPenguin joined #minetest-dev
22:03 GunshipPenguin left #minetest-dev
23:39 crazyR_ joined #minetest-dev
23:39 crazyR_ joined #minetest-dev
23:53 wischi2 joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext