Time Nick Message 05:26 Eater4 Can anyone get the irc mod working on unbuntu server? 05:45 Miner_48er Eater4 what's the problem? 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. 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: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: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 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: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 ;-)