A few questions about "handle raw movement directly in the PFS" commit

A few questions about "handle raw movement directly in the PFS" commit

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
tzaeru
Posts: 283
Joined: 28 Oct 2007, 02:23

A few questions about "handle raw movement directly in the PFS" commit

Post by tzaeru »

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?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by Kloot »

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.
tzaeru
Posts: 283
Joined: 28 Oct 2007, 02:23

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by tzaeru »

Alrighto, very cool!

I'll add this to BA to test around with right away.
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by Kloot »

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/.
User avatar
triton
Lobby Moderator
Posts: 330
Joined: 18 Nov 2009, 14:27

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by triton »

Hey, when will this be added to the engine test version? :)
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by Kloot »

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.
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by hokomoko »

Kloot wrote:When you bribe the right people to break us out of feature-freeze prison before releasing 104.
You're talking as if you are not one of them :D
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by Google_Frog »

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.
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by Google_Frog »

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.
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: A few questions about "handle raw movement directly in the PFS" commit

Post by Kloot »

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.
Post Reply

Return to “Engine”