Minetest logo

IRC log for #minetest-dev, 2015-04-07

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

All times shown according to UTC.

Time Nick Message
00:00 est31 hrm, /me wonders how hard it would be to add scrypt support
00:01 est31 perhaps we should handle it transparently
00:01 est31 and give it the scrypt hash
00:01 est31 as "password"
00:02 est31 that sounds quite good
00:02 est31 Only thing that needs modification then is the salt generation
00:03 est31 (as in: use our salt, dont invent your own :p)
00:03 est31 then we can use one salt for the scrypt and the srp
00:06 est31 another problem csrp has is seeding portability
00:06 est31 we have to manually seed it on platforms that aren't windows or linux
00:07 est31 adding that as //TODO
00:07 * est31 is no bsd expert, cant even test behaviour there
00:16 err404 joined #minetest-dev
00:17 Fritigern joined #minetest-dev
00:24 Fritigern joined #minetest-dev
00:25 est joined #minetest-dev
00:39 Fritigern joined #minetest-dev
00:40 paramat hmmmm i'd like to push #2611 in 2 hours, please could you review before then?
00:40 ShadowBot https://github.com/minetest/minetest/issues/2611 -- Cavegen: Remove now unnecessary checks for water, lava, ice. Various mgv5/mgv7 fixes by paramat
00:45 Fritigern joined #minetest-dev
00:49 hmmmm looks good to me
00:51 est csrp implementation looks much better now
00:52 paramat :)
00:52 hmmmm est, this might be useful (probably not) https://github.com/kwolekr/chii​sai-bnetd/blob/master/src/srp.c
00:53 est oh you have implemented srp yourself already?
00:53 hmmmm I reverse engineered the SRP implementation used by WC3
00:53 hmmmm it's not 100% standard but
00:54 hmmmm here is the client-side computation:  https://github.com/kwolekr/phyr​os/blob/master/src/crypto/srp.c
00:55 est what are your dependencies?
00:55 hmmmm libgmp
00:55 Fritigern joined #minetest-dev
00:55 hmmmm that being said, it's probably more secure to use a current implementation of SRP using modern hash algorithms
00:55 Megaf joined #minetest-dev
00:56 hmmmm this only works on 32 byte integers
00:56 hmmmm and 20 byte sha1s
00:56 est 32 bytes seem ok
00:56 hmmmm yeah but
00:56 hmmmm the standard is now sha-512 iirc
00:56 hmmmm what are the dependencies of csrp?
00:56 est openssl
00:56 hmmmm oh come on
00:56 hmmmm what does it use openssl for?  hashing?
00:57 est hashing and bignum
00:57 hmmmm hrmm
00:57 hmmmm are there any alternatives?
00:58 est I haven't done a really thorough study yet
00:58 est only taken the one linked by ShadowNinja
00:58 hmmmm i'd like to not bring in openssl
00:58 hmmmm if possible
00:58 est isnt it there already?
00:58 hmmmm i didn't think so... is it?
00:59 hmmmm cURL maybe, but that's an optional dependency on a dependency
00:59 est yes
00:59 hmmmm two optionals
00:59 hmmmm bringing in dependencies are serious business
00:59 est yes
00:59 hmmmm because generally they're a big pain in the butt
01:00 hmmmm libgmp in particular works fine on windows so I'm okay with that, but anything GNU i would be wary of because they try to make it as difficult as possible
01:01 est can we ship libgmp ourselves?
01:01 hmmmm yes
01:01 est now we only need a method for secure random
01:01 hmmmm we have
01:02 est how?
01:02 hmmmm PcgRandom()
01:02 hmmmm although it doesn't hurt to use OS random facilities too
01:03 hmmmm rand_s() for Windows, /dev/random for anything else
01:03 est PcgRandom is a pseudorandom
01:03 est with a quite narrow state
01:03 hmmmm PCG32 looks simple, doesn't it?
01:04 hmmmm it's crypto-quality though
01:04 hmmmm read up on it
01:04 est I've just seen the u64
01:05 est I mean, what does sha-512 use when you only have 64 bits of state in your PRNG
01:07 est when you say it I believe you
01:07 hmmmm PcgRandom::bytes(64)
01:08 hmmmm :p
01:08 hmmmm its state is unpredictable
01:08 hmmmm er wrong word
01:08 hmmmm assuming you randomize both the sequence and initial seed
01:08 hmmmm http://www.pcg-random.org/
01:08 hmmmm read
01:09 hmmmm my point is that because you can't predict the state given the current output of PcgRandom::next(), you can create as much of a range as you'd like
01:10 est yes
01:10 est but still the entropy is less than or equal than 64 bits
01:11 est but that can be solved
01:12 est http://www.pcg-random.org/useful-feat​ures.html#multiple-streams-sequences
01:12 est ^ cool trick I found
01:14 est when we have 16 bytes from the server and 16 bytes from the client, thats enough
01:14 hmmmm cool stuff
01:14 est then we combine, and have those 512 bits
01:14 hmmmm i think you should still add in the OS enthropy as well
01:14 est yes, thats the only source
01:14 hmmmm erm I mean enthropy from the OS random generator
01:15 est so when a server starts, its 4 PRNGs get seeded by the OS generator, and then we live off that
01:15 est on the client side similar
01:15 hmmmm sure
01:21 est what do you think, can we use your srp implementation?
01:22 hmmmm no
01:22 hmmmm i don't trust it
01:22 hmmmm it's not my implementation either, it's a nonstandard implementation with some questionable changes
01:23 est ok
01:23 hmmmm looking for:
01:23 est option 2: use the openssl one
01:23 est option 3: use libgmp and roll our own
01:23 est option 4: search for better implementations
01:23 hmmmm something with lightweight dependencies
01:24 hmmmm uses the current official SRP standard
01:24 hmmmm which I think is SRPv7
01:25 est 7? I only know of 6a
01:25 hmmmm oh it is
01:25 hmmmm i assumed there was a newer one out
01:26 hmmmm doesn't openssl contain an SRP implementation?
01:26 est dunno
01:27 est the so called "reference implementation" is an openssl patch
01:27 est so perhaps it has been merged
01:27 hmmmm which is why i say that some "csrp" with openssl as a dependency is a bad idea
01:27 est why?
01:30 est also, if this is the srp API of openssl, then we might not want it: https://github.com/libressl/libress​l/blob/master/src/crypto/srp/srp.h
01:30 hmmmm oh BS
01:30 hmmmm I am looking at how to use SRP in OpenSSL right now
01:30 hmmmm you need to actually execute some things from the openssl command line if i'm reading this correctly
01:31 paramat left #minetest-dev
01:35 hmmmm maybe csrp isn't that bad after all
01:35 est if you have read the same wordpress article I have, then I fully agree
01:36 hmmmm I wonder how tough it would be to take csrp and modify it to use libgmp for big numbers and then use our own hash algorithm
01:36 est not that hard
01:36 est also csrp is hash alg agnostic
01:36 hmmmm i'd go with that then
01:36 est so we can give it sha-512
01:39 est including it may have issues though
01:39 est (libgmp)
01:39 est "Since version 6, GMP is distributed under the dual licenses, GNU LGPL v3 and GNU GPL v2"
01:39 est we are LGPL v2.1+
01:45 hmmmm hrmmmm
01:46 hmmmm well
01:47 hmmmm freebsd distributes GPLed software in their base and they're able to keep their BSD license
01:47 hmmmm I think it only matters if you are modifying libgmp
01:47 est ok
01:49 VanessaE "error in error handling".  real fucking useful, Lua. :P
02:01 VanessaE_ joined #minetest-dev
02:09 est hmmmm, what's this LPNLS stuff?
02:09 est I cant find it in libgmp
02:19 est guess I dont need it
02:20 est cool, the API of csrp doesnt even require openssl
02:26 hmmmm NLS is just a structure that contains all the SRP variables for that user session
02:43 JeDa joined #minetest-dev
02:44 JeDa_ joined #minetest-dev
02:44 est ah I see thought it was gmp stuff
02:48 JeDa_ joined #minetest-dev
02:56 DFeniks joined #minetest-dev
03:18 Gethiox joined #minetest-dev
03:25 paramat joined #minetest-dev
03:40 paramat now pushing #2611
03:40 ShadowBot https://github.com/minetest/minetest/issues/2611 -- Cavegen: Remove now unnecessary checks for water, lava, ice. Various mgv5/mgv7 fixes by paramat
03:41 Hunterz joined #minetest-dev
03:42 everamzah joined #minetest-dev
03:49 paramat push complete
03:53 est gmp is more powerful
03:53 est ^ first impression
04:00 Zeno` joined #minetest-dev
04:00 paramat hmmmm i have a random idea: multithreaded lua is only really needed in one specific case, when a lua mapgen is reading, processing and writing a newly generated chunk. as it's unlikely any other lua operation will be accessing that new mapchunk why not use a (erm) 'local envlock' on the entire voxelmanip volume of that new mapchunk?
04:02 paramat so essentially focussing on one specific need instead of more general multithreading
04:02 hmmmm multithreaded lua is for running multiple mods at the same itme
04:02 hmmmm s/itme/time/
04:03 est fulfilling that specific need is easier than a "solution to solve it all"
04:13 paramat mmm i don't mean 'instead of', general multithreading would be excellent. it just seems easier in that circumstance
04:14 ShadowNinja Multithreading has to be "opt-in".  A tweaked versionof the current async API would be good.
04:15 ShadowNinja You need to be able to do things like specify "this task will run for a long time, or until the server shuts down, so you should spawn a new thread just for it instead of having it back up the queue".
04:15 ShadowNinja Or better yet, automatic thread pool management.
04:23 prozacgod joined #minetest-dev
04:47 paramat left #minetest-dev
05:11 est only one function left to convert
05:12 est (and then random stuff ofc too)
05:12 ShadowNinja Apparently Jsemaphores use a global mutex lock on OSX...
05:14 ShadowNinja Can someone explain this ^?
05:30 ShadowNinja It seems like OSX semaphores don't store their value, but the global mutex seems like a bug.
05:30 est hmmmm, I suggest we use SHA-512 internally for all housekeeping hashing (inside the srp auth), and scrypt or another such fancy new hash for the verifier generation. That will be the only part where we will be susceptible to brute-force.
05:31 est I can make a PR that replaces our current SHA-1 implementation with the implementation of OpenSSL, which also has other SHA functions like SHA-512
05:36 Zeno` ShadowNinja, can I add to the protocol without breaking it?
05:36 Zeno` i.e. I imagine that older clients would just ignore the unknown bits (yeah I can look, but you know already so I thought I'd ask)
05:36 ShadowNinja Zeno`: Yes, you might have to bump the protocol version so that you don't send the messages to old clients though.
05:37 Zeno` ok thanks
05:37 ShadowNinja Oh, to a current message?  Yes.
05:37 VanessaE_ there's an optional/extensions section of the protocol isn't there?
05:41 est btw protocol 25 isn't used right now Zeno`.
05:41 est its half finished
05:42 est I'm making a change that makes it even less finished :p
05:42 Zeno` yeah it's a current message
05:43 Zeno` hehe est
05:44 Hunterz joined #minetest-dev
06:10 cib0 joined #minetest-dev
06:21 denis_ joined #minetest-dev
06:24 hmmmm ah scrypt
06:25 hmmmm what's wrong with hashing SHA-512 like 500 times?
06:25 hmmmm I think a good target should be for the operation to take ~200ms on a current gen i7
06:25 hmmmm you need to respect older computers too
06:28 hmmmm anyway I looked into it a bit more, preemptive threading in lua is pretty much impossible.  i thought you could do it with debug hooks, but you can't set the execution to somewhere else
06:29 hmmmm so yeah we're gonna need to make like 5000 threads :(
06:30 est SHA-512 500 times can easily be parallelized
06:31 hmmmm how on earth can you parallelize that
06:31 est you can make a pipeline
06:31 hmmmm ?
06:31 est of 500 sha-512 steps
06:32 est at least thats what I think why its bad
06:32 hmmmm what do you mean by a pipeline
06:33 hmmmm unless i'm seriously misunderstanding something, it's no more parallizable than running scrypt on 500 different passwords on different processors all at once
06:34 est I think the trick about scrypt was that it also requires alot of ram
06:34 est and at the time it came out, it wasn't abundant in these programmable logic chips
06:35 est but with those cryptocurrencies we now have the situation that there are ASICS for scrypt
06:36 hmmmm :(
06:36 hmmmm hmm i can't find exactly how "large" these pseudorandom bit strings are
06:37 hmmmm sure, scrypt looks good enough
06:37 hmmmm I think we should have this as an option though
06:38 hmmmm there are certainly a lot of cases where this could get annoying (like debugging) or too expensive for servers on low-end hardware
06:38 est servers shouldn't touch scrypt
06:38 est clients only
06:38 hmmmm oh okay
06:38 hmmmm so that case is out
06:39 hmmmm so like a strength parameter
06:39 est servers can use SHA-512 instead
06:39 hmmmm one could be sha-512, and the number of iterations, and then the other option scrypt, and the number of iterations (i guess multiple scrypt rounds if you're feeling crazy?)
06:39 est scrypt has a parameter thats controlling that
06:39 hmmmm oh great
06:40 est it even has two one for memory one for cpu
06:43 est so, which SHA-512 implementation to use?
06:50 denis_ gor what purpose you use sha-512?
06:50 denis_ *for
06:50 est srp internal hashing
06:55 est sha-256 sounds good enough though too
07:04 denis_ mods can be written only using Lua? Is it possible, to use C++?
07:04 hmmmm technically yes
07:04 hmmmm you'd still have to use lua as an intermediary though
07:19 VanessaE_ it is a tantalizing thought, C++ mods with access to the same API calls as Lua.  just-in-time compiling with caching of the compiled results would make it pretty painless to use I think.
07:19 est stupid nacl
07:19 kilbith joined #minetest-dev
07:19 est they claim to be the best of the greatest
07:19 est but then they dont even have separate init and update functions
07:20 est only a large crypto_hash function
07:20 est as if I knew my hash content from the beginning
07:38 est gonna take openssl and extract it somehow
07:38 est shouldnt be too hard
07:44 hmmmm this for sha-512 or scrypt?
07:44 hmmmm that's pretty pathetic that you can't find a decent implementation anywhere
07:45 sfan5 libnettle has sha-512
07:45 sfan5 in case that helps
07:47 jin_xi joined #minetest-dev
07:51 est I can find impls but I want one that doesnt leak side-channels
07:52 sfan5 This is a game not a banking app.
07:52 est nettle looks good too, I'll have to find out which is easier to steal from, openssl or nettle
07:52 hmmmm heh agreed
07:52 hmmmm but that's the same argument made when the auth was first implemented
07:52 hmmmm if we're doing it right now it better actually be done right
07:53 est yes, but wasnt it you who wanted it to be perfect sfan5?
07:53 sfan5 no
07:53 sfan5 also: please don't use openssl
07:53 est (or perhaps it was sapier, no idea)
07:53 sfan5 it's build system sucks
07:53 est I'll only copy code
07:53 hmmmm ty.
07:54 sfan5 est: copying code out of openssl will probably end up with copying half of the other openssl stuff
07:56 hmmmm est, you're looking for a side-channel resistant sha-512?  how would timings differ in sha assuming the data being hashed fits inside the size of chunks it operates on?
07:56 hmmmm you know how sha-1 operates on like 256 bytes at a time, and anything below that is padded with zeros
07:56 est dunno
07:57 est sfan5, I got quite far with removing includes in openssl
07:57 est one file only was included to make openssl run on cray operating system
07:57 sfan5 who says the resulting code is gonna work
07:58 est thats an assumption I havent confirmed yet
07:59 est but ofc I'll have to test it then
08:01 sfan5 I'd rather link to a smaller crypto lib than rip out code from the bigger openssl and hope it works
08:05 est adding deps is pain in the butt hmmmm is right
08:05 est sha functions aren't black magic
08:08 hmmmm ugh
08:08 hmmmm so I gave Kdevelop a fair try
08:08 hmmmm it looks solid at first, but it actually functions rather poorly
08:10 Krock joined #minetest-dev
08:11 cib0 joined #minetest-dev
08:18 jin_xi i like qtcreator
08:27 FR^2 joined #minetest-dev
08:43 est ok the sha impl from openssl seems to work
08:43 est and only two files!
08:44 est (sha256.c and sha2.h)
08:44 aureate joined #minetest-dev
08:49 est no, sorry. 3 files
08:49 est md32_common.h is needed too
08:58 denis_ OpenSSL rulezzz
09:01 sfan5 OpenSSL sucksss
09:02 est where to place gmp library?
09:03 est directly in src/ like lua?
09:03 Ritchie joined #minetest-dev
09:04 sfan5 we're not including gmp into the minetest souce
09:04 sfan5 +r
09:04 sfan5 or rather I think thats a bad idea
09:05 est the other alternative would be to depend on it
09:05 est but dependencies are ... bad.
09:05 sfan5 the sqlite source initially was in the minetest src too
09:06 sfan5 but it was added as a dependency because of reasons
09:06 sfan5 such as that it was never updated
09:06 sfan5 also if we're going to depend on libgmp why not depend on just libnettle
09:06 est we dont need libnettle
09:07 sfan5 why not
09:07 est why yes
09:07 sfan5 it's 1 dependency and does what we want
09:07 sfan5 if we use openssl we also have one 1 dependency
09:07 est I dont want to use openssl
09:07 sfan5 (and some code we may or may not need to update [sha256.c, sha2.h, md32_common.h])
09:08 sfan5 if we use the files from openssl*
09:08 est we rather may not need to update
09:09 sfan5 actually
09:09 sfan5 why not just implement sha256 ourselves?
09:10 est adding dependencies just because isnt good
09:10 est there are still things that need to be maintained if you have dependencies
09:10 est like cmake finder files
09:11 sfan5 we need a dependency anyway
09:11 sfan5 including more code into the minetest src because "dependencies are bad" is not good either
09:11 est so its one dependency against two dependencies
09:11 sfan5 two dependencies?
09:12 est we'll still need libgmp
09:12 sfan5 yeah
09:13 denis_ Are you trying to make some logon/password verification?
09:13 est yes
09:14 est I have ported csrp from openssl to libgmp, but I also want to use a better hashing algorithm
09:14 est therefore the discussion about where to get the hash alg
09:14 Darcidride joined #minetest-dev
09:14 denis_ I think it's easy to find source code for any hashing algorithm
09:15 est minetest has high requirements
09:15 est for example, the license has to be right
09:15 sfan5 did i mention that it's a game and not a banking app
09:15 est still if its GPL we cant include it
09:15 sfan5 and: <sfan5> why not just implement sha256 ourselves?
09:16 est why not depend on systemd just because?
09:16 sfan5 what does this have to do with systemd
09:17 sfan5 using openssl's code is 1 dep. (libgmp), nettle is 1 dep. (libnettle) and writing the code ourselves is 0 deps
09:18 denis_ https://code.google.com/p/blockcha​in/source/browse/trunk/SHA256.cpp
09:18 denis_ the second google link. MIT license
09:19 est no, using openssl's code isnt 1 dep
09:19 denis_ I can't understand, why you need only hash algo, if you are writing some security stuff, you need much more than that
09:19 est that code only depends on std c lib
09:20 est yes we do need more than that
09:20 est for srp we need libgmp
09:20 est (not for the openssl sha2)
09:21 sfan5 ohh
09:21 sfan5 you should've said that
09:21 sfan5 including libgmp into the minetest source is still a bad idea imo
09:21 est sorry bout that
09:22 * sfan5 away
09:23 cib0 joined #minetest-dev
09:24 denis_ Java easier in that way, it already has a lot of stuff.
09:25 est yea
09:44 eeew joined #minetest-dev
09:53 kilbith joined #minetest-dev
09:55 kilbith seeing and confirming that : https://github.com/minetest/minetes​t/issues/2541#issuecomment-90158381   the best fix would to revert bfc4652 and aa340fd
09:56 kilbith i don't think nerzhul is able to provide a sane fix
09:56 kilbith ^ Zeno`, what are tour thoughts ?
09:56 kilbith *your
09:59 selat joined #minetest-dev
10:03 est I'm not sure, but bfc4652 only fixed an error
10:03 est the packet is supposed to be unreliable
10:05 kilbith it cause an huge freeze with
10:07 kilbith so i dunno whether the unrealiable packet is inherently not the good way here, or the nrz's adaptation ain't good
10:08 Player_2 joined #minetest-dev
10:08 est That packet was unreliable in the past
10:08 est then it got reliable due to <insert reason here>
10:08 kilbith ok, so it's nerzhul shit
10:08 Krock +'s
10:08 est seems caused by his changes
10:09 deltib joined #minetest-dev
10:15 cib0 joined #minetest-dev
10:15 Krock Somehow I can't reproduce the errors of 2541
10:36 proller joined #minetest-dev
10:50 proller joined #minetest-dev
11:17 Calinou joined #minetest-dev
11:17 Jordach joined #minetest-dev
11:20 Darcidride joined #minetest-dev
11:41 VanillaVan joined #minetest-dev
11:51 leat joined #minetest-dev
12:01 Darcidride_ joined #minetest-dev
12:04 VanillaVan joined #minetest-dev
12:07 Darcidride_ joined #minetest-dev
12:15 cib0 joined #minetest-dev
12:16 roniz joined #minetest-dev
12:21 rubenwardy joined #minetest-dev
12:32 Darcidride__ joined #minetest-dev
12:34 prozacgod joined #minetest-dev
12:40 selat joined #minetest-dev
12:48 rubenwardy joined #minetest-dev
13:03 JeDa joined #minetest-dev
13:32 Krock2 joined #minetest-dev
13:50 chchjesus joined #minetest-dev
14:11 Darcidride__ joined #minetest-dev
14:12 Gethiox joined #minetest-dev
14:28 chchjesus_ joined #minetest-dev
14:37 hmmmm joined #minetest-dev
14:46 hmmmm libgmp is something that doesn't need to be updated often
14:46 hmmmm I don't think bundling it by default is a horrible idea - don't get me wrong, users should still be able to use their system version
14:48 Darcidride_ joined #minetest-dev
14:50 Darcidride joined #minetest-dev
14:55 Darcidride_ joined #minetest-dev
15:04 proller joined #minetest-dev
15:22 cib0 joined #minetest-dev
15:56 proller joined #minetest-dev
15:59 rubenwardy joined #minetest-dev
16:00 Amaz joined #minetest-dev
16:07 SopaXorzTaker joined #minetest-dev
16:19 ElectronLibre joined #minetest-dev
16:27 Robert_Zenz joined #minetest-dev
16:28 Hunterz joined #minetest-dev
16:30 6JTAAUR2F joined #minetest-dev
16:32 hmmmm joined #minetest-dev
17:18 MinetestForFun joined #minetest-dev
17:39 MinetestForFun joined #minetest-dev
17:52 Amaz left #minetest-dev
18:05 aureate joined #minetest-dev
18:25 cib0 joined #minetest-dev
18:48 proller joined #minetest-dev
19:10 roniz joined #minetest-dev
19:10 luizrpgluiz joined #minetest-dev
19:12 hmmmm joined #minetest-dev
19:37 luizrpgluiz left #minetest-dev
19:42 Amaz joined #minetest-dev
19:54 kilbith ShadowNinja, as requested... game#486
19:54 ShadowBot https://github.com/minetes​t/minetest_game/issues/486 -- Convert beds in mesh by kilbith
19:57 VanessaE_ aw, not using homedecor's model :(
20:17 est31 joined #minetest-dev
20:19 est31 I think I can live with all options -- bundled gmp or not. just hmmmm is right, dependencies are a PITA.
20:19 hmmmm especially on windows
20:19 hmmmm god dammit
20:20 hmmmm every time <set> is included, it compiles all that code
20:20 hmmmm so including STL containers inside of a header files is a double-whammy
20:20 hmmmm really wish it was easier to forward define templated classes
20:21 hmmmm forward declare rather
20:21 selat joined #minetest-dev
20:38 ElectronLibre left #minetest-dev
20:40 aureate joined #minetest-dev
20:45 proller joined #minetest-dev
21:00 Amaz joined #minetest-dev
21:50 aureate joined #minetest-dev
22:05 proller joined #minetest-dev
22:19 est31 joined #minetest-dev
22:20 est31 hm, I have now some method chunks for the new protocol
22:20 est31 I can do it nrz style and commit them to master, so that everybody can see
22:21 est31 (nothing functional will change, as the protocol is still v24)
22:21 est31 or I can make a PR
22:22 est31 I dunno whether its a smart idea to share my design for comments
22:22 est31 but I also dunno whether ppl actually care, after the overwhelming storm of discussion my mail has started.
22:22 est31 I mean it is already shares
22:23 est31 shared*
22:23 est31 sharing method chunks isn't better either I think
22:23 est31 (btw now I think crypto stuff is for later, and can be done in its own packets, outside of init, too)
22:42 Zeno` joined #minetest-dev
22:46 jin_xi hm, so i've been checking out pathfinding a bit
22:46 jin_xi hacked in a way for paths to avoid a node and removed strange line of sight optimization - ta da!
22:47 jin_xi works much better and probably more as expected for mob makers
22:47 jin_xi avoid a node - i mean to avoid all nodes of a given type
22:49 jin_xi the line of sight thing is especially bad, it will happily produce paths over thin air
23:23 roniz joined #minetest-dev
23:28 proller joined #minetest-dev
23:36 Miner_48er joined #minetest-dev
23:49 kahrl_ joined #minetest-dev

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