Time Nick Message 00:05 PilzAdam Megaf, #1243 00:05 ShadowBot https://github.com/minetest/minetest/issues/1243 -- /clearobjects spams errrors 00:06 Megaf PilzAdam, what can we do about it? 00:09 Megaf now, how do I compile the sapier's android branch for android? 00:38 MegafODroid well, it still spamming the terminal 03:53 MegafODroid holly molly 03:53 MegafODroid I just made a really bad loop 03:53 MegafODroid using a not gate 03:53 MegafODroid what can I do now? 03:55 VanessaE_ uninstall mesecons, dig the offending node 03:55 VanessaE_ and figure out why it didn't overheat. 03:55 VanessaE_ and keep mod chat to #minetest 03:58 stormchaser3000 hey vanessa 03:58 stormchaser3000 have you ever seen this error? 03:58 stormchaser3000 22:25:19: ERROR[ConnectionSend]: con(6/1)RunTimeouts(): Peer 2 has timed out. (source=peer->timeout_counter) 03:58 VanessaE_ ask sapier about that one. 03:58 VanessaE_ I believe he and megaf here had to deal with that one 03:58 stormchaser3000 but sapier is not on 03:58 Anchakor heh I forgot I got this chan on autojoin 03:59 Anchakor how has minetest developed in past year or so? 04:03 MegafODroid VanessaE_: managed to take the not gate before the mod start running (restart the server) 04:03 VanessaE_ that works too 04:03 VanessaE_ but take this to #minetest 04:03 VanessaE_ this is not the place for it. 04:04 MegafODroid yep 04:04 MegafODroid stormchaser3000: that's a workaround we found 04:04 MegafODroid it means that a client disconnected and the server can reach it 04:05 stormchaser3000 hmmm 04:05 stormchaser3000 wierd 04:05 stormchaser3000 i can't use my server when that happens though 04:06 stormchaser3000 simaler to the draw hotbarr = NULL thing 04:06 MegafODroid stormchaser3000: hold on 04:06 VanessaE_ update your minetest build then 04:06 VanessaE_ all that shit has long since been fixed. 04:06 stormchaser3000 i just built a few hours ago 04:06 stormchaser3000 actualy like an hour ago 04:07 MegafODroid VanessaE_: that's a different thing 04:07 MegafODroid #1170 04:07 ShadowBot https://github.com/minetest/minetest/issues/1170 -- A few bind_address fixes by kahrl 04:08 VanessaE_ that doesn't seem related. 04:08 MegafODroid my problem was the #1231 04:08 ShadowBot https://github.com/minetest/minetest/issues/1231 -- ServerThread ServerEnv & Server::ProcessData() ERRORS 04:09 MegafODroid stormchaser3000: are you using ipv6: 04:09 MegafODroid ? 04:09 stormchaser3000 yeah 04:09 MegafODroid hm 04:10 MegafODroid stormchaser3000: pastebin a bit of the log 04:10 stormchaser3000 ok 04:12 stormchaser3000 http://pastebin.com/Kr9hgJeg 04:14 MegafODroid stormchaser3000: do you have a github account? 04:14 stormchaser3000 yeah 04:14 MegafODroid stormchaser3000: I mean, when that error is happening, that bit of log 04:14 MegafODroid oh wait 04:15 MegafODroid and you said you cant use you server when you get that error? 04:15 stormchaser3000 yeah 04:16 stormchaser3000 my client never makes it to the world 04:16 stormchaser3000 but downloads all the data 04:16 MegafODroid stormchaser3000: well, you can post a reply here https://github.com/minetest/minetest/pull/1170 04:17 MegafODroid describing very well what's going one, from whem is your git build and a link to pastebin 04:17 MegafODroid VanessaE_: or should he open a new issue? 04:17 VanessaE_ I'd say a whole new issue but .... 04:17 VanessaE_ too late. 04:19 stormchaser3000 ok done 04:20 MegafODroid stormchaser3000: you better talk to sapier tomorrow 04:21 VanessaE_ I was gonna ask for the full log of the "I can't get into my server after this point" event. 04:21 VanessaE_ because what you posted to that bug is, honestly, useless. 04:23 stormchaser3000 which i did post after 04:23 VanessaE_ nope.avi 04:23 VanessaE_ what you posted is basically one line worth of error. 04:23 stormchaser3000 look again 04:23 VanessaE_ where's the rest of the event? 04:24 stormchaser3000 i just posted a patebin 04:24 VanessaE_ I just did. 04:24 VanessaE_ you linked to this: http://pastebin.com/YN0xTGK5 04:24 VanessaE_ there's exactly one error shown there 04:24 VanessaE_ where's the rest of the event? 04:24 stormchaser3000 that is because that is the only error there is 04:25 VanessaE_ and why is the IRC mod loading *after* this error? 04:25 VanessaE_ (or connecting, rather) 04:25 VanessaE_ ditch the IRC mod and try again 04:26 stormchaser3000 bye i gtg 04:26 VanessaE_ ... 04:26 MegafODroid That's not good 04:26 * MegafODroid can see smoke comming from VanessaE's head 04:28 MegafODroid Good night VanessaE_ 11:28 RealBadAngel hi 11:29 RealBadAngel https://github.com/minetest/minetest/pull/1244 11:29 RealBadAngel any comments? 14:17 CiaranG Has anyone ever considered/worked on implementing non-axis-aligned collision box detection for entities? 14:42 celeron55 i am pretty sure no 14:43 celeron55 i think that would be a right point to pick a small physics library instead of exercising NIH 14:46 sfan5 NIH? 14:46 celeron55 http://en.wikipedia.org/wiki/Not_invented_here 14:46 CiaranG Well I'm not sure about that. It would be a minor addition to the existing code. 14:50 CiaranG Also, obviously the vast majority of collision boxes in minetest *are* axis-aligned. And for most of the remainder, it does't matter. So using a library that isn't optimised for that case would probably be a bad move. 15:45 sapier "CiaranG Has anyone ever considered/worked..." considered ... yes, really worked at it ... no 15:47 sapier stormchaser3000 the timeout error message was made visible recently but it's been there before too just at debug loglevel. basicaly it's telling your client doesn't respond for about 5 seconds and is dropped for that reason 15:51 ShadowNinja ~tell RealBadAngel 1244 seems good. 15:51 ShadowBot ShadowNinja: O.K. 15:56 ShadowNinja VanessaE_: The later IRC mod connection is intentional. It prevents server starts -> IRC mod connects -> other mod after IRC mod crashes -> script restarts server -> repeat loops, causing flooding. 15:59 sapier hmm so we don't know anything about that bug despite for some reason client times out 15:59 Anchakor has any progress by anyone (public on not) been done on moving minetest past minecraft-clone to its-own-game? 16:00 sapier once again what's the question? 16:04 ShadowNinja Anchakor: There are some games which are very different from MC. But by it's nature MT can't be made very different. 16:05 sapier can someone please check #1240 ... If noone complains I'm gonna merge it in a couple of hours. I know it may cause trouble if I missed something but the current way of doing it causes even more strange issues. So please READ the code and try to find bugs in there. 16:06 ShadowBot https://github.com/minetest/minetest/issues/1240 -- Fix broken local formspec handling by sapier 16:06 Calinou Minetest is not a Minecraft clone, Anchakor 16:06 sapier Calinou: :-) that's what everyone tells, but without additional information it's quite hard to understand. 16:07 Calinou it's a bad generalization 16:07 sapier The additional information I talk about is minetest not beeing a game at all but only an engine. The games themself define if it's a clone or something different. 16:07 Calinou hence, don't call it a Minecraft clone, for Sam's sake (:D) 16:08 sapier guess if someone wants to do clone minecraft there might be little difference 16:09 Calinou there are games that try doing it like realtest 16:09 Anchakor well the point of the game is the same no? build awesome shit from blocks with other people 16:09 Calinou both games have no real goals, but Minecraft has some "end" (a fairly bad one...) and there's more activities to do 16:09 sapier as of my pov the game is writing/improving the engine ;-) 16:10 Calinou Minecraft servers have more varied objectives 16:10 Anchakor I'm instested in some adventure mode gameplay, like roguelikes 16:10 Calinou (eg. "Hardcore" PvP, I almost never saw that on Minetest) 16:10 sapier Anchakor following this logic any third person shooter would be a doom clone ;-) 16:11 Anchakor sapier: they are, but later there was too many and it was necessary to classify them more properly :) 16:11 sapier minetest provides a scripting api you're free to write a game like the one you requested 16:11 Anchakor I know 16:12 Anchakor I want to know if anyone has done / is trying to do with MT engine something else then a building game 16:13 sapier I suggest asking this at minetest (if you didn't already do it) 16:21 celeron55 actually it's not trivial to write a game like that using minetest 16:21 celeron55 i'm guessing roguelikes have a more active world than what the engine currently is locked to do 16:22 celeron55 or, like, it's unable to really run anything in the world outside of the player's close range 16:23 sapier but does it really need to do those things immediatly? 16:23 celeron55 adding something that allows for a game to do something like that in some reasonable way will be accepted 16:23 celeron55 if the things move around, then yes 16:23 celeron55 otherwise they won't affect anything along their path 16:24 celeron55 or do something else that can have global effects 16:24 sapier so you're actually talking about the forceload entities that are requested every now and then 16:24 celeron55 and global effects implies that the world probably has to have a limited size in that usage 16:24 celeron55 sapier: it's part of it, kind of; but simply forceloading entities may require too much processing 16:24 celeron55 there's designing to do 16:25 sapier well you can "emulate" quite a lot of things by using global step and external data storage but yes that's gonna be quite complex 16:26 celeron55 Anchakor: you may already guess but i did start a project that *actually* involves a bit of something else, but i freezed the project quite quickly because i have to focus on my main project (which is not minetest nor minetest-related) 16:27 twoelk couldn't some NPC's be designed as bots that use some basic client of their own? Maybe having some sort of authentification that shows they come from the game and not from outside. 16:27 Anchakor celeron55: cool, will keep an eye for that 16:28 celeron55 twoelk: that's a huge overhead 16:29 sapier twoelk basicaly mobf mobs built from forceload entities would be almost exactly what you request (without causing the network overhead) 16:29 celeron55 twoelk: you're limited to same amount of them as there are players and even less due to running the clients 16:29 sapier yes celeron but that's true for all active entties 16:29 sapier active as of doing things themselfs 16:30 twoelk I don't think that usefull for a herd of sheep but rather for maybe five or so enemies of a shooter type game 16:31 sapier hmm e.g. if you've got some archers and guards attacking a player? 16:31 twoelk sort of 16:31 sapier that's already possible ;-) 16:32 twoelk so the mob/npc can traverse terrain not generated by my client but on its own right 16:33 sapier they're not very smart but yes for terrain not beeing to complex they can 16:33 twoelk so we need a game that showcases that 16:34 twoelk game as in minetest subbgame 16:34 sapier but quite less people did try this by now so expect some bugs in there 16:36 twoelk I guess making them smarter (process more code) will make them perform slower 16:36 ShadowNinja hmmmm: It seems that MGv6 ignores the caves/nocaves flags. 16:37 sapier yes twoelk that's the basic problem, more smart usually causes more load and as long as mods have to do all their processing within server step this increases lag 16:38 sapier guess I'm gonna make async api available for mods soon 16:38 twoelk eh? so we need to find a way to bypass server step 16:39 sapier basically yes ... but we need to keep in sync to it too so it's a little bit tricky 16:40 sapier any comments to #1241? it's supposed to cleanup mainmenu and provide base for simplified android menu 16:40 ShadowBot https://github.com/minetest/minetest/issues/1241 -- Add formspec toolkit and refactor mainmenu to use it by sapier 16:41 twoelk maybe prediction and analysis should be done in several parallel threads with a junk collection of sorts to get rid of threads not used as dessision went another thread 16:42 sapier problem isn't the prediction and analysis itself but all of it needs map access ... that's the bottleneck 16:43 sapier of course analysis can be done smart or stupid too but as long as it's part of server step that's not a difference 16:45 twoelk I dont knoso a mod can never disconnect from the pulse the server supplies? 16:46 sapier not yet 16:46 twoelk -i dont kno 16:46 twoelk so this is where the bot jumps in 16:46 sapier no 16:47 sapier a bot is some external thing that's why you have to run through full network stack causing way more overhead then necessary 16:47 twoelk grrr 16:47 sapier of course you can do it with a bot, no question 16:47 sapier but imho this isn't best way to do it 16:48 twoelk although if I have one bot that moves several mobs from the same connection? 16:48 sapier can't be done 16:49 sapier one connection one player/bot 16:49 twoelk it definitly is the wrong way to do it! The best way would be to write that into the engine, but I dont see that any time soon 16:50 sapier you'd be surprised how much of that work is already done 16:50 twoelk well not "that" but some sollution 16:50 twoelk oh 16:50 sapier async is there, just not enabled for mod api 16:50 twoelk hope appears on the horizon 16:50 sapier yes it's not gonna provide full set of features 16:51 sapier e.g. map modification has to be done from server step by now 17:00 twoelk I'm still wondering wether the quasi physical map and the semi sapient entities should not be processes of their own, working each in their own container of som sort. Maybe not as complete botclient but something that can crash and not take down the map with it and yet not jumping through the big loop of a full network stack but coming from somewhere closer. 17:01 sapier if async operation would gain map access you'd have exactly this but I don't wanna predict how much overhead map locking would cause in this scenario 17:10 ShadowNinja Pushing soon: http://sprunge.us/TZPe?diff 17:10 twoelk actually if the mapper could connect to minetest as some client it would be possible to make maps while the world is running, maybe there are other uses for a sort of client access that 3rd party programs can use 17:12 sapier better not do that twoelk, mapper would cause full map to be generated ;-) 17:12 twoelk oops 17:12 sapier 64kx64kx64k nodes ;-) 17:12 twoelk need avoid_unloaded function 17:13 sapier that's forceload ;-) 17:13 sapier wait 17:13 sapier misread your message 17:13 sapier but there's no usecase for that feature except of mapper 17:14 twoelk at the moment, offer it and someone will find more uses :-P 17:15 sapier so we provide a feature to double map size requirement because of someone may find a way to use it? ;-) 17:15 twoelk actually zombies could avoid unloaded areas as there are no players to eat there 17:15 sapier zombies wont even exist there because unloaded areas aren't loaded ;-) 17:16 twoelk ? why would that double the size? 17:16 sapier that's been a suggestion for a new completely unrelated feature 17:16 * twoelk is rereading what was said 17:17 sapier as you said once provided someone will find a usecase for it ;-) 17:17 sapier because I don't know of what use a feature to double map size requirement could be :-) 17:18 sapier imho mapping should be done on server 17:18 twoelk ok I want my program to avoid unloaded area so to not generate new chunks.....why does that make the map bigger? 17:19 sapier the feature "double map size" is not related to your feature unload area ;-) 17:20 * twoelk is confused, must have missed something 17:20 sapier *g* 17:20 sapier well maybe I haven't written it in best way 17:20 sapier I was aiming at your request to add a feature without a real usecase 17:21 sapier minetest is suposed to be a game engine not a map database 17:21 twoelk well then I request fancy smart cars for everyone 17:22 twoelk no the map database is a sqlite file 17:22 sapier a feature to not load blocks from a client would be only usefull for a single (argueable) usecase ... and it's quite a lot of work to provide it 17:22 twoelk minetest is a database server, in parts, at the moment 17:23 sapier nope 17:23 sapier minetest uses a database 17:23 sapier it's just gonna send to client what client needs to know 17:23 twoelk that is why the mapper is not allowed to read the database, because minetest has read/write access when running 17:24 sapier yes ... but you should do a backup by time anyway so mapper could run when doing that backup 17:24 sapier and for client maps client could build them upon it's cache which most likely is what user needs to know anyway 17:25 twoelk sqlite allows only one user at a time, in our case this is a server that channels several clients into a single user process, if I understood sqlite correctly 17:25 sapier if you wanna do a backup you need to stop server anyway 17:26 twoelk gah you cant write while I#m typing :-D 17:56 RealBadAngel so, going to push 1244 now 18:03 sapier ok 18:07 RealBadAngel done. i am browsing now old issues and checkin whats worth merging whats closing 18:08 sapier I'm merging 1240 as noone wants to check it anyway and current code is quite broken 18:08 sapier noone except blockmen 18:09 RealBadAngel its too complex to just read and say its ok 18:09 sapier I know that's why it's important to read and at least confirm it's not obviously wrong 18:10 sapier the old bug wasn't seen by anyone for weeks ... yet it's quite obvious once you know where to look 18:10 BlockMen RealBadAngel, http://dev.minetest.net/Git_Guidelines point 2. 18:11 RealBadAngel BlockMen, https://github.com/minetest/minetest/pull/795 18:11 RealBadAngel i wasnt original author of it 18:11 BlockMen git rebase? 18:12 BlockMen you can rename commits 18:12 sfan5 you can use git commit --amend to rename itr 18:12 sfan5 -r 18:13 RealBadAngel i will remember that 18:33 RealBadAngel also, going to push https://github.com/minetest/minetest/pull/1237 18:33 RealBadAngel metaducky is right 18:46 ShadowNinja twoelk: The C++ mapper works while the world is running, although it's a bit slower since it has to wait for the server to release any locks it sets. 19:05 sapier I'm gonna merge #1240 now and then I'm gonna duck and wait for bugreports ;-) 19:06 ShadowBot https://github.com/minetest/minetest/issues/1240 -- Fix broken local formspec handling by sapier 19:45 twoelk ShadowNinja: I could have sworn... now when was that fixed ... bah talking rubbish 'cause I'm not up to date. 19:47 ShadowNinja twoelk: Be carefull though, I don't know if Minetest handles SQLITE_BUSY well. 19:48 Megaf sapier: don't 19:48 Megaf did you do it already? 19:49 sapier yes 19:49 sapier what's wrong? 19:51 Megaf Uh, nothing, I would test it for you before you merge, but that's a bug on the windows build, so I can't thest 19:52 sapier well the actual bug was on linux too but it didn't happen to cause an error (by now) 20:24 Megaf sapier: Wher's the apk? 20:24 sapier I knew I did forget something 20:28 Megaf sapier: If you could publish somewhere on how to build mientest for android thet would be great. I got the whole android SDK plus emulators en Eclipse already 20:29 Megaf and I managed to export apps to my android phone too 20:29 sapier build/android and then enter make 20:29 Megaf Or write very briefly and I write a tutorial 20:29 Megaf is that simple? 20:30 sapier almost 20:30 sapier you need to have sdk as well as ndk somewhere on disk, make will ask you on first run where to find the 20:30 sapier m 20:31 sapier it's only tested for arm by now 20:31 Megaf ok 20:31 sapier guess to build x86 android makefile requires some adjustments 20:31 Megaf right 20:31 Megaf I will see that when I get home 20:32 sapier there's some portability code in there but it's not complete 20:33 Megaf I'm checking the code, looks cool 20:34 sapier for some of the makefiles you can specify the build architecture but it's not done for all 20:37 sapier http://animalsmod.comuf.com/downloads/Minetest-debug.apk link for everyone who doesn't want to compile 20:38 sapier I've already managed to merge (or at least split to independent commits) most of the andorid changes 20:38 sapier remaining code is almost completely separated from core 21:30 hmmmm you know, what if the mod model needs to be fundamentally reinvented 21:30 VanessaE_ oh G8d 21:30 hmmmm instead of having mods process things in the server step, what if there was a separate mod thread 21:30 VanessaE_ G*d 21:31 VanessaE_ well 21:31 VanessaE_ many have been proposing just that 21:31 VanessaE_ but that would be fundamentally hard to do 21:31 VanessaE_ and it would probably break LOTS of things 21:31 VanessaE_ it's a good idea though 21:31 hmmmm any sufficiently good innovation would need to break things 21:32 VanessaE_ true 21:33 VanessaE_ it *would* finally solve the core issue of mods just plain locking up the server 21:34 VanessaE_ (mostly) 21:34 VanessaE_ though that would require introducing locks or so 21:35 VanessaE_ and I guess it was decided that modders couldn't be trusted with that 21:36 hmmmm well the idea is to have a queue of pending mod actions and every server step those will be performed 21:37 hmmmm only big problem i can forsee is fighting for access of the map for reads 21:37 hmmmm what if map access was done with some kind of async io 21:37 hmmmm Lua can do closures, right? 21:37 hmmmm so it doesn't even need to be callback based 21:37 VanessaE_ it can but I don't understand how they work. 21:38 VanessaE_ (that's one programming concept I've never quite gotten my head around) 21:38 VanessaE_ now as for read access, what about read priorities instead? 21:38 VanessaE_ async like you are thinking, but with stacked priority 21:39 hmmmm well the priority would be the hundred million things that need it inside of server thread 21:39 hmmmm if serverthread wants to read map, it locks it, but a mod wanted to read the map as well, so you still get the same sort of laggyness 21:39 hmmmm ...it's just that instead of being lualocked it'll be waiting on a maplock 21:39 VanessaE_ like if two processes ask for this one node at the same time, and no priority is set, well then the result would be first come first served (random, probably). if a mod asks the engine for priority access to the node, then it gets first crack at it. 21:40 hmmmm it's not that simple. 21:40 VanessaE_ hm. 21:40 VanessaE_ well I suppose it wouldn't be particularly simple, no 21:41 VanessaE_ but the reason it was decided against doing some kind of multithreaded Lua was just exactly this issue, of multiple mods potentially reading or writing the same node or mapblock at the same server step 21:41 VanessaE_ or so I thought 21:42 VanessaE_ and that can only be solved either by locking or by some kind of priority system (even if it's static) 21:44 VanessaE_ (I'm counting one Lua thread versus the engine as "multithreaded" for this discussion) 21:44 sapier hmmm you don't need to reinvent full moding api if you stick to async engine ...yet the map locking issue will still be there 21:44 VanessaE_ (because it'll eventually lead to truly multithreaded Lua eventually) 21:45 sapier lua isn't capable of doing multithreading, no chance to get this done 21:46 VanessaE_ (also I work for the Department of Redundancy Dept. at the Bureau of Excess Parenthesis) 21:46 VanessaE_ sapier: it isn't right now, no. But anything is possible in the future. 21:46 sapier well if you intend to rewrite a multithreaded lua interpreter maybe 21:47 VanessaE_ in the old days, we called it multitasking/multithreading even if all you had was a couple of IRQ sources to drive your threading engine. 21:47 sapier imho providing a callback based async mechanism is way more promissing 21:48 VanessaE_ so it's really a matter of terminology, if you'd rather call it async, even if the effect is the same (two or more Lua mods seem to run concurrently), then that's fine. 21:48 sapier no it's not the mods running concurrently it's only jobs requested by lua mods 21:48 VanessaE_ I know. 21:49 VanessaE_ I'm talking about the effect the end-user sees. 21:49 sapier it's only gonna help for some classes of tasks to be done, you wont get a mob to react to a punch this way 21:49 VanessaE_ true. 21:49 sapier but you can make a mob find a path in parallel to other things 21:50 sapier or a spawn algorithm find a suitable position 21:50 sapier or mapgend generating map 21:50 VanessaE_ indeed. 21:51 VanessaE_ send moretrees/plantslib off to populate a block while the rest of the system goes on to generate another block, etc. 21:51 VanessaE_ (without having to resort to saplings mode) 21:51 sapier for example 21:52 VanessaE_ hmmmm is right though that Lua needs to be more "detatched" from the engine 21:52 sapier yes 21:53 sapier but main issue isn't game but map 21:53 VanessaE_ yeah 21:53 sapier we need to enable it to read data without needing to lock it 21:53 sapier once this is done async calls could be allowed to do read operations only resulting in asny things not blocking server 21:54 VanessaE_ but here's the thing, if Lua's running in it's own thread, it's still gonna be event-based, right? 21:55 sapier of course 21:55 sapier what else? 21:55 VanessaE_ that means mapgen callbacks of some kind. So what *would* lock the map? 21:55 VanessaE_ in other words, what would be left to solve at that point? 21:56 sapier well the async threads could access map at any time while server thread (with it's own lua instance) does other callbacks 21:56 VanessaE_ (I'm ignoring just for the moment, hmmmm's idea of queueing up Lua events) 21:56 sapier that'd be a problem 21:56 VanessaE_ right. 21:57 sapier well async jobs are queued anyway 21:57 sapier you can see this if you enter modstore in mainmenu 21:59 sapier hmmmm making async available for mods is quite a minor patch, the big deal is providing safe map access 22:00 VanessaE_ that begs the question: 22:00 VanessaE_ what's the absolute worst thing that can happen if it's left "unsafe"? 22:00 sapier total corruption of internal game data 22:00 VanessaE_ suppose you just randomly opened up async access to all, with access to the map through the usual ..... oh 22:01 VanessaE_ "Okay, that's bad. Important safety tip, thanks Sapier." 22:01 sapier in best case player actions are only lost, in worst case whole database is messed up 22:01 VanessaE_ wait a second here... 22:01 VanessaE_ just how low-level is the access? 22:02 sapier depends, if our database backend does proper locking (I assume it doesn't) we may only get a deadlock 22:02 * twoelk 's discussion topic scanner locks in on something promising 22:02 VanessaE_ well that's what I mean...modders don't need access to nearly THAT low level 22:03 VanessaE_ (and anyway a modder could delete a server's map.sqlite anyway) 22:03 sapier it's not what modders need it's what you need to do to get that data 22:03 sapier if you set a node from multiple async threads as well as main server thread, result will be undefined 22:04 VanessaE_ well the obvious case there is that each of those threads should write the database and whatever was last written is what takes effect. 22:04 sapier in best case db is consistent at last one to set it, in worst case (without db backend having proper locking) internal db data is corrupted 22:04 VanessaE_ if "undefined" is possible, then it's badly written. 22:05 VanessaE_ but that's something that happens at a level lower than what the modder is coding at. 22:05 VanessaE_ that's what I'm talking about 22:05 VanessaE_ what the modder is *supposed* to have access to 22:05 sapier yes but the modder is able to cause it 22:06 VanessaE_ yes, but that would suggest a bug in the database code, not in the Lua interpreter etc. 22:06 sapier no 22:06 VanessaE_ yes 22:06 sapier if database code is not supposed to be used multithreaded it's not abug 22:06 VanessaE_ the modder doesn't have access to the database (even vmanip doesn't get *that* close) 22:06 sapier same as a lua stack isn't meant to be handled by different threads 22:07 VanessaE_ which means if you open up async access, you have to harden the database engine against it. 22:07 VanessaE_ failing to do so would be a bug 22:07 VanessaE_ that's not really the same thing as, say, failing to lock some API function such as set_node() 22:07 sapier of course we can add our own locks in upper layer ... that's most likely what we need to do but that's the tricky thing if we do it wrong we don't get any performance gain in good case and deadlocks in bad 22:08 VanessaE_ well the idea isn't necessarily a performance gain as much as *consistent* performance. 22:08 VanessaE_ *however* 22:09 VanessaE_ if you have multiple cores, and you really *are* running Lua on its own thead as far as the CPU is concerned, then there surely will be a performance gain 22:09 sapier in case of server thread waiting for a lock taken by async we dont win anything 22:09 VanessaE_ right 22:10 VanessaE_ the idea with async is to stop a multi-second lockup because of some slow-by-necessity mod from lagging two dozen users :) 22:10 sapier lua isn't anything to run, it's just a language to do things, think of it as core functions as of threading the only difference to c++ functions is their data is limited to a single thread only 22:10 VanessaE_ when I say Lua in that context, I mean the interpreter :P 22:11 sapier well of course we could do locking to make sure a single thread can access a lua context by time only 22:11 VanessaE_ the code that runs the code, don't split hairs 22:12 sapier no it's not even a interpreter activity is still core itself, there's no magical transition to lua the one doing is still the one doing core code 22:12 VanessaE_ mmm, true 22:13 sapier think of some worker switching tools once he's doing it with c++ next time with lua 22:13 VanessaE_ I get tha 22:13 VanessaE_ that* 22:13 VanessaE_ though some would say the time it takes to switch tools is pretty horrendous :P 22:13 VanessaE_ the idea here is to give the worker a couple more hands 22:13 sapier while the lua tool can be used by a single worker per time only while c++ could be used by multiple workers 22:14 sapier as long as those c++ workers don't try to use same c++ tool handles 22:14 VanessaE_ at any rate, I better shut up now 22:15 sapier well my suggestion is adding more lua tools and workers ... but to get this done you have to package work and pass it from one worker to another 22:16 twoelk and have some coordinater with fixed rules ;-) 22:16 sapier yes 22:16 sapier but the additional lua tools can't do all of those things the current lua tool can do 22:16 sapier so only special types of work can be packaged 22:17 twoelk maybe that expertize is not needed for every job 22:18 sapier that's what I'm hoping ... an doing it this way we can implement the additional tools quite simple and improve them step by step 22:18 twoelk interacting with nodes may be different to just moving around 22:18 sapier I assume this to be way less error prone then rewriting all at once 22:21 sapier but first I wanna merge android port ;-) 22:22 twoelk have let my niece try a debug apk version on her new smartphone 22:22 twoelk water looked wierd 22:23 sapier well android devices aren't as fast as pc's so all fancy stuff is turned off 22:23 twoelk but movements looked a lot smoother than on my pc 22:23 sapier you can disable all of those things in settings too ;-) 22:24 twoelk let me reword: water looked so wierd I did not recognize it as water 22:24 sapier it's not transparent there 22:25 twoelk and strange color. not blueish at all but some dirty grey 22:25 twoelk might be here device though 22:25 sapier ok that's strange 22:27 twoelk I dont use a smartphone, so I cant investigate and she is not into testing things 22:30 twoelk I did notice though that I could hardly read any text. I would definitly have to change some settings concerning that if I were to play 22:30 twoelk too late 23:39 hmmmm the solution here is and always was RCU 23:40 hmmmm the fundamental problem is that the map is this simply gigantic lock 23:40 hmmmm and everybody needs it 23:46 VanessaE_ mmh 23:48 VanessaE_ well I guess as long as it's fast. 23:49 VanessaE_ (I had to look up RCU. I've used that back in the stone age, but we didn't call it that back then) 23:49 VanessaE_ (or something similar anyway)