Minetest logo

IRC log for #minetest-dev, 2014-08-08

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

All times shown according to UTC.

Time Nick Message
00:17 VargaD_ joined #minetest-dev
01:01 nore__ joined #minetest-dev
01:01 nore_ joined #minetest-dev
01:04 nore_ joined #minetest-dev
01:11 nore_ joined #minetest-dev
01:49 nore__ joined #minetest-dev
01:54 Zeno` joined #minetest-dev
02:18 nore_ joined #minetest-dev
02:20 AnotherBrick joined #minetest-dev
02:28 zat joined #minetest-dev
03:54 Eater4 joined #minetest-dev
04:27 ^v joined #minetest-dev
05:01 cg72 joined #minetest-dev
05:26 Eater4 Can anyone get the irc mod working on unbuntu server?
05:41 Hunterz joined #minetest-dev
05:45 Miner_48er Eater4 what's the problem?
05:58 Garmine joined #minetest-dev
07:06 grrk-bzzt joined #minetest-dev
07:06 grrk-bzzt joined #minetest-dev
08:02 SoniEx2 joined #minetest-dev
08:20 Krock joined #minetest-dev
09:17 Calinou joined #minetest-dev
09:25 kahrl joined #minetest-dev
09:48 jp__ joined #minetest-dev
09:50 jp__ Hello venerable devs. Does it's possible to have a smart highlighting instead of a collisionbox dark edges, please ?
09:50 Calinou jp__, you can change selection box colour to anything
09:50 Calinou but it'll always be fully opaque
09:50 Calinou try some dark grey instead of black
09:50 Calinou to reduce contrast
09:51 jp__ I want an highlighting rather.
09:51 Calinou selectionbox_colour = 34,34,34
09:51 jp__ Not a color, an highlighting.
09:51 Calinou selectionbox_color = (34,34,34)
09:51 Calinou fixed
09:51 jp__ Without dark edges ?
09:51 Calinou nope.
09:51 jp__ Ah.
09:51 Calinou would need C++ edit
09:52 Calinou what you want is to just add some semi-transparent bright field?
09:52 Calinou possible… but not trivial
09:52 jp__ "semi-transparent bright field"  <- indeed.
09:54 Garmine joined #minetest-dev
09:57 rmilan joined #minetest-dev
10:15 PenguinDad joined #minetest-dev
10:26 loggingbot_ joined #minetest-dev
10:26 Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/
10:33 NakedFury joined #minetest-dev
10:58 proller joined #minetest-dev
11:48 Jordach joined #minetest-dev
11:49 Krock joined #minetest-dev
11:51 nore_ joined #minetest-dev
11:53 ImQ009 joined #minetest-dev
12:30 nore_ joined #minetest-dev
12:34 jp___ joined #minetest-dev
12:34 jp___ left #minetest-dev
12:55 PilzAdam joined #minetest-dev
12:59 nore_ joined #minetest-dev
13:17 nore_ joined #minetest-dev
13:44 casimir joined #minetest-dev
15:33 Calinou joined #minetest-dev
15:36 Hunterz joined #minetest-dev
16:11 sapier joined #minetest-dev
16:18 grrk-bzzt joined #minetest-dev
16:18 grrk-bzzt joined #minetest-dev
16:19 zat joined #minetest-dev
16:44 Calinou joined #minetest-dev
17:42 nore__ joined #minetest-dev
17:42 nore_ joined #minetest-dev
17:50 cg72 joined #minetest-dev
18:07 nore_ joined #minetest-dev
18:36 cg72 left #minetest-dev
18:55 Eater4 joined #minetest-dev
18:59 proller joined #minetest-dev
19:13 Miner_48er joined #minetest-dev
19:22 cg72 joined #minetest-dev
19:52 nore_ joined #minetest-dev
19:53 grrk-bzzt joined #minetest-dev
19:56 nore_ joined #minetest-dev
20:14 ^v joined #minetest-dev
20:18 ^v joined #minetest-dev
20:26 paramat joined #minetest-dev
21:06 cg72 joined #minetest-dev
21:55 nore_ joined #minetest-dev
22:04 kahrl now that I have a bit of free time, I think I will start working on prediction for node metadata inventories
22:04 kahrl has there been any previous work on this?
22:06 kahrl e.g. thoughts on how (or whether) to predict which actions the server will allow or not allow
22:07 sapier we thought about some sort of client side lua which would actually solve the issue
22:08 kahrl sounds like overkill (at the moment at least)
22:08 kahrl of course it would be the best solution in the long term
22:08 sapier yes but how do you intend to predict something done by a mod for example
22:08 VanessaE I dunno about that, but there is a more pressing issue to deal with (not your domain though): minetest_game is experiencing horrible lag.
22:08 VanessaE I've got reports from multiple sources, including two of my own servers.
22:09 sapier current master or stable?
22:09 kahrl what kind of lag?
22:09 VanessaE kahrl: unclear what the cause of the lag is, but high server CPU usage, 3 to 12 seconds' worth of hangs, etc.
22:10 VanessaE where there used to be less than 1 second
22:10 kahrl is it just minetest_game?
22:10 VanessaE sapier: master
22:10 VanessaE commit 6967232619cfc6f5751d30390473181941b46c9b at the moment.
22:10 VanessaE kahrl: yes.
22:10 sapier https://github.com/minetest/minetest/pull/1475 this one improves "fealt" lag due to lost node updates drasticaly
22:10 Zefram_Fysh kahrl: it should be sufficient, as an intermediate before we get client-side lua, to have metadata on the node type to say whether to predict that an inventory transfer will succeed, per list name
22:11 sapier btw it's server side so you could test if this is the same lag reason you see VanessaE
22:11 VanessaE sapier: it's not that kind of lag.
22:11 sapier Zefram_Fysh: there's no way to predict this
22:11 kahrl Zefram_Fysh: that's what I thought I would do
22:11 VanessaE it's more like server just stops listening and goes into a high-CPU-usage state for several seconds at a time
22:11 sapier if a transfer succeeds or not depends on lua callbacks
22:11 VanessaE similar to what would happen with mapgen lag, but it's not the mapgen
22:12 sapier VanessaE: sounds like a mod issue
22:12 VanessaE I've seen it happen when I'm the only one online.
22:12 sapier is there anything to trigger it?
22:12 VanessaE sapier: I suspect the boats mod, based on reports I've seen from others - apparently this mod is very crashy.
22:12 kahrl sapier: sure, some predictions will be wrong, but it should be much better than what we have now
22:12 sapier remove it and have a try
22:12 VanessaE (I have yet to see it crash, myself - perhaps my server just lags out)
22:12 Zefram_Fysh there are easy cases such as unlocked chests, where the lua callbacks always say yes.  these easy cases cover rather a lot of node inventories.  the only difficult bit is that you need to recover if the prediction turns out to be inaccurate
22:12 VanessaE I will try, I wanted to get you'all's opinion on it.
22:13 sapier kahrl only if you manage to avoid inconsistent states ... not sure how complicated that will be
22:13 kahrl we would have to do that in any case, as the client side lua might not have access to all information that is needed to correctly predict
22:14 sapier Zefram_Fysh: imho hardcoding something isn't worth the work as it's work for trash once a more generic solution is done
22:14 Zefram_Fysh in principle it's exactly the same issue as placement and digging prediction.  we do predict those, and recover from inaccurate predictions
22:14 Jordach i've not noticed lag by using magpen v7
22:14 Jordach BFD in recent days has not seen massive lockups as VanessaE describes
22:14 sapier yes and prediction is why we see that huge lag on node placement now
22:15 Zefram_Fysh I'm neutral on whether an intermediate (pending client-side lua) inventory prediction mechanism is worthwhile
22:15 sapier 1475 fixes a race condition where a node update is lost due to prediction this bug got undetected for years
22:16 sapier well prediction and a quite insane way of error hiding
22:17 sapier but kahrl if you find a way to do prediction without messing all up and in best case in a way the code can be reused once client side lua is there too ... that'd be great :-)
22:17 kahrl I'll try :)
22:17 Zefram_Fysh I've noticed that placement prediction interacts not-brilliantly with block updates: upon receiving update the client drops all its predictions of actions that were performed later than what the update is based on.  which gets messy if you have big network lag between client and server
22:17 kahrl can you explain the 1475 issue so I can avoid it?
22:17 sapier or ... maybe you'll try to fix the mess ShadowNinja made on changing players to be dynamic objects
22:18 sapier 1475 happens if you do a lot of modifications in same block
22:19 VanessaE sapier: OH that reminds me!
22:19 sapier if a node change happens while a block update is "in wire" that update is lost
22:19 VanessaE sapier: easy way to reproduce that!   Worldedit, select two positions  with //pos1 and //pos2  stand INSIDE the selection  and do //clearobjects (with two slashes).  There's a good chance YOU will be deleted.
22:19 sapier result is nodes "reappearing"
22:19 sapier but
22:20 sapier there once was added a "workaround" causing blocks around a player to be resent periodic
22:20 VanessaE sapier: ^^^^ the player-deleted bug I mean.  I discovered this way-to-reproduce by accident the other day while testing something only tangentially related.
22:20 sapier that resend fixes the lost update
22:20 sapier but there are several seconds between the periodic updates
22:21 kahrl sapier: ah, I see.
22:21 sapier 1475 can't prevent the client prediction form beeing reverted by the "on wire" update
22:22 sapier but that block is marked to be updated immediatly after the in progress block update is finished thus it's just about 2 rtt's to get back to consistent state
22:22 sapier same thing, server side update reverting your prediction, could happen on any prediction case
22:23 nore_ joined #minetest-dev
22:25 Zefram_Fysh could be avoided by the server's update carrying a sequence number identifying what was the last action from the client that's reflected in the update
22:25 sapier VanessaE: how to reproduce?
22:26 sapier that update was most likely sent on purpose if you just ignore it you'll get inconsistency in client map
22:27 Zefram_Fysh client would then predict state amounting to the last state received from the server modified by all actions it's queued up that were not reflected in the update (as judged by the sequence numbers)
22:27 Zefram_Fysh obviously drop prediction for any action that the server has taken into account
22:27 PenguinDad VanessaE: the player deletion when using //clearobjects is probably caused by how worldedit deletes the objects
22:27 sapier Zefram_Fysh: you still don't know why that block is back there
22:28 sapier if server disallows node diging same block update would be received
22:28 sapier if someone else would place that block immediatly after you dug it same thing would happen too
22:29 sapier block updates aren't one action one block update but cumulate multiple actions
22:29 Zefram_Fysh indeed, if the server disallows a dig then the node will still appear in an update that takes the dig attempt into account, and the client doesn't know exactly why the block is still there
22:29 VanessaE sapier: all you gotta do is select an area with //pos1 and //pos2 that's big enough for you to stand in, step in, drop a stack of something, and issue //clearobjects.
22:29 VanessaE PenguinDad: I doubt it - it never did that before.
22:30 Zefram_Fysh all I'm suggesting should change is that the server should say which (attempted) actions it's considered to produce the update, so that the client knows which ones it should still be predicting
22:30 sapier Zefram_Fysh: 1475 (almost) fixes the issue completely ... only in high latency situations there's a noticable delay ... I don't think that issue is worth spending a lot of time on it
22:31 kahrl VanessaE: I guess object:remove() should refuse to do its job when the object is actually a player
22:31 Zefram_Fysh high latency does randomly happen, and it's worth putting in effort to get cleaner results in that case
22:31 VanessaE kahrl: indeed -- in perhaps all cases short of destroying the player object on sign-off
22:31 sapier Zefram_Fysh: that'd be a major and especially performance killing change in network protocol
22:31 kahrl seems simple enough
22:31 Zefram_Fysh how would it kill performance?
22:32 sapier because you can't cumulate block updates if you have to send each update/action combination back to ALL clients
22:32 Zefram_Fysh you don't have to do that
22:32 sapier you do
22:33 sapier and even if you do you don't catch the two player scenario
22:33 VanessaE sapier: shall I update my repo and merge #1475 for testing?
22:33 sapier I think it's worth it
22:33 VanessaE ok, willdo
22:34 sapier Zefram_Fysh: btw that bug got almost unnoticed for years ... I just discovered it because of android clients beeing quite slow and causing that race condition quite often
22:34 Zefram_Fysh in what I'm proposing, you don't have to update any more than you do now.  you only echo the sequence numbers back to the specific client who produced them, and range treatment of the sequence numbers is implicit.  it's only to let each client determine which of its own actions it still needs to predict
22:35 kahrl sapier: well, I'll use tc to test the inventory prediction under high latency conditions
22:35 sapier Zefram_Fysh: still a client would have to MERGE a block to his own block
22:35 Sokomine regarding inventory movement prediction: most cases really ought to be pretty simple ones. either it's a non-locked chest, a bag the player is carrying, or something where access is limited. quite a lot of that could be predicted if an inventory list could be set to "open for all", "only owner and people who may dig here" or "custom". the first two cases might cover a lot
22:35 Zefram_Fysh if you have lag between two players, you can't avoid a problem there, and I'm not addressing that.  I'm only considering the predictions that a single client makes based on its own actions.  clients don't predict what other clients would do
22:36 Sokomine there's still that bug the circular saw suffers from where the engine disregards allow_metadata_inventory_* functions. celeron tried to fix it, but that disabled inventory swapping alltogether
22:36 kahrl Sokomine: yeah, the second case has been troubling me though
22:36 Zefram_Fysh yes, it would involve some merging of state, and so a bit more client-side CPU use.  not a network killer, and probably not a problem at all.  hell, in the usual low-latency case, the client's prediction queue will be empty, so there'll be no merging to do
22:36 kahrl how can the client know who the owner(s) are?
22:36 sapier if you do that sequence number thingy client would have to store all actions and reapply them to each block he gets ... possible ... but for what? a scenario happening about once per 1000 node digs?
22:36 Sokomine most of the time it's listed in the metadata
22:37 Sokomine very very often in a convenient "owner" string
22:37 sapier server would have to store a sequence number per block AND client
22:37 kahrl Sokomine: but if it's area protection?
22:38 Sokomine kahrl: then it does indeed get more complicated. but that's only of intrest for shared things. could be handled like "custom" - that is, the client doesn't know weather it will work or not - unless "his" player is the "owner"
22:38 VanessaE sapier: ok, deployed to all servers.
22:38 Zefram_Fysh sapier: as to frequency, I've been seeing it loads with Vanessa's technic testing server.  it and I are not poorly connected, though maybe its host is a bit busy
22:39 kahrl Sokomine: I'll probably do it that way then
22:39 kahrl anything else would be violating KISS
22:39 Zefram_Fysh server would have to track a sequence number per client, not per block and client
22:39 Sokomine a huge amount of felt lag was introduced by locked chests using a function based on ownership to show a formspec of their contents (if it's their owner) or nothing else. that was horrible
22:39 sapier Zefram_Fysh: what do you see on vanessae's server .. lag doesn't mean it is this bug
22:39 Zefram_Fysh the sequence number would go in each action packet from the client and each update from the server.  16 bits if you're stingy
22:40 sapier no zeftram it's per block and client as block changes are sent out of order
22:40 Sokomine i did experience strange lag when moving things around inside my own inventory today on jordachs server. this did not happen yesterday
22:40 Zefram_Fysh the *actions* are processed in order.  doesn't matter which order block updates are sent in
22:40 sapier even if a block is changed first it's update may be sent after another update
22:40 sapier still actions are not sent back to server
22:40 sapier -server +client
22:41 Sokomine my version has not changed since then
22:41 Zefram_Fysh yes, I'm not asking for actions to be echoed back to clients
22:42 sapier e.g. block A is modified by an action, block b is modified by another action
22:42 Zefram_Fysh the client numbers the actions, the server keeps track of the last number it saw from each client, and when sending out a block update the server says to the client what the last action number it saw from that client was.  that's all.  dirt cheap for the server
22:42 sapier block b is sent because of higher priority
22:43 sapier now another action comes modifying block C
22:43 sapier -C
22:43 sapier forget last action
22:43 Sokomine kahrl: the bug no one has had any really good ideas as to how to fix yet (apart from celerons attempt) is #944. the effects are item loss/item duplication. the lua api is unreliable in this aspect as its functions are not called before items are inserted into lists (for temporal storage)
22:44 VanessaE stand by before you evaluate my server.  I need to address an unrelated screwup.
22:44 kahrl Sokomine: I heard of that bug, how did celeron's attempt go?
22:44 sapier now block A is enqueued with sequence number of c
22:45 kahrl oh I see your comment
22:45 Zefram_Fysh what I've specifically seen on Vanessa's server is that as I'm digging a bunch of nodes, initially they're shown to disappear (dig prediction), then some of them from the middle of the sequence reappear (presumably a block update that doesn't incorporate those later digs), then a few seconds later the spurious ones disappear again (presumably another block update that does incorporate those digs)
22:45 Sokomine kahrl: he sent me a patch. unfortionately that disabled *all* inventory swap actions - even in situations where there was no problem with it (i.e. simple locked chest, or just inside inventory)
22:46 sapier yes zefram but that's almost completely fixed by 1475
22:47 Sokomine zefram: yes, that happens a lot. it's so common one stops to notice after a time. usually it's not really a big problem when mining. it's slightly annoying when the block below you suddenly disappears while you're balancing somewhere high, but that's about it
22:47 sapier you could be right one sequence number might be enough ... still you add a lot of additional complexity and bug reasons without a major benefit
22:47 VanessaE sapier: ok, my servers are back up.  minetest_game is now at HEAD, as is the engine, plus #1475
22:47 Sokomine in general, it works pretty well on most servers. lag becomes more obvious when i.e. crafting something or moving inventory around
22:48 sapier Sokomine: Zefram_Fysh vanessae just updated her server could you try and validate this fix does same for you as for me
22:48 Sokomine sapier: ok. anything special to look for?
22:48 proller joined #minetest-dev
22:49 sapier dig a lot of nodes and see if they reappear just to disappear some seconds later
22:49 kahrl Sokomine: true about the balancing thing. That's one area that the other voxel game does better
22:49 Zefram_Fysh 1475 is a workaround for the problem, and it's nice that it doesn't require a client update to work.  I still reckon that the action sequence number I proposed is a real *fix* for the problem, and very little additional complexity
22:50 Zefram_Fysh will try it now...
22:50 sapier no it's not
22:50 Sokomine kahrl: it is just an issue when the server's close to breaking down anyway
22:50 sapier your sequence number thingy is a lot of additional complexity for an issue not existing
22:50 sapier server missing a block update is a bug ... making it send it is not a workaround at all
22:51 sapier imho the cyclic sending of blocks is a workaround and should be removed completely
22:51 kahrl I was building a bridge 100+ nodes above ground in a Super Hostile map once, when suddenly a block I placed disappeared
22:51 Zefram_Fysh it's a small additional complexity for an issue that at least existed a few days ago when I thought about it.  maybe 1475 makes it not a practical issue now
22:51 sapier yes that could've been this bug
22:51 kahrl I fell down, but then reappeared on top of the bridge because the server also simulates everyone's physics
22:52 sapier it's not a small additional complexity it's delta updating of blocks
22:52 Zefram_Fysh I think you're still misunderstanding my proposal, then
22:52 sapier then please try again
22:53 Zefram_Fysh trying now on VE's server, I'm seeing something different: still getting reappearance, but it's very brief, gone in 200 ms
22:53 Zefram_Fysh so that's a great improvement, but not totally fixed
22:53 sapier seems to be slow connection but that's about what I expected
22:54 sapier tell me again how you intend to fix it
22:56 sapier ok then don't tell me ... but keep in mind that once we removed that cyclic workaround you won't get a block update on successfully digging a block  at all
22:57 Zefram_Fysh my proposal: client includes a sequence number (16-bit cyclical) in each packet to the server describing an attempted action.  no other change to protocol in that direction; no change in when packets are sent.  server processes actions as it does now, but additionally records for each client the last action sequence number it saw.  that's one sequence number per client.  the server sends packets to the clients exactly as it does now: no additional
22:57 Zefram_Fysh (takes a while to type in, patience please, more coming)
22:57 sapier you don't know how I hate 1 bit values
22:57 sapier 16
22:58 kahrl why not use the existing sequence number?
22:58 kahrl of course, there would have to be a way to get the value from Connection
22:58 sapier because it's not part of application layer protocol
22:58 Zefram_Fysh if there's a sequence number already, so much the better.  I don't know the protocol in that detail
22:59 sapier there ain't a sequence number
22:59 sapier it's 3 sequence numbers, one per channel not connected to each other, different per send and receive direcetion
23:00 sapier so actually 6 sequences per client
23:00 sapier still a client would have to store all it's actions and redo them once a packet arrives with a sequence number smalle then the actions one
23:01 sapier for the block of the packet of course ... still the list of actions would have to be traversed
23:02 Zefram_Fysh the client keeps a note of the few most recent actions that it predicted will change nodes.  when it receives a block update from the server, if the sequence number echoed in that update doesn't match the last predicted action that it sent to the server, then it replays the intervening predicted actions onto the block state received from the server.  that maintains the predictions.  client discards a predicted action when an update is received for
23:02 Zefram_Fysh typically that's going to be a single-digit number of predicted actions kept
23:02 sapier depends
23:03 sapier if someone does digging only the number can rise to infinite
23:03 paramat left #minetest-dev
23:03 Zefram_Fysh I'd be happy to work up a patch for this, if you're not vetoing it out of hand
23:03 sapier if you handle all cases, e.g. block unloading by server without sending an update
23:04 Zefram_Fysh if the server isn't sending updates after an unlimited number of pending actions, you have a bigger problem.  in general you do need a timeout or something equivalent to deal with things like unloaded blocks
23:04 sapier there are a lot of corner cases ... as you intend to fix a quite small issue I'll not accept a solution not handling the corner cases
23:04 sapier why?
23:04 Zefram_Fysh why what?
23:04 sapier there aren't pending actions as of server perspective
23:04 sapier the dig is done
23:05 sapier if it's successfull we don't shadow it back to client
23:05 Zefram_Fysh I appreciate the need to deal with corner cases.  I tend to program from the corners inwards, actually
23:06 sapier to be honest right now we do this insane cyclic update which is a incredible waste of network bandwidth and was added for some reason that should've been solved in a better way
23:06 Zefram_Fysh yeah, point taken, but you'd expect to get updates from the server eventually.  not about each specific action, sure, but if you're sending unlimited actions and getting no updates back then statistically it's more likely that communication has been lost
23:07 VanessaE block place/dig lag is much better, but inventory lag is about as bad as it ever was
23:07 sapier once you place a block you'll get a block update ... and yes it's not very likely to have a lot of actions pending ... but there are corner cases where this can happen (once the bug is fixed)
23:07 Sokomine which server is the testing going on at? or is it finished already?
23:07 VanessaE I'm playing on my FreeForAll server
23:08 Sokomine ah, that one *moving*
23:08 VanessaE just building some roads right now.
23:08 sapier if you want that sequence number add it to client interface
23:09 Zefram_Fysh so yes, corner cases matter, the client mustn't hold an unbounded amount of pending state
23:09 sapier no actually the client HAS TO hold them
23:09 sapier if client doesn't his map will get inconsistent
23:10 kahrl how about: if (number of pending updates > 9000) { report_error("Connection to server lost."); exit_to_main_menu(); }
23:10 Zefram_Fysh er, by "pending state" I was specifically referring to the queue of not-yet-superseded action predictions that is a feature of my proposal
23:10 Zefram_Fysh I'd rather not reuse it as a way of detecting communication loss
23:11 sapier yes digg 9001 nodes and you'll be there
23:11 Sokomine players eventually notice once connection to the server is down. may take a while, but inventory changes are always returned then. krock did something helpful on his server: he has added a mod that sends a message at shutdown
23:11 Sokomine (formspec message. so it doesn't get easily missed)
23:11 sapier I don't think it's menat as communication loss detection but client side error handlig
23:12 sapier actually client doesn't even have to send the number
23:12 sapier it's enough if server counts client actions
23:13 Zefram_Fysh as long as the action sequence is transmitted reliably, yes, the sequence number could be implicit.  good point
23:13 sapier no
23:13 Zefram_Fysh no what?
23:13 sapier don't use the protocol sequence numbers
23:14 kahrl I don't thik Zefram meant that
23:14 kahrl think*
23:14 sapier hmm could be
23:14 kahrl just # of dig/place actions sent so far
23:15 Zefram_Fysh a specific sequence number for actions could be implicit, defined as the number of relevant actions sent.  I think that's what you just suggested, and I agree
23:15 sapier ok then next thing to find out is if block updates are even sent to clients directly
23:15 sapier or broadcasted
23:15 Zefram_Fysh multicast block updates would indeed screw my system over
23:15 VanessaE sapier: still seeing dropped updates coming across.
23:15 VanessaE if that makes any sens
23:15 sapier define "dropped updates"?
23:15 VanessaE +e
23:16 VanessaE place some blocks, a bit later they disappear, a bit later after that they re-appear, but not *all* of the placed blocks re-appear.
23:16 VanessaE every so often a few of the placed blocks were never recorded
23:17 sapier ok blocks are sent client specific so you can include the action sequence number in ther
23:17 sapier e
23:19 Sokomine regarding tests: i can confirm that short flash of blocks reappearing after digging (and immediately after disappearing). i even managed to trap myshelf for a split second in stone
23:19 sapier right now I don't see other issues except of the building up pending actions ... which most likely wont happen as long as we have the cyclic update
23:20 Sokomine compared to what i've experienced on other servers, it's extremly harmless. it used to be so bad that a tunnel digged closed after the player in the past (long ago with older versions)
23:20 sapier the only way how it might happen now is if someone digs a block and moves away far enough to unload that block prior update beeing sent ... unless server sends a unload message but I don't think that's done
23:21 sapier guess you'd have to actively do bad things to get stall actions this way
23:23 ^v joined #minetest-dev
23:24 Zefram_Fysh is the server aware of which actions the client will predict?  it has the necessary information, as it's telling the client which things to predict in the first place.  if so, it could predict the client's prediction and take that into account in deciding whether a client needs a block update.  send final update before unloading, that sort of thing.  it's sounding a bit more complex than my scheme for preserving client prediction, though
23:25 sapier partial
23:25 Zefram_Fysh (and, to be clear, anything based on that train of thought would be quite separate work from what I proposed earlier)
23:25 sapier as digging always results in a "air" block that is assumed to be handled by client
23:25 sapier so if digging really results in "air" no update is sent
23:25 Zefram_Fysh aha
23:26 sapier replace "air block" by "air node"
23:26 Zefram_Fysh so we could extend that system to placement prediction to avoid sending some updates that are unnecessary because the client accurately predicts them
23:26 sapier a client doesn't need a block update prior unloading that's insane ;-)
23:27 sapier a block is unloaded because of noone beeing next to it why waste network bandwidth ;-)
23:27 Zefram_Fysh clients still render blocks that the server has unloaded
23:27 Zefram_Fysh I do like being able to see into the distance
23:27 sapier yes but client already knows the latest state of that block
23:28 Zefram_Fysh well, the client *thinks* it knows the latest state.  it could be wrong due to incorrectly-predicted actions
23:28 sapier which can't be true
23:28 Zefram_Fysh that's one of the corner cases affecting my proposal
23:28 Zefram_Fysh can't?
23:28 sapier as if the brediciton would've been wrong server would've sent an update
23:29 sapier as I said we only do dig prediction
23:29 sapier placing is always updated
23:29 Zefram_Fysh ok
23:29 sapier well especially for placing the sequence numbers will help
23:30 sapier ... the bad thing is you have to manipulate map at a very low level as each regular modification will trigger another action to be issued
23:30 sapier well there's way to do this just make a suggestion
23:31 Sokomine client prediction might also be intresting for crafting. that is when lag becomes most obvious. another intresting case would be to add general support for "entitiy is on rails" to the client
23:31 sapier that's not even related to what Zefram_Fysh is doing ;-) ... and way more complex
23:31 Sokomine wishing doesn't cost :)
23:32 sapier in this case ... I want 20 degrees at night and a pool and a new car ... a lot of money
23:32 sapier ;-)
23:33 * Sokomine throws sapier in one of the pools digged by the next inexperienced builder on the next random server, creates a bunch of minegeld notes via /giveme, even grabs a car from somewhere, but can't do anything about the 20 degree
23:34 Sokomine :-)
23:34 sapier well a empty pool without some nice women around ... come one you can do better
23:35 Zefram_Fysh I'd like an entity-on-rails system as a generalisation of sapier's timed-move stuff.  been thinking about how to do that
23:35 Sokomine er...you get lots of children around it who'll go on your nerves and won't let you relax :-)
23:36 sapier Zefram_Fysh: sorry but you mixed up "generalization" and "specialization" ;-P
23:37 Sokomine such an entity-on-rails system would be very fine. there are of course limits. but right now, carts are something where things soon look very odd - they speed for some time in the wrong direction. that's not dramatic most of the time (just an optical glitch..though optics play a huge role in a game such as this); sometimes there's more chaos
23:38 sapier what Zefram_Fysh most likely wants is environment dependent movement .. which isn't at all related to the timed move feature as that one doesn't have any dependencys to environment
23:38 sapier and for what I believe it's not even necessary
23:40 Sokomine the idea behind the timed move was to stop entities from going on and on into infinity, wasn't it? if they hit the end of their respective rail(environment), that might in some cases already be enough
23:40 Zefram_Fysh what I'm thinking of is that instead of the entity just giving one position/velocity/acceleration tuple, it would give multiple such tuples (probably limited to two or three) with durations for each
23:40 sapier you already can give it two
23:41 sapier maybe three would be better 1 initial speed second speed after direction change third catch runaway
23:42 Zefram_Fysh your patch lets you do two velocities and accelerations, but not specifying a position to jump to when starting the second leg of motion, and not specifying a time at which the second leg stops
23:42 sapier I won't add any positions ever
23:43 Zefram_Fysh yeah, want three for that reason, but the third leg can be limited to zero velocity and acceleration
23:43 sapier as you can't mix up positions ans speed
23:44 Zefram_Fysh adding a position at which to start the second leg means that you get over any arithmetic difficulty with the time, including anything arising from time steps, and it allows for item teleportation, which pipeworks wants for tubed items
23:44 sapier engine just doesn't handle positions for movement and you get a lot of additional corner and partial cases if you add positioned movement
23:44 sapier no it ain't that simple
23:44 sapier what do you do if you set a position but change acceleration to a value where the position is never reached?
23:45 sapier or you miss that position by some distance
23:45 sapier then you have to add some some range around it
23:46 Zefram_Fysh that's why you have to treat the start position for the second leg as a teleportation.  normally this position will be almost identical to where the first leg got the entity to at the appointed time
23:46 sapier next thing what if server step is delayed for 2s (worst case scenario) thus you pass that position
23:46 Zefram_Fysh ah, I see the confusion.  I'm not proposing that the movement leg be *delimited* by position.  I'm proposing that it be delimited by *time*, as in your patch, but that the position be reset when switching leg
23:47 sapier why?
23:48 sapier e.g. if something blocks a entities path for what reason should it jump there maybe through a wall?
23:48 Zefram_Fysh as I said, resetting the position fixes the problems that would occur with delayed steps, getting the entity back onto the intended rail.  (though I also have another idea about addressing that.)  but it also allows for actual discontinuities in motion, which pipeworks at least does want
23:49 sapier and adds the problem that you have to decide if it's allowed to jump there
23:49 Zefram_Fysh entity motion is not currently impeded by walls, at the level we're talking about.  no change there.  it's up to the entity code to decide whether to make the entity jump, just as it already is
23:49 sapier it is
23:50 sapier a entity can be defined physical which e.g. mobf does
23:50 sapier then all the collision handling is done
23:51 Zefram_Fysh ah, I'm not familiar with that bit.  my comments don't directly apply to physical entities, then.  I'll get back to you on how my version of motion-on-rails should interact with physical entities
23:52 sapier actually imho using non physical entities for moving things is strange as especially moving ones require collision handling
23:53 Zefram_Fysh that's a case-by-case issue.  I'm sure some could be improved by being physical
23:54 sapier especially movement is quite specific I don't really believe we get a all in solution in core ... you can emulate most things by lua and the timed version. not all of course
23:54 Zefram_Fysh pipeworks definitely doesn't want general collision detection for tubed items, but collision detection that it can disable for tube-capable node types could be a neat way to handle tubes being dismantled mid-move
23:54 sapier but e.g. if you have a multi s curve trac you'd need infinite path lengths anyway
23:55 sapier pipeworks does have design issues anyway
23:55 sapier engine isn't designed to have things acting far away from player on their own
23:56 Zefram_Fysh that's a separate issue
23:57 sapier yes but using a mod as example that actually can't ever work correct without major design changes in engine isn't a quite good decision
23:59 sapier but lets do it step by step, first implement that sequence number thing for actions ;-)

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