Time  Nick         Message
00:17 ShadowNinja  iqualfragile: bool?
00:17 iqualfragile ShadowNinja: :D looks like i was a bit too generic: mesecons-like on and off
00:18 iqualfragile so a node can have two states (on and off) and those can be changed without lots of effort
00:18 ShadowNinja  Ah.
00:20 iqualfragile its more or less impossible to have 4 treefarms run i paralel on a server
01:54 iqualfragile bug: when trees grow the will not replace flowing water
04:12 cheapie      Is there anybody here that is somewhat high up in the Technic project? I have a pull request for you.
04:14 Miner_48er   could try #minetest-technic
04:14 cheapie      OK.
07:53 sapier       iqualfragile I understand that this could be very helpfull for mesecons, but imho adding a on/off state to nodes is somehow messing up nodes to entities, nodes are static non changing objects, nothing except their id is stored. We already have one special case "inventories", as far as I know they're not stored within node but separate by position (correct me if I'm wrong). Adding that on/off state will therefore require to break map for
07:59 VanessaE     sapier: actually to be fair I've run into numerous places where I wished there indeed were proper "on/off" states
07:59 VanessaE     but a lot can change between the "on" and the "off" state of a node to make that more or less impractical
07:59 sapier       I don't say they aren't usefull, it's just where to stopp adding entity features to nodes?
07:59 VanessaE     stop at the point where nodes can move freely ;)
08:00 VanessaE     then it's no longer a node ;)
08:00 sapier       that's not very usefull as this would mean each node would be able to run lua scripts on it's own ;-)
08:00 VanessaE     ok ok smartass :)
08:00 VanessaE     not THAT far then
08:01 VanessaE     I could see arguments for node models, on/off states, even damage/health amounts
08:01 VanessaE     perhaps other things
08:01 VanessaE     but beyond that, no
08:02 sapier       right now the difference between nodes and entities is that nodes are merely not distinguishable instances of a base class. While each entity is a unique element
08:02 sapier       for on/off state you can just use two different nodes
08:02 VanessaE     maybe inside the engine, but remember to a modder, there's a pretty significant difference, in the way they behave and just what you can or can't do with a node vs. an entity
08:03 VanessaE     sapier: right, and that's what I do.
08:04 sapier       no the effects resulting from that basic difference are far from small
08:04 VanessaE     I think what iq wants (and this is what I'd lean toward) is something like minetest.set_node(pos, {name = "foo", state = "off"}) without having to explicitly call for the on or off node by name.
08:04 VanessaE     "a pretty significant" = "a large"
08:04 sapier       I didn't intend to tell entities and nodes are anything comparable ;-)
08:04 VanessaE     I was agreeing with you, the differences are large.
08:05 VanessaE     however,
08:05 VanessaE     there'd be no real gain
08:06 VanessaE     one could just as easily set_node(pos, {name = "foo_"..state})
08:06 VanessaE     so I don't see what he's getting at that we can't already do
08:06 sapier       I don't see the actuall use of this function, either we change map format making each node unique by adding the on/off flag to map. Or we store that information separatly ... resulting in douling map size in worst case
08:07 sapier       ok :) reading prior completing sentence would be good :-)
08:08 VanessaE     that would help :)
08:08 VanessaE     reading comprehension FAIL :)
08:10 VanessaE     now, on topic:
08:10 VanessaE     I'm getting some reports of users having trouble connecting.
08:10 VanessaE     or more to the point,
08:10 VanessaE     they connect, get media, can chat,
08:10 VanessaE     but the map sometimes doesn't load.
08:10 VanessaE     I tell them to re-connect, it loads.
08:10 VanessaE     these are all folks who use 0.4.9-release or earlier
08:10 VanessaE     so probably the same issues we've discussed before.
08:11 VanessaE     (it's never a problem for me since I'm at git HEAD)
08:12 sapier       Yes according to description this seems to be same issue
08:14 VanessaE     sounds like it might be a good idea to push another release right away
08:14 VanessaE     if that possible.
08:14 VanessaE     that's*
08:14 VanessaE     maybe just call it 0.4.9.1 or something
08:15 sapier       a release would mean we think it's stable but I'm not convinced about this by now
08:15 VanessaE     fair enough
08:20 sapier       interesting about 10% of prollers freeminer changes are about tuning connection parameters to fit his current network state
08:24 sapier       but could be less as some are at least twice in history
08:41 sapier       on the other hand the profiler and arm fixes seem to be quite interesting
08:49 celeron55    sapier: it's already possible to store any value within a node instance using node metadata
08:49 sapier       it is? hmm so we wouldn't even have to add anything?
08:49 celeron55    if it's too slow or otherwise unusable for mesecons, then there might be a reason for optimizing it
08:49 sapier       ok
08:49 celeron55    or adding something
08:50 sapier       I guess metadata are stored separate from node itself?
08:50 celeron55    actually, i think the problem is that you can't make the node look different by using the metadata
08:51 celeron55    there has been talk about that, and making that generically possible leads to a much more heavy system than just replacing the node for different states
08:51 sapier       because it'd require engine to check for metadata on each draw
08:51 sapier       ?
08:51 celeron55    sapier: yes, there is a container for metadata in each block
08:51 sapier       sounds almost like entities ;-)
08:53 sapier       VanessaE do we have still entity duplication issues?
08:55 VanessaE     I'm not sure
08:55 VanessaE     I removed most of the mobs from my servers.
08:55 sapier       would be interesting as we could increase the limit if we don't have them anymore
08:55 VanessaE     they caused too much lag due to too much network bandwidth usage
08:55 VanessaE     (simple mobs spams 30 kB/sec per user)
08:56 sapier       is this same for mobf?
08:58 VanessaE     I'm not sure, I removed that one before anyone had a chance to report the usage
08:59 VanessaE     consider that 30 kB/sec to be non-authoritative for now, but it seems believable
08:59 sapier       true, I remember seeing a lot of object updates in wireshark on doing protocol fixes too. I'm not sure if all of them are required but I didn't investigate
09:04 celeron55    it would seem there shouldn't be so much consumption as mobs usually stand still
09:04 VanessaE     nope.avi
09:04 celeron55    or i guess that depends on the mo
09:04 celeron55    +b
09:04 VanessaE     simple mobs are constantly walking around
09:04 VanessaE     in fact they almost never stand still
09:05 celeron55    what kind of object counts were you seeing? it's visible in the profiler
09:05 VanessaE     you'd have to ask cheapie on that one
09:06 VanessaE     though I doubt he looked
09:06 VanessaE     however,
09:06 sapier       but even if they're moving as far as I know simplemobs sets speed and doesn't update position
09:06 celeron55    anyway, entity-specific bandwidth measurement wouldn't be hard to add, as each entity knows on the C++ side what it's registered name is
09:06 sapier       I can only tell for mobf celeron but there it's usualy around 50
09:06 VanessaE     I usually saw numbers in the sub-100 range after a clearobjects, once I'd restored all the signs and such and had given the mobs time to respawn.
09:06 celeron55    its*
09:07 VanessaE     (in the survival server that is.  recall signs, item_frames, pedestals, and pipeworks all use entities)
09:07 VanessaE     for me, 30 kB/sec is a drop in the bucket.  that's less than 1% of my peak bandwidth
09:08 VanessaE     I wouldn't even notice it in practice
09:08 VanessaE     but I guess for others, it's quite a bit more.  One player on my server can barely sustain half that rate as his full speed
09:09 * VanessaE   looks...
09:09 VanessaE     number of objects around the spawn, 115.
09:10 VanessaE     sounds about right given what's here.
09:12 sapier       let's see what's beeing sent, in theory a mob will add as much bandwith as another player (at least in worst case)
09:14 nore         any thoughts on #1094?
09:14 ShadowBot    https://github.com/minetest/minetest/issues/1094 -- Add forceloading by Novatux
09:16 sapier       while this feature is quite good for mesecons it's abuse potential is huge
09:16 nore         there is a limit for each mod
09:16 VanessaE     I'd say from the engine and client's perspectives, the duplication issues are long since fixed.
09:17 nore         I could perhaps even change something so you change change the limit per-mod
09:17 nore         VanessaE, btw: it does not affect objects this time
09:17 sapier       there's always a way to go around a limit
09:17 VanessaE     nore: different question, see above.
09:18 kahrl        nore: minetest.get_current_modname() <- this doesn't work if you call it from a callback
09:18 kahrl        say, within a register_globalstep handler
09:18 nore         ... ah, I hadn't thought about the handler being called after the begining
09:19 nore         is there a way to delete the method when all mods have started?
09:19 sapier       I suggest adding a config setting to disable this on default, this way server owner would have to think about if she/he really wants to take the risk
09:19 kahrl        perhaps just return immediately if get_current_modname returns nil
09:19 kahrl        or error9)
09:19 kahrl        error()*
09:20 sapier       isn't there already a way to make a entity do forceloading?
09:20 nore         sapier, no, it was never merged
09:21 sapier       oh ok even better :-)
09:21 VanessaE     I don't think I'd want that, honestly.   *imagines an entity going apeshit and flying off into outer space, force-loading ~ 3x3x32000 of the map on the way*
09:22 sapier       I don't want it too VanessaE I just thought it was added
09:22 nore         sapier, easy: block limit for all mods = 0
09:23 sapier       no won't work
09:23 nore         why?
09:23 sapier       if it's a setting a mod can change it on the fly
09:23 nore         where could it be configured then
09:23 nore         ?
09:24 sapier       hmm I guess that'd be a basic issue
09:24 sapier       we don't have protected settings right now
09:24 sapier       maybe it's time to add this feature
09:27 sapier       right now the only safe option would be make it a compiler option ... but thats nonsense
09:27 celeron55    actually it's possible to do force-loading already
09:27 celeron55    via voxel manipulators 8)
09:28 celeron55    it's as hacky as it can get, but it works
09:28 sapier       guess there were only a view people realizing that side effect ;-)
09:30 nore         sapier, celeron55: about the settings:
09:30 celeron55    so trusting mods to not change the setting is okay, because they could load it anyway if they wanted
09:31 nore         one possibility would be to read them at loading time, and to write them at shutdown
09:31 nore         and about the vm forceloading: it does not run ABMs
09:31 celeron55    server never writes settings to the file
09:31 sapier       it does
09:31 celeron55    has it been changed?
09:31 sapier       yes
09:31 celeron55    for like two years it was that way
09:32 sapier       yes but what would settings functions be good for if they don't save anything?
09:32 celeron55    for the client and for temporary settings
09:32 nore         but anyway, I guess trusting the mods would be the best
09:32 celeron55    you know, you want server's configuration to be quite stable
09:32 sapier       "temporary settings"? as far as I know that's callled variable ;-)
09:33 celeron55    sapier: the engine doesn't expose variables, it exposes settings
09:33 celeron55    anyway this is useless
09:33 sapier       true both variants are insufficient
09:33 celeron55    it would be easy to add settings that cannot be changed by mods though
09:33 sapier       storing as well as not storing cause issues for different usecases
09:34 sapier       yes I already had that feature in one of the secuity pulls
09:34 sapier       I implemented it by making settings prefixed securtity_ to be read only
09:34 celeron55    you should start grabbing those into the engine one-by-one 8)
09:35 celeron55    i think that's a bad idea
09:35 celeron55    because an unmodifiable setting isn't necessarily anything related to security; security is just a meta-property of it
09:35 sapier       it's been a quick solution if you have a better idea I'm open for suggestions
09:35 celeron55    of course i have
09:37 celeron55    in defaultsettings.cpp, something like settings->setModWritable("server_announce", false);
09:37 celeron55    then just implement it 8)
09:38 sapier       but it's hardcoding a write protection for specific settings?
09:38 nore         but apart from those security concerns (I fixed some of them), are you ok with the pull?
09:38 celeron55    do we need anything else?
09:38 sapier       if you want to add security to builtin a generic aproach would be better
09:39 sapier       you wouldn't have to fight for any single setting if it's protected or not
09:39 celeron55    well then expose that function to lua, and make it so that it can't be changed from false to true by lua
09:39 sapier       ok you'd have to fight less
09:40 sapier       I don't see a way to do this without storing some information, either in code defaultsettings/lua file or in settings itself
09:40 sapier       I don't like mixing up a flag (protected/not) with control code
09:41 sapier       I suggest setting max_forceloaded_blocks default to 0
09:43 sapier       to show up use of this feature is discouraged if you see any other way to do it
09:43 nore         0 is a bit low... there are several mods who could need it
09:43 sapier       it's not about "could need it" it's about do they really not have any other way
09:44 sapier       most time this will be a lazy solution for problems that can be solved in a better way too
09:44 nore         well... you may be right
09:44 nore         done
09:45 sapier       e.g. of course I could make a mob force load everything, I wouldn't have to care about storing restoring relevant data ;-) but in this special case it's obvious to be an abuse of that feature
09:45 VanessaE     if it moves, it should not be able to force-load.
09:46 sapier       it's been a hypothetical example ;-)
09:46 nore         VanessaE, it could, but it would require cleverly forceloading blocks to never leave loaded ones
09:47 VanessaE     nore: which requires cooperation from the modder.....
09:47 VanessaE     better to assume the modder will do it wrong :)
09:47 nore         well, anyway, it is set to default to 0 now
09:48 sapier       modders always use any possible hack to achiev what they want ... believe me I did this multiple times too
09:48 sapier       yes
09:48 VanessaE     sapier: indeed so.
09:49 VanessaE     I haven't looked at the code yet; how does the server know to start a load sequence?  I mean say you spawn at one end of a large mesecons circuit.  How does the server go about finding all of the circuit?
09:49 VanessaE     would you make every mesecons node attach to the force-load calls?
09:50 nore         VanessaE, no... (though mesecons could cheat and use VM)
09:51 sapier       local function blockpos_from_hash(hash) you could make this function generally available
09:51 sapier       hash_blockpos a function like this already exists as far as I know
09:51 VanessaE     oh I see what you're getting at
09:52 VanessaE     store the circuit and re-load the mapblocks it needs it at start-up?
09:52 sapier       you should explicitly return nil in get_forceload_handler
09:53 sapier       nil and 0 aren't same in lua
09:53 nore         sapier: indeed, I hadn't seen it
09:54 sapier       wait some time prior fixing it I'll tell you once I reached end
09:54 kahrl        could safeWriteToFile be used instead of write_file?
09:56 nore         kahrl, what does it do? is it exposed to Lua?
09:57 kahrl        it's not exposed to lua but it probably should be
09:58 kahrl        it writes to a temporary file and uses atomic rename() to overwrite the target file
09:58 kahrl        well, atomic on modern platforms
10:00 sapier       I don't understand what the handler is good for
10:00 nore         sapier, it allows to be per-mod
10:01 nore         i.e.: mod X has already loaded all it was allowed to, but mod Y still has right to load blocks
10:01 sapier       hmm ok so the limit is actually mods*limit true?
10:02 nore         yep
10:02 sapier       feels a little bit overcomplicated but I don't know a better way right now
10:03 nore         the problem is that you can't know which mod calls after loading step
10:03 kahrl        actually, a mod could intercept minetest.get_current_modname and get an infinite amount of handlers that way
10:03 sapier       you're taöling about replacing it prior calling and restoring it afterwards
10:04 kahrl        indeed
10:04 kahrl        alternatively, just make a modpack with tons of individual mods, each with its handler
10:04 sapier       possible ... but it's not the only security issue in there
10:04 sapier       "in there" not meaning this patch but minetest
10:05 sapier       a absolute limit would be more predictable for server owners
10:05 nore         there are security issues everywhere... I guess it would be possible for a mod to replace the minetest executable with another one, and to get everything it wants that way
10:06 nore         sapier: perhaps print the mods that asked an handler at the end of the loading step?
10:07 sapier       others doing wrong doesn't justify doing even worse ;-) ... this way server owner could at least see it if interested
10:07 celeron55    nore: on a global install on linux replacing an executable isn't possible 8)
10:07 celeron55    on everything else it probably is
10:07 sapier       crosschecking modname against modlist would be another option to prevent this
10:07 nore         you're right... I use a run in place version, so it is possible for me
10:08 nore         sapier, can't we just trust mods a bit? they can also do minetest.setting_set("max_forceloaded_blocks", 100000)
10:09 sapier       actually we have a big fat warning about mods on our website ;-)
10:10 sapier       why should we consider any 3rd party code trustworthy ;-) we can only throw that hat on server owner ... giving him responsibility to check mods prior using them... but who does?
10:10 nore         sapier, btw: and if the mod changes the modlist too?
10:10 celeron55    sapier: where is the big fat warning? i can't find any
10:11 sapier       is it gone?
10:11 celeron55    doesn't seem big and fat enough
10:12 sapier       hmm you're right ... but I remember there was one in a earlier web page version
10:13 sapier       nore your arguments speak more for adding a hard total limit instead of using a per mod limit
10:14 celeron55    why try to do anything per-mod? the lua environment is shared and any such attempts are probably useless
10:14 celeron55    at least with a global limit you actually manage to limit something
10:14 nore         so, everything globally?
10:14 sapier       great I don't see anything warning users about mod code beeing potentially harmfull
10:15 sapier       sorry nore but I guess the per mod limiting doesn't actually work
10:15 celeron55    probably this should have it, because it is pointed to as an official guide http://dev.minetest.net/Installing_Mods
10:16 nore         ok, I will do that... makes the code much easier now
10:16 celeron55    there is an almost identical guide here though http://wiki.minetest.net/Installing_Mods
10:17 sapier       ok I add a warning to top of those pages
10:18 sapier       "Prior installing any mod make sure you either have it from someone you trust, or check it to not contain mallicious code!" what about this?
10:18 celeron55    this is firefox's wording on it http://i.imgur.com/zvOopsD.png
10:18 celeron55    maybe use something similar
10:20 celeron55    sapier: i think my link has better wording
10:20 VanessaE     s/have/received/; s/it to not/that it does not;  s/mallicious/malicious/
10:20 sapier       Prior installing any mod make sure you either have it from someone you trust. Mallicious mods can damage your computer, violate your privacy or even make your computer take part of criminal activities!
10:21 celeron55    sapier: don't make it so long; make it short and clear
10:21 celeron55    they can go read about malware on wikipedia if they want
10:21 sapier       Prior installing any mod make sure you either received it from someone you trust. Mallicious mods can damage your computer, violate your privacy or infringe you to criminal activities!
10:22 VanessaE     "Prior to installing any mod, please make sure that you have received it from someone you trust.  Malicious code can damage your computer, violate your privacy, cause your computer to take part in criminal activities, start the next world war, or cause the death of innocent kittens."
10:22 sapier       two words smaller?
10:22 kahrl        PilzAdam, sapier: https://github.com/minetest/minetest/pull/1095
10:22 VanessaE     celeron55: they won't read.
10:22 sapier       death of innocent kittens? maybe that's not a warning but advertisement for some ppl ;-)
10:22 VanessaE     and sapier, your grammar sucks. :)
10:23 sapier       :-)
10:23 celeron55    just use that VanessaE's one; at least it's valid english
10:23 PilzAdam     kahrl, ah, finally
10:24 sapier       ... ok but only until "activities"
10:24 VanessaE     then, "..., or cause your computer..."
10:25 VanessaE     sure, spoil my joke :)
10:28 sapier       http://wiki.minetest.net/Installing_Mods http://dev.minetest.net/Installing_Mods
10:28 nore         sapier, changes done
10:28 nore         could you look at it again?
10:30 sapier       seems to be ok ShadowNinja what do you think about it?
10:30 sapier       talking about #1094 right now
10:30 ShadowBot    https://github.com/minetest/minetest/issues/1094 -- Add forceloading by Novatux
10:32 sapier       #1095 seems to be a good change too
10:32 ShadowBot    https://github.com/minetest/minetest/issues/1095 -- Compare values instead of pointers in Inventory::operator== by kahrl
10:33 nore         sapier, wait a bit before merging: I need to finish testing
10:33 sapier       I can't merge it nore it's definitivly scriptapi which is ShadowNinja's domain
10:35 sapier       well I can merge it but only after he agreed to it
10:40 nore         anyway: I just made a test mod for it
10:41 nore         there: https://gist.github.com/Novatux/8369336
10:47 celeron55    sapier: you do have the option to follow the two-devs-agree rule if you think ShadowNinja probably agrees, but it's probably better to ask anyway
10:48 sapier       oh that's still an option to go? didn't know about it
10:48 celeron55    there has been no reason to remove it 8)
10:49 sapier       ok :-) good to know
10:50 BlockMen     why crashes mt at main.cpp L1006 [run_tests()] (when debugging with msvc)?
10:51 BlockMen     error-msg "Unbehandelte Ausnahme bei 0x75dbc41f in minetest.exe: Microsoft C++-Ausnahme: SendFailedException an Speicherposition 0x00e12b68..
10:51 BlockMen     minetest.exe hat einen Haltepunkt ausgelöst."
10:51 sapier       guess one of the unit tests is wrong again
10:52 sapier       some of them are quite timing sensitive
10:52 PilzAdam     BlockMen, run it with --disable-untitests
10:54 BlockMen     PilzAdam, not sure how to do that in msvc
10:56 BlockMen     but got at least that http://pastebin.com/pcr5JCF2
10:57 sapier       yes that's one of those tests
10:57 sapier       find the command line options in configuration and add "--disable-uinttests"
10:58 BlockMen     i just commented out now :P (l1006)
10:59 sapier       :-) works too of cours
10:59 sapier       e
11:00 BlockMen     debug under msvc is even more pain than releasing =\
11:04 nore         any thoughts on that? https://github.com/Novatux/minetest/commit/32505249a11027b9f2593c07548ff2004f1ad3c7
11:05 nore         sapier, who's in charge of builtin?
11:06 * VanessaE   hides
11:06 nore         ?
11:06 sapier       Shadowninja is for scriptapi
11:06 VanessaE     (I seem to have been one of the most recent contributors to that)
11:06 nore         so, that includes builtin, right?
11:06 sapier       while I support the mainmenu subpart
11:06 sapier       yes
11:06 nore         anyway, can you tell me your comments about that commit?
11:08 nore         https://github.com/Novatux/minetest/commit/3160c63a687179cd86b19643ae66d06733475ae4 <-- forgot the doc
11:09 sapier       copy instead of reference seems fine, I don't actually see a use for the additional parameter as it can be calculated from pos with little effort
11:10 nore         no, it can't... you don't have pointed_thing.above
11:11 nore         which is the whole problem (for example, if you want the on_rightclick to sometimes do as if the node had not an on_rightclick function)
11:11 sapier       it's a position isn't  it?
11:12 nore         above is a position, indeed
11:12 nore         pointed_thing = {type = "node", under = <pos>, above = <pos>}
11:13 sapier       sorry I have to leave now I'll have a closer look at it later (if still relevant)
11:39 nore         the utf-8 characters in formspecs have been fixed????
11:45 sapier       ok back what about utf-6?
11:45 sapier       +2
11:45 nore         I'm just asking, since I saw some of them work... but gtg, brb
12:39 nore         sapier, so, can I merge that commit? https://github.com/Novatux/minetest/commit/3160c63a687179cd86b19643ae66d06733475ae4
12:43 sapier       I'm not sure about it I still believe it's redundant information passing
12:44 sapier       the only additional information is the pointed_thing.type
12:49 nore         sapier, no, the additional information is pointed_thing.above
12:49 nore         (pointed_thing.type will always be "node")
12:50 sapier       but isn't above always under y+1
12:50 VanessaE     nope.
12:50 sapier       no?
12:50 VanessaE     above is whatever's between you and under
12:51 VanessaE     it might be under.x+1
12:51 VanessaE     or under.z-1/under.x-1
12:51 VanessaE     it's line of sight
12:51 sapier       oh ... ok in this case it does make way more sense
12:51 sapier       -make +give?
12:52 nore         so, can I merge it then?
12:52 sapier       if shadow agrees ;-)
12:52 VanessaE     that's how I detect wall vs. floor in the rotate and place call.  if the x/z pos is not equal between the two, then I'm pointing at a wall, because LoS has me looking through one node (the space in front of the wall) and into a different place (the wall).
12:52 VanessaE     if they're equal, then I must be looking at a floor or ceiling
12:52 sapier       also we could decide by two core devs I personally don't want to merge things without asking the responsible maintainer
12:54 sapier       at least not for feature addons
15:49 ShadowNinja  nore: That seems fine with s/Copy/Deep-copy/ (It was already shallow-copied) and docs.
15:50 ShadowNinja  nore: You should note that pointed_thing can be nil since some mods call it directly.
15:56 ShadowNinja  I think that the force-load API would be fine with a global limit, not just per-mod.
15:57 ShadowNinja  And mods that abuse it won't get acepted into the MMDB.
16:06 nore         ShadowNinja, it has been changed for that
16:08 ShadowNinja  nore: I also think it should have a higher default limit, like 16.  That shouldn't be enough for mods to cause too much load, but it will mean that mods won't have to ask users to modify their configuration file.
16:08 nore         ShadowNinja, sapier told me it should be 0...
16:08 ShadowNinja  mod developers*
16:09 sapier       I also said I think ;-) ... and I still think so but it's shadows realm to decide
16:09 ShadowNinja  Yes, I saw, but why?  They can't cause too much abuse if it's low by default.
16:10 nore         ShadowNinja, I changed the doc for pointed_thing, is it ok?
16:10 sapier       It's a door opener, once a ugly hack is implemented instead of a valid solution pressure to server owners will rise to increase it
16:10 ShadowNinja  (Or rather they can't without using setting_set and the like, which they can do anyway, and they probably will do when users complain about having to modify their .conf.
16:10 ShadowNinja  )
16:10 ShadowNinja  nore: Commit?
16:11 nore         https://github.com/Novatux/minetest/commit/a910e95b59e98b1d4602530e0379baebe9a3a48e
16:11 sapier       whoever uses this feature most likely doesn't care about performance and side effects
16:12 sapier       e.g. in a static world making 100 blocks force load will most likely not be an issue ... but try adding mobs to that world
16:12 ShadowNinja  nore: Split the on_rightclick call onto two lines, then it seem good.
16:12 ShadowNinja  +s
16:12 sapier       but as I said it's your decision
16:12 ShadowNinja  If a mod causes lag the user will complain andremove it.
16:13 sapier       no they always complain about mobs because they are where the lag becomes obvious
16:13 nore         ShadowNinja, done
16:14 nore         https://github.com/Novatux/minetest/commit/18e9b71382db06a737afbcc719b6bc7e4017395e
16:14 BlockMen     should i use #define xyz for different camera view modes (for better readability) or just comment there different values somewhere?
16:14 nore         BlockMen, I guess #define is better
16:14 hmmmm        https://github.com/minetest/minetest/commit/3bbd280336dffc73ef43b2ac93937f320cb32872
16:15 hmmmm        WOWW
16:15 hmmmm        seriously
16:15 hmmmm        how was that not noticed right away as being a critical bug
16:15 ShadowNinja  BlockMen: It sounds like that's something for an enum.
16:16 sapier       no idea ... the stange thing is this was added as fix for win32 but I don't have any idea how it could solve that issue in wind32
16:16 xyz          nore: what's the use for force loading some blocks?
16:16 nore         xyz: keeping machines loaded, etc.
16:16 xyz          machines?
16:16 ShadowNinja  nore: Two tabs, and still s/Copy/Deep-copy/.
16:17 nore         technic machines, furnaces, ...
16:17 xyz          hmmm... but if you talk about furnaces
16:17 xyz          those can be built by any player
16:17 BlockMen     ShadowNinja, even better
16:18 xyz          so limiting seems strange
16:18 nore         xyz, no, I mean for example a block that will forceload an area
16:18 sapier       furnaces are not a reason to forceload a block, if someone uses this she/he's just to lazy to do a propper implementation
16:18 nore         but with a priv to place it, etc
16:18 nore         sapier, I wrote code for furnaces to do that, but it was never merged
16:19 xyz          yeah, so I want to have some real reason
16:19 xyz          but I guess it won't hurt to have this feature
16:19 sapier       I don't know what happened to that code but I know chaose of minetest development so I believe you
16:19 nore         however, technic machines or huge mesecons contraptions will need it
16:19 BlockMen     where would be the best place to put in the enum?
16:19 xyz          just a thought: you shouldn't limit it at all
16:20 nore         xyz: btw, there is already force_loading in FM, but it is far much hacky
16:20 xyz          for entities
16:20 nore         (and it is for entities, etc)
16:20 xyz          different use case
16:20 nore         well, you can do both with any of them
16:20 xyz          you're talking about hacky things now D:
16:20 sapier       I don't think we will ad two versions to do so
16:20 nore         and if you don't want limit, set it to 100000
16:21 xyz          abusing entities to just get some area loaded is no good
16:21 xyz          nore: I don't want limit by default
16:21 Megaf        sapier, ! Hi tehre
16:21 Megaf        sapier, did you fix connection.cpp?
16:21 sapier       the whole forceload mechanism is a hack which shouldn't be used ;-)
16:21 xyz          how comes
16:21 Megaf        in your UDP thing
16:21 ShadowNinja  BlockMen: What do you mean?  The enum should probably be in a related .h.
16:22 sapier       what exactly are you speaking about Megaf?
16:22 xyz          sapier: it's quite useful
16:22 Megaf        also, if someone could fix this please > https://github.com/minetest/minetest_game/issues/236
16:22 nore         ShadowNinja, better now? https://github.com/Novatux/minetest/commit/6aded07d92fe3a7c9d84e374b00864ef54137ed1
16:22 Megaf        sapier, I have no idea, VanessaE knows better, let me see if I can find a pastebin I did
16:22 sapier       xyz the only legit reason to forceload anything I have read sofar are big mesecon/technic machine
16:22 xyz          for example, for carts that can carry items
16:22 Megaf        sapier, there you go http://paste.debian.net/74363
16:22 xyz          you have a deep mine
16:22 nore         xyz, so, you don't want limit by default, sapier wants to set the limit to 0 by default, what should I do?
16:23 xyz          and you send a cart with mined stuff
16:23 xyz          to the top
16:23 ShadowNinja  nore: Well, yes, but I meant the commit message.  But you can tweak that locally.
16:23 xyz          and without forceloading it gets stuck somewhere
16:23 sapier       5-01 guess that's long done
16:23 nore         ShadowNinja, so, is it ok now?
16:23 nore         xyz: the cart can use this version of forceloading too
16:24 BlockMen     ShadowNinja, because i need in game.cpp, content_cao, camera.cpp, clientmap.cpp, ...
16:24 xyz          nore: indeed
16:24 sapier       xyz ok this is a valid usecase true but is it really worth the abuse potential?
16:24 Megaf        sapier, I think I'm talking about this branch https://github.com/sapier/minetest/tree/udp_implementation_fixes
16:24 BlockMen     should i put it in game.h then and include missing game.h in camera.cpp for example
16:24 xyz          but I feel that for this case entities' force loading is better
16:24 xyz          sapier: "abuse potential"
16:24 Megaf        sapier, or this one https://github.com/sapier/minetest/tree/network_fixes_udp_1
16:24 sapier       Megaf the corrected fixes are already merged to master ;-)
16:24 xyz          please stop
16:24 xyz          it's like you want to argue while having no better argument
16:25 xyz          so you just make things up
16:25 nore         xyz, then we would need to merge it in minetest too perhaps
16:25 sapier       whole design of minetest is based uppon having as less as possible active
16:25 nore         I don't know the thoughts of other devs
16:25 ShadowNinja  nore: Yes.
16:25 xyz          nore: dunno
16:25 xyz          sapier: fine
16:25 xyz          sapier: then don't merge stuff like that
16:26 sapier       I don't say this isn't usefull at all but everyone using or allowing it's usage should be aware of the possible performance issues
16:26 xyz          for that we need docs
16:26 xyz          we don't have docs
16:26 xyz          a problem right here
16:27 xyz          what we have now are 1) a giant .txt file which basically says "fuck you" and 2) an outdated wiki
16:27 sapier       and if used it should be used as last option not because "it's so much easier if my block isn't unloaded"
16:28 xyz          not adding something just because someone could misuse it feels too wrong to be considered as a valid argument
16:28 Megaf        Thanks sapier, your udp thing branch is fantastic
16:29 xyz          "hello, no, you can't have this because we don't want people to use it wrong way"
16:29 sapier       best way would be add it with proper methods to prevent abuse
16:29 xyz          you are absolutely right
16:29 sapier       but imho not adding is slightly better then adding without abuse prevention (not much better of course)
16:30 xyz          now, I define "proper methods" as having a nice explanation of what to use this for and what consequences this will have
16:30 ShadowNinja  nore: Make sure to update the dev wiki too.
16:30 sapier       and I don't agree to that definition ;-P
16:30 xyz          some people, for some strange reason I can't really understand, define "proper methods" as having a ridiculous limit which is so stupid every mod will ask you to change it
16:31 sapier       imho server owner should be able to prevent this abuse without having to rely on someone else doing right
16:31 xyz          that's fine too, different people, different opinions
16:31 sapier       e.g. for nores fixes server owner can make settings read only and set a limit
16:32 nore         ShadowNinja, for forceload, I changed the default limit to 16. Would it be ok?
16:32 ShadowNinja  nore: Yes.
16:36 sapier       xyz limit of 0 was actually meant as disable that feature by default to make sure any server owner has to actively enable it (hopfully reading what she/he's doing)
16:37 nore         so, is forceloading ok for merging, or not?
16:37 xyz          sapier: this is very user-unfriendly
16:39 nore         ShadowNinja, sapier, xyz: ^
16:40 ShadowNinja  nore: Yes.  sapier: I want to avoid that, there isn't any big risk with enabling it.
16:41 xyz          nore: no
16:46 xyz          first, it doesn't even match what docs say
16:47 xyz          second, it's quite strange that it force loads a block based on node position
16:47 xyz          you can of course ignore the second remark but the first one is a no-no
16:48 nore         what do you mean, it doesn't match docs?
16:50 sapier       ShadowNinja: I'll tell you once there's a server with 1k active mobs due to 100 foceloaded blocks ;-) and a single player
16:50 ShadowNinja  sapier: The limit I suggested was 16.
16:51 sapier       as I said the 0 was only to force server owners to actively enable it... I guess 16 will in practice be same as 0
16:51 xyz          nore: well, it doesn't even return anything
16:51 sapier       difference is only psychological
16:52 sapier       you more likely think about something when you have to enable it as if you "just" increase
16:53 nore         I have forgotten a "return" indeed: can I still rewrite history, or is it too late?
16:54 nore         ok, I rewrote history (commit is less than 10 mins old)
16:54 xyz          no, you
16:55 xyz          oh well fuck
16:55 nore         well, that was what was written in the dev wiki...
16:55 xyz          yes
16:56 xyz          proposition: add a rule to never rewrite history in master unless you've done something ridiculous (committed your private key or deleted the whole repo or added a 10 gb file)
17:00 proller      network_fixes_udp_1 must be reverted yesterday
17:00 sapier       did you merge a prototype?
17:01 sapier       or what's your problem with it proller?
17:02 proller      unproofed hate
17:02 proller      need something else?
17:02 sapier       A little bit more might be helpfull, e.g. undoubtable prove of basic errors ;-)
17:05 sapier       of course those errors have to be non fixable too ;-)
17:05 * VanessaE   wonders too...
17:06 VanessaE     I wrung that code out on my servers left, right, sideways, and diagonal....and 6d facedir too.... and it works fine for the most part.
17:38 ShadowNinja  No, hate is not a valid reason.  ;-)
17:40 ShadowNinja  nore: Close your pull.
17:41 nore         Sorry, I always forget that
17:44 ShadowNinja  kahrl: Why do you use !(==) instead of != in https://github.com/minetest/minetest/pull/1095 ?  (If it isn't implemented then maybe it should)
17:59 ShadowNinja  sapier: 9edb91da5754cf194637d1d7faa513719b61f9b4 is the first bad commit <-- This somehow broke the HUD entry that my areas mod adds.  (Fixed minetest reliable udp implementation)
18:02 sapier       how can transmission break hud?
18:02 sapier       what's going on with hud?
18:03 VanessaE     it just doesn't appear.
18:03 VanessaE     the "Area owner:" display that should appear in the lower left just isn't there after that ^^^^^ commit.
18:03 sapier       is it sent reliable?
18:05 ShadowNinja  sapier: Looks like you incremented the second argument to Send.
18:05 sapier       hmm guess I know what's happening
18:05 ShadowNinja  That's all I see related to HUD.
18:06 sapier       for some strange reason the hudremove message is sent on channel 1 ... which has lower prio than the other channels
18:07 ShadowNinja  My mod doesn't use remove, it only uses add and update.
18:07 sapier       actually it's other way round add and remove are sent at 1 while change setflags and setparam are sent at 0
18:08 sapier       maybe the change is received prior add
18:08 sapier       guess all of them should be on same channel
18:09 ShadowNinja  My mod only sends change is it's actually changed.  Which is when you move in or out of a protection zone.
18:10 sapier       https://gist.github.com/sapier/8374497 could you try this one?
18:10 sapier       second argument is channel
18:11 sapier       channels have been there before they just didn't work at all and noone used them
18:15 ShadowNinja  error: patch failed: src/server.cpp:3772
18:15 sapier       what?
18:16 sapier       I just rebased my view to master?
18:17 sapier       are you at master ShadowNinja
18:17 sapier       ?
18:17 sapier       +latest
18:18 ShadowNinja  git describe --> 0.4.9-25-g84b94eb
18:18 sapier       I've got exactly same version
18:20 ShadowNinja  Applied manually.
18:21 sapier       hmm seems like gitdiff doesn't give valid patch files ... or I did copy something wrong
18:22 ShadowNinja  git diff --patch?  But I think that's the defaut.
18:22 ShadowNinja  Still no HUD.
18:23 sapier       hmm how can I reproduce it?
18:24 ShadowNinja  git clone git@github.com:ShadowNinja/areas.git
18:25 ShadowNinja  Normaly it shows "Area owners: " at the bottom left.
18:27 sapier       I have a look yet I don't have any idea how this could be related to network if those channel changes aren't reason
18:35 kahrl        ShadowNinja: yeah, operator!= isn't implemented
18:35 kahrl        I didn't want to change more than was needed
18:39 ShadowNinja  kahrl: Well, merge it.  And maybe add a !=, in a seperate commit if you prefer.
18:44 kahrl        why isn't operator== a const method?
18:44 kahrl        well, I'll change that too
18:44 ShadowNinja  I'll push get/set_lists.
18:45 kahrl        I'm about to push the operator==/!= fix
18:46 ShadowNinja  OK, I'll wait.
18:49 kahrl        done
18:49 kahrl        (took a bit longer, had to build it again)
18:51 ShadowNinja  I also renamed get_json_value to read_json_value.  And I should add a recursion limit...
19:15 ShadowNinja  kahrl: Why hasn't formspec_table been merged yet?
19:17 kahrl        I don't know
19:41 sapier       ShadowNinja: seems like scriptapi is transmitting your hud prior connection is completely initialized
19:42 sapier       seems like detached inventorys can be sent prior initialization beeing complete too
21:54 Megaf        sapier1, http://paste.debian.net/75676/
21:54 Megaf        Just got this crash
21:56 sapier1      what version do you use?
21:57 Megaf        latest from git
21:57 Megaf        and your udp branch with fixes
21:57 sapier1      AND?
21:57 Megaf        I'm not sure if this one https://github.com/sapier/minetest/tree/network_fixes_udp_1 or this one https://github.com/sapier/minetest/tree/udp_implementation_fixes
21:58 Megaf        VanessaE, ping
21:58 Megaf        https://github.com/sapier/minetest/tree/udp_implementation_fixes
21:58 sapier       just take latest git my fixes are already included
21:58 Megaf        this branch I'm using
21:58 sapier       that one has some bugs left
21:58 sapier       try latest git
21:59 proller      yet another 1000 random lines and 3 threads added &
21:59 proller      ?
21:59 sapier       what are you talking about?
22:02 proller      about next "fixes"
22:02 sapier       there are none by now
22:03 sapier       whatever megaf found was in a old version
22:12 Sokomine     regarding find_node_near: how efficient is it to call it with a relatively long list of possible node names (about 20)? my mob needs to find something to sit on - and that comes in several mods and in several colors
22:12 sapier       the list is less problem then the range
22:13 Sokomine     they don't have to search too often. that at least can be limited :-)
22:14 sapier       if you do consume 1 time 5s it's worse then 20 times 200ms
22:14 sapier       ok 50 times 200ms