Minetest logo

IRC log for #minetest-dev, 2014-01-11

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

All times shown according to UTC.

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
00:32 kahrl joined #minetest-dev
00:49 Miner_48er joined #minetest-dev
01:03 us_0gb joined #minetest-dev
01:54 iqualfragile bug: when trees grow the will not replace flowing water
02:19 salamanderrake joined #minetest-dev
02:43 Miner_48er joined #minetest-dev
03:01 OldCoder joined #minetest-dev
03:10 ImQ009 joined #minetest-dev
04:04 Shadowfire joined #minetest-dev
04:12 cheapie joined #minetest-dev
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.
05:42 nore joined #minetest-dev
05:46 Miner_48er joined #minetest-dev
07:44 sapier joined #minetest-dev
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 mrtux joined #minetest-dev
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 werwerwer joined #minetest-dev
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 jin_xi joined #minetest-dev
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 Calinou joined #minetest-dev
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 PilzAdam joined #minetest-dev
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 rsiska joined #minetest-dev
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 BlockMen joined #minetest-dev
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 Evolykane joined #minetest-dev
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:26 Ritchie joined #minetest-dev
12:33 EvergreenTree joined #minetest-dev
12:33 EvergreenTree joined #minetest-dev
12:38 ImQ009 joined #minetest-dev
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 Jordach joined #minetest-dev
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
13:17 bas080 joined #minetest-dev
13:20 Megaf joined #minetest-dev
13:42 Ritchie joined #minetest-dev
14:09 zat joined #minetest-dev
14:18 Gethiox joined #minetest-dev
14:37 grrk-bzzt joined #minetest-dev
14:53 NakedFury joined #minetest-dev
15:07 iqualfragile joined #minetest-dev
15:13 Yepoleb joined #minetest-dev
15:26 hmmmm joined #minetest-dev
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:00 Zeitgeist_ joined #minetest-dev
16:01 VanessaE joined #minetest-dev
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/commi​t/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/minetes​t/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/minete​st/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/mine​test/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 Calinou joined #minetest-dev
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 Ritchie joined #minetest-dev
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 kaeza joined #minetest-dev
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:13 ImQ009 joined #minetest-dev
17:23 ImQ009_ joined #minetest-dev
17:32 rubenwardy joined #minetest-dev
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:16 ImQ009 joined #minetest-dev
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:00 BlockMen left #minetest-dev
19:02 EvergreenTree joined #minetest-dev
19:02 EvergreenTree joined #minetest-dev
19:06 iqualfragile joined #minetest-dev
19:15 ShadowNinja kahrl: Why hasn't formspec_table been merged yet?
19:17 kahrl I don't know
19:34 OldCoder joined #minetest-dev
19:41 sapier ShadowNinja: seems like scriptapi is transmitting your hud prior connection is completely initialized
19:42 Weedy_lappy joined #minetest-dev
19:42 Weedy_lappy joined #minetest-dev
19:42 sapier seems like detached inventorys can be sent prior initialization beeing complete too
20:15 Calinou joined #minetest-dev
20:44 sapier1 joined #minetest-dev
20:53 xiong joined #minetest-dev
20:59 proller joined #minetest-dev
21:27 EvergreenTree joined #minetest-dev
21:28 EvergreenTree joined #minetest-dev
21:37 Gethiox2 joined #minetest-dev
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/mine​test/tree/network_fixes_udp_1 or this one https://github.com/sapier/minete​st/tree/udp_implementation_fixes
21:58 Megaf VanessaE, ping
21:58 Megaf https://github.com/sapier/minete​st/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
22:38 Zeitgeist_ joined #minetest-dev
22:55 salamanderrake joined #minetest-dev
23:05 rsiska joined #minetest-dev

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