Heyas,
Sorry if this is in the wrong forum section, but I'm super curious about this particular commit: https://github.com/spring/spring/commit ... f78a41c54f
Is the goal of this to implement a ZK-like raw movement on a free path -thing straight to the engine, allowing units to try to use raw movement without Lua scripting for it?
If so, how do we enable this? I can see that we need 'allowRawMovement ' to moveDefs, but how can pfDef.allowRawPath be set true from Lua side, if it can yet?
A few questions about "handle raw movement directly in the PFS" commit
Moderator: Moderators
Re: A few questions about "handle raw movement directly in the PFS" commit
That's exactly the purpose since two major games have now adopted raw move commands.
The engine controls pfDef.allowRawPath and sets it to true for short-range orders (meaning those that invoke the highest-resolution pathfinder) where straight-line movement has the largest impact on gameplay and deviations from the cost-optimal path are acceptable.
The engine controls pfDef.allowRawPath and sets it to true for short-range orders (meaning those that invoke the highest-resolution pathfinder) where straight-line movement has the largest impact on gameplay and deviations from the cost-optimal path are acceptable.
Re: A few questions about "handle raw movement directly in the PFS" commit
Alrighto, very cool!
I'll add this to BA to test around with right away.
I'll add this to BA to test around with right away.
Re: A few questions about "handle raw movement directly in the PFS" commit
NB: this branch hasn't been merged into develop yet (due to FF) so remember to grab the NativeRawMove build from https://springrts.com/dl/buildbot/default/.
Re: A few questions about "handle raw movement directly in the PFS" commit
Hey, when will this be added to the engine test version? :)
Re: A few questions about "handle raw movement directly in the PFS" commit
When you bribe the right people to break us out of feature-freeze prison before releasing 104.
BA test servers can also just host {NativeRawMove}103.0.1-1475-g46eaa69 (or later) which is available for download via the link above.
BA test servers can also just host {NativeRawMove}103.0.1-1475-g46eaa69 (or later) which is available for download via the link above.
Re: A few questions about "handle raw movement directly in the PFS" commit
You're talking as if you are not one of them :DKloot wrote:When you bribe the right people to break us out of feature-freeze prison before releasing 104.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: A few questions about "handle raw movement directly in the PFS" commit
Which commands use raw move? I've tried fight and attack and they both seem to be using the pathfinder still.
Edit: Just a config issue.
Edit: Just a config issue.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: A few questions about "handle raw movement directly in the PFS" commit
Raw move is looking quite good. I like how it is resilient by switching back and forth between raw mode depending on the path-ability as it updates. My main request is that the raw move distance be increased as currently units will move in straight lines for short distances but still take inefficiently bending paths for longer distances. Also, especially if longer distances get raw move, it would be good to ignore invisible enemy structures in the decision about whether to raw move as this could be used for cross-map scouting without actually sending any units across the map.
Re: A few questions about "handle raw movement directly in the PFS" commit
Support for longer raw paths also requires a (moderately intelligent) layer to examine speed-modifier variance or players will complain about units taking more time to reach their goals across hills/puddles/etc despite moving in straight lines.
I'm not convinced it would be advisable, but you can do tests with a79b1127 (change system.pathFinderRawDistMult) to find the sweetspot for ZK.
I'm not convinced it would be advisable, but you can do tests with a79b1127 (change system.pathFinderRawDistMult) to find the sweetspot for ZK.