I would like to connect two distant rail pieces by rail, avoiding obstacles along the way like the built-in rail planner already available to players. Since the functionality already exists, I expected it to also be available to scripts.
Please add a function that takes two rail pieces or positions (start and end), direction (for start and end), path-finding options (avoid obstacles or not, allow elevated rails or not, etc), and returns an array of either rail ghosts that were created, or rail piece data (like a BlueprintEntity, so one could create the rails as ghosts, or do something else without potential side-effects of ghosts being created).
Rail Planner
-
SupplyDepoo
- Filter Inserter
- Posts: 286
- Joined: Sat Oct 29, 2016 8:42 pm
- Contact:
Re: Rail Planner
Short answer: No.
Slightly longer answer: Noooooo.
Full answer:
1/ Rail plan finder as you can see when using a rail item is actually implemented as client side feature. Only the client that is planning the path has its CPU working on finding possible solutions and once you confirm build the specific result is wrapped into an input action so it is properly introduced into a game state. Given that a rail plan finder was never implemented with a determinism in mind i cannot simply move it into game state to provide it through a Lua API without verifying it is actually deterministic. No (nr.1) is that it is not guaranteed deterministic.
2/ Rail plan finder is really expensive because of large amount of heap allocations and expensive collision checks. Using it would either result in a update time spike or it would have to be limited to a relatively small number of steps before returning a no result. No (nr.2) due to performance.
3/ Given that rail plan finder is only running on clients and its state is out of game state, it is using a lot of traits of this environment like being able to run incrementally on multiple ticks without worrying about state serialisation. If rail plan finder would be required to be part of game state for the purpose of exposing it to lua api, it would be required to have it also able to run incrementally across multiple ticks which would require state serialisation which right now was never required. No (nr.3) due to need to add extra complexity for something base game is not using.
Even if point 3 would be decided not important, in 1.1.x a rail plan finder only does 200 steps in a single render frame and there are internal limits of work up to 50000 steps so in order to give up on state serialisation, the entire rail plan finder would have to be completed within a single tick the request came in which means up to 250x computation time spent within a single update tick when doing a lot of expensive buildability checks.
Short answer: No.
Slightly longer answer: Noooooo.
Full answer:
1/ Rail plan finder as you can see when using a rail item is actually implemented as client side feature. Only the client that is planning the path has its CPU working on finding possible solutions and once you confirm build the specific result is wrapped into an input action so it is properly introduced into a game state. Given that a rail plan finder was never implemented with a determinism in mind i cannot simply move it into game state to provide it through a Lua API without verifying it is actually deterministic. No (nr.1) is that it is not guaranteed deterministic.
2/ Rail plan finder is really expensive because of large amount of heap allocations and expensive collision checks. Using it would either result in a update time spike or it would have to be limited to a relatively small number of steps before returning a no result. No (nr.2) due to performance.
3/ Given that rail plan finder is only running on clients and its state is out of game state, it is using a lot of traits of this environment like being able to run incrementally on multiple ticks without worrying about state serialisation. If rail plan finder would be required to be part of game state for the purpose of exposing it to lua api, it would be required to have it also able to run incrementally across multiple ticks which would require state serialisation which right now was never required. No (nr.3) due to need to add extra complexity for something base game is not using.
Even if point 3 would be decided not important, in 1.1.x a rail plan finder only does 200 steps in a single render frame and there are internal limits of work up to 50000 steps so in order to give up on state serialisation, the entire rail plan finder would have to be completed within a single tick the request came in which means up to 250x computation time spent within a single update tick when doing a lot of expensive buildability checks.
Short answer: No.