Path finding - The stuff that allows units to get from point A to point B.
Lua - Magical stuff. That's all that is needed to describe it.
Currently, the pathfinder is very inflexible with the way it calculates its paths. I would like to see that change though.
What I want to see, is a way for the pathfinder to temporally allow Lua to take over. When lua does have control, it can either define the rest of the path itself, or just define a small part before letting the pathfinder do the rest.
My suggestion is we define areas on the map with lua, that simply tells the pathfinder that lua can find a faster way between any two of them. From the lua side, you could either just specify some weighting information, or tell it to assume that any unit using any shortcut provided by this feature will behave and act as another unit during the duration of the trip, so that the pathfinder can get an idea of how to determine if it would truly be shorter or not.
One immediate example that comes to mind: Imagine a transporter managing script that works by exposing a transporter's pickup and drop off zones to the pathfinder. Normally only units that are set to go within the pickup zone will be picked up, moved, and dropped off at the drop off zone. But with a widget using my suggestion, ANY unit that could gain an advantage from the transporter would be able to use it without extra effort from the player. If you even want, you could perhaps allow units to use the drop off and pickup zones in reverse, allowing a quick retreat when needed.
Another few examples that comes to mind is allowing some exotic movement that can't normally be defined without lua, such as defining a bridge, tunnel, or a feature with movable surfaces. With this idea, making lua capture commands and decide own its on whether or not a unit should use a bridge or not could all be done with this feature. In fact, this could be seen as one of the first steps needed to realize workable bridges in spring.
With a feature such as this, combined with the ability to better define a movable surface upon a feature, or even on another unit, we can change the way me make maps, the way widgets will handle precise movement of units, and even take battles to new heights!
Optionally, I would also like to define a "floating surface," an area that isn't attached to the map directly that defines a surface for units to move on. Information such as geometry needed for the pathfinder could be provided in form of type of height map. You could then seamlessly connect it to the map's main geometry using the proposed lua-path finder interactions. I heard that this is already mostly possible with lua, so perhaps just defining this in the pathfinder would suffice?
Please consider this idea, discuss it thoroughly, and try to realistically find any solutions to any flaws that may be present. Perhaps you know of a better way this could work? Feel free to post that here as well.
I might provid diagrams to better demonstrate what I mean later on if this is seriously being considered.
If I could better understand the path finding of spring, perhaps i'll even help out? Where could I find out how the pathfinder works, aside from reading the source code? Is anyone familiar with the pathfinder enough to give me a quick explanation on how it works? Assuming that I do in fact get the free time I want from my RL, and if I decide to help, how would I begin coding such feature request? I'm pretty sure that this would have to go in a separate git/svn branch/repository, just like what is being done for the ROAM version of spring.
More advanced path-finder - LUA interaction
Moderator: Moderators
Re: More advanced path-finder - LUA interaction
TL;DR
Pathfinder is the most CPU costly thing in RTS. So the only thing where C speed really matters.
But then I am no dev, so don't trust my words.
Pathfinder is the most CPU costly thing in RTS. So the only thing where C speed really matters.
But then I am no dev, so don't trust my words.
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: More advanced path-finder - LUA interaction
Yeah - doing the pathfinder in Lua is no good idea. Instead of hacking the pathfinder to allow Lua extensions immediately integrate the additions / changes into it on the C level...
Re: More advanced path-finder - LUA interaction
when I tested MT spring on a low-clocked multicore cpu, the biggest hit was initial pathfinder 

Re: More advanced path-finder - LUA interaction
It sounds like you want:
1) a declarative way to add new paths between arbitrary points on the map with an arbitrary cost
(would be used to make units aware they can cross river using bridge unit X once that's deployed; to make units aware they can get somewhere faster by driving away from it and then entering some teleport, etc.)
and
2) a way for Lua to optionally take over path following the moment the unit actually reaches the begin of such an arbitrary path
(would be used to give the unit or the bridge instructions to actually move the unit over the bridge; instructs the unit to enter the teleporter unit, instructs the teleporter unit to load the unit, etc.)
EDIT: to clarify, I think there's an important distinction between 1) making units aware of the existence of a shorter path and 2) implementing the logic required for the unit to actually travel along this path.
1) a declarative way to add new paths between arbitrary points on the map with an arbitrary cost
(would be used to make units aware they can cross river using bridge unit X once that's deployed; to make units aware they can get somewhere faster by driving away from it and then entering some teleport, etc.)
and
2) a way for Lua to optionally take over path following the moment the unit actually reaches the begin of such an arbitrary path
(would be used to give the unit or the bridge instructions to actually move the unit over the bridge; instructs the unit to enter the teleporter unit, instructs the teleporter unit to load the unit, etc.)
EDIT: to clarify, I think there's an important distinction between 1) making units aware of the existence of a shorter path and 2) implementing the logic required for the unit to actually travel along this path.
Re: More advanced path-finder - LUA interaction
I'm in favor of exposing this stuff, if possible. There are a lot of ways we could probably make pathfinding faster, if we could turn it off and take direct control in some situations. And it would allow me to finally see cars that stay on roads, which they don't, even after Kloot's patch allowed me to play with the typemaps and make them super-attractive.
Re: More advanced path-finder - LUA interaction
1) can be easily handled by exposing the weight function to lua. con: CPU usage will increase, and probably will increase _a lot_.
2) is just hard. we could add a lua callin that would return wanted velocity vector, but again, it'd probably be prohibitively expensive CPU-wise.
2) is just hard. we could add a lua callin that would return wanted velocity vector, but again, it'd probably be prohibitively expensive CPU-wise.