| 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/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 |
|
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/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 |
| 22:38 |
|
Zeitgeist_ joined #minetest-dev |
| 22:55 |
|
salamanderrake joined #minetest-dev |
| 23:05 |
|
rsiska joined #minetest-dev |
