Time Nick Message 06:36 hmmmm today was not a very minetesty day 06:37 VanessaE that could change :P 06:37 VanessaE unfortunately it's late :-/ 06:39 hmmmm :/ 06:39 hmmmm so busy lately 06:39 hmmmm hopefully that'll change 06:41 est31 what do you ppl think, which hash alg for speed improvements? 06:41 VanessaE what's the target for the hash? 06:41 est31 I want to make a std::unordered_map 06:41 VanessaE recipes? 06:41 est31 yes 06:41 VanessaE oh 06:42 hmmmm eh 06:42 VanessaE idk, md5? :) 06:42 hmmmm est31, about that... I would hold off if I were you 06:42 est31 my idea would be xxhash 06:42 est31 why hmmmm? 06:42 hmmmm I make everything that should be a hashtable into a std::map, and then when the time comes to switch to C++11, we go through all instances of std::map and see if it's able to get changed to std::unordered_map 06:42 hmmmm and same with std::set 06:43 VanessaE *looks up xxhash* wow, that IS fast 06:43 hmmmm C++11 should be coming soon(tm) (we're waiting on debian, i think...) 06:43 est31 yea this month 06:43 hmmmm you serious? 06:43 est31 unordered_map is specified < c++11 06:43 VanessaE you sure deb stable will gain this? 06:44 VanessaE I mean without big reinstalls etc 06:45 hmmmm VanessaE: I don't really know... but once gcc 4.6 or newer is on all supported distros/platforms, there's no really good excuse for holding back as long as mingw works 06:45 hmmmm switch to C++11 if only for the speed gains 06:45 est31 or no, you are right, its c++1 only 06:45 VanessaE hmmmm: that's fair, it's just you know how long some hosts can take to update their stuff 06:45 est31 c++11* 06:45 hmmmm yeah... not 100% sure what the plan is 06:46 VanessaE when I was shopping around recently, I swear I was seeing places where Debian 6 was still being offered 06:46 est31 weird doc ----> http://en.cppreference.com/w/cpp/container/unordered_map 06:46 VanessaE (in addition to 7 of course) 06:46 est31 other doc, sais its > c++11 -------> http://www.cplusplus.com/reference/unordered_map/unordered_map/ 06:46 hmmmm huh? 06:47 hmmmm est31: the cppreference.com link has "(since C++11)" there 06:47 hmmmm in green, off to the right of the declaration 06:48 est31 yes, I thought it was only about the hash part 06:49 est31 would have been a very breaking way to introduce new params 06:49 jin_xi hm working on particles i noticed something 06:49 hmmmm agreed 06:49 jin_xi it seems like for every particle spawner that is expiring by itself we leak an id 06:49 est31 so then it will be a map 06:49 hmmmm figures as much 06:49 jin_xi so i wonder where to keep track of those on server side 06:49 est31 with a comment // change this to unordered_map when c++11 can be used 06:50 hmmmm in fact i'm pretty sure all of the current particle code had memory leaks 06:50 hmmmm merging that has to be my biggest regret so far 06:50 jin_xi here: https://github.com/minetest/minetest/blob/master/src/server.cpp#L2956 06:51 hmmmm that is so cringeworthy 06:51 jin_xi m_particlespawner_ids is only handled with explicit add and delete of spawners, as expiration happens only on clients 06:51 hmmmm i'm wondering if it's worth fixing particlespawners 06:52 hmmmm jin_xi, i think you should scrap the entire current implementation minus the network packet format 06:52 jin_xi thats what im doing 06:52 hmmmm thank you. 06:52 jin_xi still server needs to know spawners, mostly to give them unique ids 06:53 hmmmm hehehe 06:53 hmmmm :) 06:54 hmmmm I didn't get around to writing up the proposed design, but basically hud, particle spawners, formspecs, and sounds are four easy targets for client side modding 06:55 hmmmm the plan is to remove them from server-side completely, reimplement the current apis in lua, and use the ObjDefManager setup to manage them 06:56 jin_xi so i ignore this problem just as its being done now and work on other details 06:56 hmmmm well, no 06:56 hmmmm there's really no telling when client side modding will happen 06:57 jin_xi then i need help to come up with a solution 06:57 est31 vessels should be client side too. 06:57 jin_xi i would just increment a number and wrap on overflow... 06:57 hmmmm that's doable 06:57 hmmmm how big is the ID field? 06:58 hmmmm 32 bit in the Server:: methods, it seems, but I think it's incredibly inconsistent 06:58 hmmmm if I recall it's 16 bit inside the packets 07:01 jin_xi another highly annoying thing is that effin camera_offset 07:02 jin_xi i wonder what glitches thats fixing 07:03 VanessaE you mean the every-200-nodes thing? 07:04 VanessaE that was added to counter irrlicht rende rounding errors or some such, that used to happen once you get out more than about 2km from the map center. 07:04 VanessaE render* 07:06 nrzkt hmmmm: experienced the replacement of our JMutexAutoLock with std::lock_guard on a separate branch, that's okay. Replacing also JMutex with a JMutex: std::mutex works great too :) 07:06 hmmmm what? 07:07 jin_xi yes i know, but i wonder what kind of errors it caused. because the offset thing is not without its problems. 07:07 hmmmm I don't quite get what you mean by that, but std::mutex is C++11. 07:07 nrzkt yes, you talked about C++11 i see in the logs :p 07:07 jin_xi for one it breaks helicopter mod, attachments get torn and players teleported 07:07 nrzkt then i tell you i tested it with minetest core (and also i use it on my own server) 07:07 hmmmm nrzkt, I am glad it works great for you but I would much prefer that we don't make such a drastic change 07:08 hmmmm there are subtle differences we may not know about... not so with std::unordered_map 07:08 nrzkt the change is simple in fact 07:08 hmmmm one has much higher potential for disaster because its errors are subtle by nature 07:08 nrzkt i don't experienced std::unordered_map, only test std::mutex and std::lock_guard 07:08 hmmmm you thought changing std::list to std::vector was easy 07:08 hmmmm and look at how many bugs that caused 07:09 nrzkt because only the usage was wrong because i haven't read carefully one function, right 07:09 hmmmm it's not that simple. it's NEVER that simple! and we can't go around breaking things willy nilly because our upstream version must have some semblance of stability 07:09 hmmmm I am not going to rush things any more 07:10 nrzkt but i can tell you the std::mutex and std::lock_guard change can be done safely, i'm using in since ... 2 weeks on my server without any problem. I don't tell we must switch it 07:10 hmmmm if a huge change like that is going to rot away too quickly due to merge conflicts, well then, break it up into small pieces 07:10 nrzkt i tell this is possible, that's a little bit different :p 07:10 hmmmm I don't care how long you tested it on your own server 07:10 nrzkt and i don't care that you tell me te be slow, because i don't tell i will merge it into master. 07:10 hmmmm the network changes were tested for a MONTH on multiple peoples' servers and problems were still found 07:11 hmmmm nrzkt: I didn't quite understand your last sentence. are you saying that you're going to commit it without approval? 07:12 nrzkt hmmmm: wake up. You tell exactly the opposite 07:13 hmmmm erm... whatever. 07:13 nrzkt please reread what i said slowly 07:13 hmmmm I tried to and I didn't understand 07:13 VanessaE hmmmm: I think he means, "because i don't tell [you] i will merge it into master" 07:13 nrzkt i said: the switch is possible, i tested it. I don't say, i will merge it (soon or not). 07:14 hmmmm oh 07:14 hmmmm "I didn't ever say that I was going to merge it to upstream" 07:15 nrzkt my english isn't perfect, i know :p but i try to be understandable :p 07:15 hmmmm that particular sentence had subtle meanings. 07:15 nrzkt i'm not subtile 07:15 nrzkt simpler, faster, efficient :p 07:15 hmmmm yea... being subtle is necessary when we're trying to not break things 07:16 jin_xi so, some more questions, anyone knows what could cause textures to be upside down and black instead of transparent? 07:16 hmmmm jin_xi, try enable_clean_transparent = false 07:16 nrzkt in fact, when we are talking together, be subtle is not very efficient :p clear sentences are a good communication process 07:17 hmmmm well subtility is not good for purposes of communication 07:18 hmmmm being subtle when making code changes is 07:18 nrzkt only for politicians 07:18 hmmmm that's not subtility, that's doublespeak 07:18 hmmmm :/ 07:19 hmmmm so back to the original topic: I'm all for changing JMutexAutoLock, but don't do it all at once 07:19 hmmmm change one class at a time, gradually 07:19 nrzkt i will push a modified version of #2526, which only init the nodepos with static_spawnpoint value if set 07:19 ShadowBot https://github.com/minetest/minetest/issues/2526 -- findSpawnPos should use the static_spawnpoint to set the player position by nerzhul 07:20 hmmmm we already went through this when we switched from irrlicht containers to stl containers 07:20 nrzkt in fact hmmmm: we must change JMutex.Lock and JMutex.Unlock and add JMutex.lock and JMutex.unlock 07:20 hmmmm there was a lot of disasterous breakage and bugs galore because everything was done all at once and it was hard to track 07:20 nrzkt lock_guard is simple, it only call lock/unlock it's a stupid class 07:20 VanessaE nrzkt: er... why the upper/lowercase change? 07:21 nrzkt because of std::lock_guard 07:21 nrzkt if we have std::lock_guard 07:21 hmmmm btw 07:21 nrzkt the lock_guard will call JMutex.lock at creation and JMutex.unlock at destruction 07:21 hmmmm why make findSpawnPos a member of Server 07:22 nrzkt because only server call it 07:22 hmmmm if you're doing that, why not remove the map parameter 07:22 hmmmm and use m_map 07:22 nrzkt good idea :) 07:22 nrzkt m_map = m_env->getServerMap() , right ? 07:22 hmmmm yea 07:24 nrzkt we don't have ServerMap member in Server call 07:24 nrzkt but i will call the pointer into the function 07:26 nrzkt okay for https://github.com/nerzhul/minetest/commit/dbc739b6a584856155575dc4580709fc332da72b ? 07:26 hmmmm by the way, are you certain that static_spawnpoint doesn't have a default setting anywhere? 07:27 nrzkt ➜ minetest git:(master) ✗ grep -R "static_spawnpoint" src 07:27 nrzkt src/server.cpp: g_settings->getV3FNoEx("static_spawnpoint", nodeposf); 07:27 nrzkt src/server.cpp: // Default position is static_spawnpoint 07:27 hmmmm maybe it is being set in Lua, i don't know 07:27 hmmmm just checking 07:28 nrzkt http://pastie.org/10071244 07:29 hmmmm wwow good one 07:29 hmmmm this is why we review commits before we commit them 07:29 hmmmm you're copying the entire ServerMap 07:30 nrzkt that's right 07:30 hmmmm i think you forgot a & 07:30 nrzkt yeah, i'm adding it 07:31 hmmmm what is the desired behavior of static_spawnpoint exactly? 07:32 hmmmm isn't it supposed to override the random search for a spawnpoint? 07:32 nrzkt here this permit to fix in some rare cases player beeing teleported to 0,0,0 because of this function call 07:32 VanessaE always teleport the user there after death or on a new user sign-on 07:32 VanessaE simple. 07:32 nrzkt after death and new user, right 07:32 VanessaE it has no other purpose than that, in a vanilla setup. 07:32 hmmmm why don't you return immediately if getV3FNoEx("static_spawnpoint") returns true, then? 07:33 nrzkt it was the original PR 07:33 hmmmm i thought that's what we wanted 07:33 nrzkt but i don't know if we should do this or find a good place 07:33 nrzkt if you think we want this, okay for a return, like the original PR 07:33 hmmmm i don't know what we want 07:33 hmmmm i just want it to work 07:34 hmmmm it's up to you i guess 07:34 nrzkt here we doesn't have a player teleported to 0,0,0 if static_spawnpoint is set 07:34 nrzkt but we can have a random position after a respawn 07:35 nrzkt or, default, the static_spawnpoint. If the goal of static_spawnpoint is to spawn every time at spawn, then we return immediately. 07:35 nrzkt it's how i understand it 07:36 hmmmm that's how i understood it too 07:36 nrzkt then we will return directly 07:36 hmmmm but, unless i'm completely mistaken, that code in the PR doesn't do anything with static_spawnpoint since it gets overwritten by the random search loop 07:37 nrzkt but in some case the random search loop doesn't match 07:37 hmmmm oh yeah, I see those 07:37 hmmmm the two continue statements 07:37 nrzkt and we return a basic v3s16, with 0,0,0 07:38 hmmmm maybe this can be two separate settings 07:38 hmmmm fallback_spawnpoint and static_spawnpoint 07:38 hmmmm static_spawnpoint, if set, returns immediately with that static spawnpoint 07:38 hmmmm fallback_spawnpoint, on the other hand, is the default spawnpoint used if no suitable random spawnpoint can be found 07:38 hmmmm sound good or not? 07:39 nrzkt it could be good to add it in a separate commit, why not :) 07:39 hmmmm ok then 07:39 VanessaE hmmmm: well, if you could set one, why not just set the other?> 07:39 VanessaE I mean you as the user editing your config 07:40 nrzkt https://github.com/nerzhul/minetest/commit/3f8024330ae9d5f92418fa4b3025638d5a7e0b37 for the static_spawnpoint 07:40 VanessaE really, it just seems like overkill for a singleplayer instance - in a multiplayer server, you'll almost always have a static_spawnpoint set 07:41 jin_xi so regarding expiring spawners on server: where does such stuff go? regardless of how ids are done, server needs to keep track to free expired ones 07:43 jin_xi im thinking of a list of id and expiration time and a check, only wondering where this kind of housekeeping is done in server step 07:43 hmmmm well, I guess it could just scan for the lowest available ID 07:43 nrzkt a last review before a push hmmmm ? ^ 07:43 hmmmm nothing really does need to be fancy 07:43 hmmmm VanessaE: dunno, you as a server owner should make the decision on how you want the behavior to be 07:43 hmmmm nrzkt, looks good 07:44 VanessaE hmmmm: agreed - I'm just saying I don't think you'll see too many people actually using the feature. but ok 07:44 jin_xi hmmmm: exactly. i wonder where the right place to check time in server is as im not familiar 07:45 hmmmm wait, why do they need to expire after a certain time? 07:46 hmmmm isn't that the mod's decision to make it expire? forgive my ignorance i don't quite know how they work 07:46 ZeraRoox hmmmm Please check your private msg 07:46 hmmmm ZeraRoox: why are you private messaging me 07:46 hmmmm I don't check private messages btw 07:47 hmmmm just tell me here what it is 07:47 jin_xi yes, mods can have them expire with fixed time set. server makes spawner with id, passes to client, client handles expiration. -> id leaked and never reused 07:47 jin_xi thats current situation 07:47 hmmmm jin_xi, what kind of resolution does it need? 07:47 ZeraRoox When you have time check your email 07:48 hmmmm uh, okay 07:48 ZeraRoox is about a project 07:48 jin_xi hmmmm: not very precise, time is in seconds on lua side 07:49 hmmmm there's nothing fundamentally wrong with time(NULL) 07:49 hmmmm you could use that... 07:50 hmmmm you can't use irrlicht's timer because that's client-side 07:50 jin_xi ok and forgive my ignorance, but where is server step housekeeping done? 07:51 hmmmm lol 07:51 hmmmm in Server::step 07:51 hmmmm but I think what you're actually interested in is the environment's step 07:52 nrzkt Server::AsyncRunStep 07:52 nrzkt which calls Environment::step 07:52 hmmmm Particle spawners should be part of the Environment 07:52 jin_xi thanks. i thought putting particle spawners in 25 line server::step looked off 07:52 hmmmm at least in theory 07:53 hmmmm jin_xi, you should use dtime instead by the way 07:53 hmmmm instead of using other timers 07:54 jin_xi yes thats what i want to do. 07:54 VanessaE jin_xi: a note: there's a glitch with the expiration time, 07:54 VanessaE if set to zero, particles don't move. 07:55 jin_xi so my plan is to replace list of ids on serverside with list of struct with id and expiration time 07:55 jin_xi then properly expire expired ids 07:56 jin_xi VanessaE: is that on my PR or current glitch? 07:56 VanessaE it's a current thing 07:56 VanessaE not in your PR 07:56 VanessaE just mentioning it since you're fiddling around with the code. 07:56 jin_xi ok because all current rendering and stepping will be gone. im deleting this code 07:57 VanessaE thought you might want to take a look at it 07:57 VanessaE oh? 07:58 jin_xi anyways, this server id thing needs to be fixed regardless of particle rendering situation 07:59 VanessaE this is 2587? 07:59 jin_xi idk what bugs it may cause, but it accumulates some memory for every spawner deleted by expiration 08:00 jin_xi yes 08:00 VanessaE ok 08:00 VanessaE I'll leave you to it then 08:00 VanessaE sorry to interrupt 08:06 * VanessaE wanders off to bed, clearly too tired for rational thought :P 08:06 VanessaE night. 08:12 hmmmm it's past 4am, but i'm perfectly up and feeling at my best right about now 08:12 hmmmm there's something seriously wrong with me 08:27 Megaf Hi everyone 09:59 Megaf devs are never online when we need them 10:04 Megaf /home/minetest/minetest/src/irrlichttypes.h:34:22: fatal error: irrTypes.h: No such file or directory 10:05 Megaf cmake . -DRUN_IN_PLACE=1 -DBUILD_CLIENT=0 -DBUILD_SERVER=1 -DIRRLICHT_INCLUDE_DIR=/home/minetest/Deps/Irrlicht/ 10:05 Megaf minetest@mt:~/minetest$ find /home/minetest/Deps/Irrlicht/ | grep irrTypes.h 10:05 Megaf /home/minetest/Deps/Irrlicht/include/irrTypes.h 10:06 Megaf The file is there 10:06 Megaf help? 10:06 Megaf ^ Calinou VanessaE 10:06 Megaf fresh git clone from master 10:07 Megaf -- Could NOT find Irrlicht (missing: IRRLICHT_LIBRARY) 10:08 Megaf hm 10:14 sfan5 Megaf: by your logic -DIRRLICHT_INCLUDE_DIR=/ should also work 10:15 sfan5 Megaf: hint: you obviously need to point IRRLICHT_INCLUDE_DIR directly at the directory with irrTypes.h 10:15 Calinou yes, you forgot include/ 10:15 Megaf sfan5: I've been doing the very same way for three years... 10:15 sfan5 no 10:15 sfan5 this doesn't work and has never worked 10:16 sfan5 Megaf: -DIRRLICHT_SOURCE_DIR= could have worked though 10:16 sfan5 (IRRLICHT_INCLUDE_DIR vs IRRLICHT_SOURCE_DIR) 10:17 Megaf Ok, I have changed my cmake script in fact, let me see the old script that is know to work 10:17 Megaf known* 10:18 Megaf sfan5: anyway, it doesnt work when I point the include to /home/minetest/Deps/Irrlicht/include and source to /home/minetest/Deps/Irrlicht/ either 10:18 sfan5 what does it say when you point the include to /home/minetest/Deps/Irrlicht/include 10:21 Megaf This is in fact the line that I have been using for 3 years -DIRRLICHT_SOURCE_DIR=/home/minetest/Deps/Irrlicht/ 10:22 Megaf It worked till yesterday 10:22 Megaf now cmake says -- Could NOT find Irrlicht (missing: IRRLICHT_LIBRARY) 10:22 Megaf anyway, it's working again now 10:23 Megaf go figure 10:23 sfan5 it should work like that 10:23 sfan5 you don't need the library for server builds 10:23 Megaf I know, I attempted to include that because source wasnt working 10:25 Megaf sfan5: I think it was working yesterday because I had actually compile Irrlicht once, and today I removed the compiled version by a fresh source snapshot 10:26 sfan5 iirc irrlicht_source_dir only finds the library on windows 10:40 Megaf kilbith: my server is back online, thanks to sfan5. Join now and see if the bug is fixed, please. 10:44 kilbith Megaf, the public one ? 10:44 Megaf yep, the main on 10:44 Megaf one 10:44 Megaf mt.megaf.info 30003 or 8080 10:47 kilbith Megaf, this seems fixed now 10:47 Megaf cool 10:58 Megaf is there a way to make cmake/gcc optimze the binary as much as possible? For speed, not for size, runtime speed 10:58 Megaf or is that the same as optimizing for size/speed? 10:58 Megaf Compile time is not an issue 11:14 sfan5 Megaf: -DCMAKE_C_FLAGS="-O3 -march=native -mtune=native" -DCMAKE_CXX_FLAGS="-O3 -march=native -mtune=native" not that the resulting binary might not run on other processors 11:15 Megaf sfan5: I'd like to optimize my server, I do not intend to run it on other places 11:15 Megaf Thanks 11:27 Megaf sfan5: is not even compatible with its own CPU 11:27 Megaf $ bin/minetestserver 11:27 Megaf Illegal instruction 11:47 est31 Zeno`, what do you think? http://pastie.org/10071522 11:48 Zeno` I think it looks like a diff 11:49 Zeno` and that PAssword has a typo 11:50 Zeno` PASSWORD_SIZE * 2 ??? 11:51 est31 no idea why or how 11:52 est31 ah 11:53 est31 yes 11:53 est31 ofc 11:53 est31 first old password, then the new one 11:53 est31 and the first byte is already strippped 11:55 est31 I'll merge if you dont mind 11:55 est31 or push 11:57 Megaf !server Megaf 11:57 ShadowBot Megaf: server [--{name,address,ip,players,ping,port} ] 11:57 Megaf wrong channel, sorry 11:58 est31 do you agree? 11:59 Zeno` err you're removing just the errorstream thing? 11:59 est31 yes 12:00 Zeno` well it's not an error 12:00 Zeno` so yeah 12:00 est31 I can't find that "if nobody objects, then you can push minor stuff rule", so I dont know whether it only affects subsystem maintainers 12:01 Zeno` if it's a trivial fix just mention here that's you're going to do it, wait a bit, and push/merge 12:01 Zeno` that* 12:01 Zeno` I have nfi why that line is even there so, yeah, that would be a trivial change 12:03 est31 my theory is that its debug stuff which was forgotten to be removed 12:03 Zeno` even so it should have been verbosestream 12:03 Zeno` it's obviously wrong 12:07 est31 sfan5, can you give me (freshly promoted core-dev) a blue dot? 12:09 nrzkt est31: approved. 12:10 Zeno` lol I've already approved 12:10 Zeno` what is a blue dot? 12:10 nrzkt yes, i also approve it because it's on my network handlers :p 12:10 Zeno` oh 12:10 Zeno` +v 12:10 nrzkt but it's not necessary, it's very trivial :p 12:10 est31 yes 12:11 Zeno` no blue dot for you1 12:11 Zeno` hehe 12:11 est31 its bad because every time a user changes their password, the error is transmitted in public server chat 12:12 est31 "error" 12:12 Zeno` yes very bad 12:13 Zeno` hey, your first merge and you didn't stuff it up 12:13 Zeno` nice :P 12:13 est31 lol 12:13 Zeno` I am supposed to be in bed :( 12:14 Zeno` Doctor says I have influenza 12:14 Megaf That means, a simple flue 12:14 Megaf just dont move too much and drink plenty of water Zeno` 12:14 Zeno` you can die from the flu 12:14 Megaf flu* 12:15 Zeno` so I dunno if it's "simple" :P 12:15 Zeno` can I drink beer instead? 12:15 Megaf I'm afraid you can't 12:15 Megaf you can drink natural juices 12:16 Zeno` good, because I don't feel like moving or drinking beer anyway heh 12:16 Zeno` I' 12:16 Zeno` I'm outa here.. I can hardly think 12:16 Zeno` O/ 12:19 Megaf !up stuff 12:19 ShadowBot Megaf: Resolving stuff failed: [Errno -2] Name or service not known 12:38 sfan5 est31: there's your blue dot 12:53 est31 thanks 14:42 rubenwardy What technical things limit us to +/- 31,000? 14:43 rubenwardy Is it the size in bytes of position serials? 14:43 rubenwardy like, you'd have to break the blobs to increase the size. 14:46 est yea seems so 14:46 rubenwardy I guess it's a case of bigger serials means bigger maps but bigger file sizes. 14:47 est not neccessarily 14:47 est bigger maps I mean 14:47 est network will be a bit more verbose yes 14:47 rubenwardy So you have to compromise between bigger maps and bigger files 14:47 rubenwardy Really? 14:47 rubenwardy Yeah, networking would be a problem too. 14:48 rubenwardy It seems they currently use 2 bytes for each coordinate, so 6 bytes for the position serial. 14:48 est sorry got it wrong, maps will be bigger of course, but file sizes wont be 14:48 est I'm not sure though 14:48 est perhaps they will 14:49 rubenwardy Blobs don't store position serials, of course? It's just the fields for x/y/z in the MapBlock table 14:49 est yes 14:49 est usually, the mapblock table is referenced by serials 14:49 est inside the db 14:49 est and on the network I think too 14:50 rubenwardy #1845 hasn't been merged, so it's just one field for position, as a serial. Instead of three. 14:50 ShadowBot https://github.com/minetest/minetest/issues/1845 -- Split block position into separate fields in SQLite3 database by ShadowNinja 14:53 rubenwardy The current map size is fun for the majority of players, but not for making countries etc in game. 14:53 rubenwardy *fine 14:53 rubenwardy It's mostly just a willy waving competitions 15:29 Megaf rubenwardy: est: What is the technical problem/issue with infinite maps? Can't we just make it grow on demand? 15:31 est the problem is that node positions are stored in a value that has certain limits, and network protocol and other places need it to not exceed the limits 15:32 Megaf est: I understand that, but isnt Minecraft map infinite? 15:32 est it is definitely possible for players or mobs to walk around areas past the 30k, just no voxel world 15:35 Megaf hm, it is not 15:35 Megaf http://gaming.stackexchange.com/questions/19179/what-happens-when-you-reach-the-edge-of-the-world 15:35 Megaf first answer 15:37 rubenwardy In Minecraft, we should disregard range where is starts to get floating point errors 15:37 est how important is the feature that you can use aliases in craft recipes? 15:37 est should I try to retain it? 15:40 rubenwardy An older version of the food mod used it to add support, but no longer. It's probably best to - will it cause problems? Can you convert from alias to real when registering a recipe, and then there is no need to look it up in get craft recipes? 15:41 rubenwardy ie: no alias support in get_crafts(), but doesn't matter because aliases are removed in register_craft 15:42 est I'll try to retain it 15:46 rubenwardy So in Minecraft you can walk in one direction from spawn 1000x longer. 15:47 rubenwardy * shrugs * 15:48 Megaf rubenwardy: yep, but you can't go very deep 15:48 Megaf nor very high 15:49 Megaf anyway, I would really like to have a world 100000x100000x100000 instead of 32000x32000x32000 15:50 Megaf Is that (10^5)*3? 15:51 rubenwardy (10^5)^3 for the area 15:51 rubenwardy Horizontal distance is more useful than vertical, but having a limit of 255 is just taking the p. 15:52 rubenwardy It should be at least 5,000 to allow for nice layers 15:53 Megaf what if the max size of the world of limited by the CPU instruction? 15:53 rubenwardy huh 15:53 rubenwardy ? 15:53 * Megaf feels liek he doesnt know what he is talking about 15:53 kilbith do we *really* need more than 32K³ nodes ? biggest servers does not even have 10% of the map explored... 15:53 Megaf s/liek/like 15:53 kilbith better to focus on interconnected multi-worlds instead 15:53 Megaf kilbith: well, you'd be surprized the distance players walk on my server 15:54 kilbith and how is that useful ? 15:54 Megaf how useful is it to limit peoples urge to explore? 15:54 Megaf let them explore 15:55 Megaf and I do agree on interconnected worlds by the way 15:55 Megaf and I even have some idea on how would that be possible 15:55 sfan5 Megaf: how useful is it to break everyones existing maps 15:55 Megaf sfan5: no need to break... Just expand 15:55 Megaf keep the existing coord and add more 15:56 sfan5 the map format is not designed for that 15:56 sfan5 it would need conversion 15:57 rubenwardy The map size is sufficient for most uses, but not for big projects like real world maps. 32 KM isn't that much in real life. 15:57 est btw what do you imagine with the "interconnected worlds" thing? 15:57 Megaf rubenwardy: I was thinking about that actually 15:58 kilbith est, ask to RBA when he will be there 15:58 kilbith was in his plan 15:58 Megaf est: one very hacky way of doing it, and "very not good" is using a shared database by n servers 15:59 Megaf each server could have its own limits of map 15:59 Megaf within the global map 16:05 Megaf or they could just have their own database and send stuff to each other 16:06 Megaf each one could have its own 32K*3 map, the coord could be relative, 17:20 est why again are we serializing craft definitions? 17:20 est and whole managers 17:20 sfan5 how would we get them over the wire otherwise? 17:21 est and why do we do that? 17:21 est why do we do them at the other side? 17:21 est need* 17:22 sfan5 actually 17:22 sfan5 hm 17:23 sfan5 why does the client need craftdefs? 17:27 est https://github.com/minetest/minetest/blob/master/src/network/networkprotocol.h#L44 17:27 est my guess is it isn't used anymore 20:05 hmmmm fuwah! 20:05 hmmmm the weekend is here 20:05 hmmmm ha ha! time to minetest! 20:06 hmmmm I know how to solve the infinite map problem 20:06 Calinou then do it :P 20:06 hmmmm let's claim that our maps can from FLT_MIN to FLT_MAX 20:07 hmmmm and then the client will exponentially decay in performance the further it goes out from the origin, discouraging people from exploring 20:07 hmmmm s/exploring/teleporting to the borders/ 20:08 hmmmm that's basically what minecraft does anyway 20:08 Calinou but Minecraft behaves well until at least 100,000 20:14 hmmmm people don't typically build past 8000 20:15 hmmmm the more i think about it, the more i convince myself that making the limits higher is a gigantic waste of time and effort 20:15 hmmmm that number is for marketing 20:16 hmmmm it's like horsepower vs. torque. it's like the genesis being '64 bit' with 'blast processing' 20:16 kilbith agreed 20:36 est ^ 20:38 est even if, I would think that 2^32 is more than enough 20:38 est floats lose precision 20:39 est better a hard limit than "it begins to fail when the FPU starts to do weird things" 21:55 sofar well, you could pack 2^21 three times in 64 bit 21:55 sofar giving you a 4mln sized cube 22:01 ZeraRoox +hmmmm u there? 23:07 paramat > making the limits higher is a gigantic waste of time and effort < this 23:50 VanessaE marketing. 23:50 VanessaE map size is a function of marketing, not necessarily whether it's practical to actually *explore and build* that far away 23:51 VanessaE er not a function of, wrong word. meh, you know what I meant to say 23:53 VanessaE every checkmark you can put in your column that says your product is better than your competitor is a point you can bring up when trying to "sell" your product (regardless of whether money has to change hands).