Spidertron instantaneous acceleration/deceleration

[azaghal]

'ello all,

To give some background, I am working on a mod that would allow templating (export/import) of vehicle equipment grids using blueprints. The export part was fairly simple, but import is giving me some headaches. The import code is currently based on using the item request proxies to deliver equipment via construction bots directly into the vehicle (with some code handling moving items from inventory into equipment grid etc).

However, this is turning out to be rather unreliable because some vehicles may or may not have an inventory etc. Now I am considering an alternative approach of trying to again use item request proxies, but this time around against an entity with an inventory that would act as an intermediate for final delivery into equipment grid. This way I could have a reliable and uniform delivery into an inventory of sufficient size, from which I could then move equipment into equipment grid of target vehicle entity.

Instead of creating some kind of invisible chest that I would move around periodically to match-up position with destination vehicle entity, I've been looking into maybe creating an entity based on spidertron instead, and utilising the LuaEntity::follow_target property. This way I would be able to have a moving inventory that would follow the target vehicle and have roughly the same position as the target vehicle entity, and with the item request proxies layered on top (and cancelable by player via right-click).

For this to look and work somewhat sanely, I would like to implement a spidertron entity (prototype) that would:

1. Have high base top speed in order to be able to keep-up with most vehicles.
2. Have ability to stay on top of exact position, without overshooting (when target vehicle is not moving).
3. Instantly accelerate and decelerate (avoiding speed-up/wobble etc).

So far I have fiddled around a bit with an entity prototype where I have a single spidertron leg, trying to adjust parameters like initial_movement_speed, movement_acceleration and movement_based_position_selection_distance, but I haven't been able to find more info on the algorithm behind speed and position calculation.

So, would anyone have an idea on how I would be able to achieve the three listed goals above for spidertron?

Best regards,
Branko

P.S.
Truth be told, I am starting to think that having an invisible chest-style container and doing periodic position updates might be the simpler way to go forward - at the expense of it looking a little bit ugly as it gets moved around.

[Xorimuth]

Not sure how feasible this would be - spidertrons do wacky stuff at high speeds (viewtopic.php?p=569165#p569165).

[azaghal]

Hm... Yeah, looks like it would be difficult to do what I've asked for. It felt like the right thing to do, but it's probably not worth it.

In the meantime I've went ahead and implemented a small prototype where I use a custom car entity (since I need some form of container entity that can teleport/change position) combined with script.on_nth_tick event handler (on demand) to keep the "delivery box" entity on top of "requesting" entity.

So far it seems to work well, the item request proxy associated with delivery box entity will lag behind the original entity a bit, but I think that should be tolerable quirk compared to benefits. Might need to think a bit about performance in case I estimate that there might be too many delivery box entities around, though.

Thank you for providing me with the answer and the link

[Xorimuth]

Hm... Yeah, looks like it would be difficult to do what I've asked for. It felt like the right thing to do, but it's probably not worth it.

In the meantime I've went ahead and implemented a small prototype where I use a custom car entity (since I need some form of container entity that can teleport/change position) combined with script.on_nth_tick event handler (on demand) to keep the "delivery box" entity on top of "requesting" entity.

So far it seems to work well, the item request proxy associated with delivery box entity will lag behind the original entity a bit, but I think that should be tolerable quirk compared to benefits. Might need to think a bit about performance in case I estimate that there might be too many delivery box entities around, though.

Thank you for providing me with the answer and the link

You're probably better off using a container than a car, you can give it the "placeable-off-grid" flag if you don't want it to snap to the nearest integer position. I'm sure the game does less processing for a container than for a car, so it is probably slightly more efficient. The only thing that you'd be losing (that I can see) is the ability to teleport between surfaces.

[azaghal]

Ah... I've misread (or skimmed more likely) the error message that I received when trying to teleport the wooden chest. I was passing-in the surface as well, and didn't realise that was the thing preventing the chest from being teleported. Thanks for pointing out that one.

Hm... I'll have to think about it a bit. If the performance hit is not large, I might stick with the car for now for simplicity sake (to avoid having to recreate the delivery box and item request proxy), but we'll see. Once I get the code sorted-out a bit more I might revisit (don't think that recreating the container should be really that complicated).

Thanks once again for the input and feedback

[Pi-C]

You're probably better off using a container than a car, you can give it the "placeable-off-grid" flag if you don't want it to snap to the nearest integer position. I'm sure the game does less processing for a container than for a car, so it is probably slightly more efficient. The only thing that you'd be losing (that I can see) is the ability to teleport between surfaces.

While teleporting to another surface doesn't work for containers, you should be able to clone them and destroy the original. The downside is, you've got to update your data so that the new container.unit_number will be stored.

[azaghal]

To follow-up on this topic, I ended-up using plain container entities, and recreating them (instead of cloning) if the target entity's surface changes. Cloning is not required since I empty out the container as the first step of processing (basically install the equipment into grid or just spill it on the ground and order deconstruction of items).

Thank you both once again for providing help and input on the topic, I am super happy I did not have to deal with spidertrons nor cars to implement this mod