Spring RTS Engine

Posted: **06 Mar 2012, 09:50**

A long time ago, the kind CarRepairer gave CT a sprint button and it worked just dandy. In a subsequent engine update, that broke.

Yeah I saw the mantis report about how you can't boost unit's speeds anymore, and that to achieve the same effect you raise the speed in the unitdef, reduce it in the script and then have it return to "normal" for your sprint function...

But this isn't working for me. I can get the unit to boost to it's increased speed for like... a second, then it returns to the slower "normal" speed. Sprint function is supposed to last for 10 seconds. Did some tests and found that the sprint function lasts the full 10 seconds, its just the speed modifiers that don't last.

Here are the relevant parts of the script:

Code: Select all

	--variables
	local speedFactor = 1
	local normalFactor = 4

	--locals
	local myOrigSpeed = UnitDefs[unitDefID].speed
	local myOrigAcc = UnitDefs[unitDefID].maxAcc
	local myOrigTurnRate = UnitDefs[unitDefID].turnRate

	
	--Sprint code
	local function SprintEffects()
		Signal(SIG_SPRINT)
		SetSignalMask(SIG_SPRINT)
	end

	function StartSprint()
		Spring.MoveCtrl.SetGroundMoveTypeData(unitID, {
        		maxSpeed    = myOrigSpeed,
        		accRate     = myOrigAcc,
        		turnRate    = myOrigTurnRate,
        	})
		StartThread(SprintEffects)
	end

	function StopSprint()
		Spring.MoveCtrl.SetGroundMoveTypeData(unitID, {
			maxSpeed    = myOrigSpeed/normalFactor,
			accRate     = myOrigAcc/normalFactor,
			turnRate    = myOrigTurnRate/normalFactor,
    		})
    		Signal(SIG_SPRINT)
	end
	--End sprint code


	--local functions
	local function normal_speed()
		Spring.MoveCtrl.SetGroundMoveTypeData(unitID, {
        		maxSpeed    = myOrigSpeed/normalFactor,
        		accRate     = myOrigAcc/normalFactor,
        		turnRate    = myOrigTurnRate/normalFactor,
        	})	
	end


	--script
	function script.Create()
		StartThread(normal_speed)
	end

What incredibly crucial thing am I missing/doing wrong?

Posted: **06 Mar 2012, 15:37**

what unit is that? I thought missilemech but its script is different in svn.

Did some tests and found that the sprint function lasts the full 10 seconds

Did you test putting an echo before the line where you set speed to slow? See if it triggers too early or often.

StartThread(normal_speed)

why as thread?

Posted: **06 Mar 2012, 23:29**

Hmm yeah, it is the bmissilemech. What I posted here was my working copy, but I'll commit it so others can see it more easily. It doesn't spam errors or anything afterall...

knorke wrote:
Did some tests and found that the sprint function lasts the full 10 seconds
Did you test putting an echo before the line where you set speed to slow? See if it triggers too early or often.

Yep. Put an echo right before sprint started, and an echo right before the slow back to normal speed. The slow echo comes after the full 10 seconds. Just tested it to confirm.

knorke wrote:
StartThread(normal_speed)
why as thread?

Left over from when I was playing with signals... I put it back in Create() as I know I should

The odd thing is that I noticed the speed boost would last for different amounts of time depending on which crazy attempt I made to fix it... sometimes it would last a full second, maybe even a half second more. Other times it seemed to only last for a fraction of a second. Very odd.

Posted: **06 Mar 2012, 23:52**

I don't get it. You made the variable speedFactor but it isn't used anywhere as far as I can tell. That can't be right, right?

To me it seems to like the values from the unitdef you want to change for sprinting refer back to themselves.

(Of course I still consider myself a big noob, so i might be totally wrong.)

Posted: **07 Mar 2012, 04:26**

speedFactor is just a residual value... when it sprints it returns to it's unitdef speed. speedFactor doesn't need to be there, but there's no harm in it floating around until I get this ironed out.

The whole process is rather mucky, I wonder why the engine devs made it so you can't increase a unit's speed...

Posted: **07 Mar 2012, 11:54**

Why don't you just sleep(10000) instead of calling StopSprint from a gadget?

Posted: **07 Mar 2012, 23:02**

I tried that in various arrangements and got the same results. The closest I got was when I accidentally put the sleep in function StartSprint() instead of in a thread, and the speed boost was permanent. Also gave an error of course

I don't know what's going on here, maybe the gadget is malfunctioning. I looked through it and my lua-reading skill is not high enough to follow what is going on.

Do any other games use a Sprint button? Any kind of working example for me to compare against?

Posted: **09 Mar 2012, 09:19**

I've made a small bit of progress, but my solution I am afraid does not fix it.

I noticed that Spring.MoveCtrl.SetGroundMoveTypeData has the keys: requestedSpeed and requestedTurnRate

This prompted me to check if perhaps the unit is not simply slowing down back to its requested speed despite having a new higher max speed after sprint is activated.

Testing in game I found the following:
(/give 1 bmissilemech)
Issue far move order
Activate sprint
Unit slows down after a moment
Re-issue far move order before sprint finishes
Unit speeds back up to full sprint speed
Unit continues sprinting until sprint times out (even for multiple new move orders)

Hence, over confident in having cracked it, I changed the script (bmissilemech.lua) code to:

Code: Select all

	--Sprint code
	local function SprintEffects()
		Signal(SIG_SPRINT)
		SetSignalMask(SIG_SPRINT)
	end

	function StartSprint()
		Spring.Echo("Goooo!")
		Spring.MoveCtrl.SetGroundMoveTypeData(unitID, {
        		maxSpeed           = myOrigSpeed,
        		accRate            = myOrigAcc,
        		turnRate           = myOrigTurnRate,
				requestedSpeed     = myOrigSpeed,     --New Added Line
				requestedTurnRate  = myOrigTurnRate,  --New Added Line
        	})
		StartThread(SprintEffects)
	end

	function StopSprint()
		Spring.Echo("Whoooa nessy!")
		Spring.MoveCtrl.SetGroundMoveTypeData(unitID, {
			maxSpeed           = myOrigSpeed/normalFactor,
			accRate            = myOrigAcc/normalFactor,
			turnRate           = myOrigTurnRate/normalFactor,
			requestedSpeed     = myOrigSpeed/normalFactor,     --New Added Line
			requestedTurnRate  = myOrigTurnRate/normalFactor,  --New Added Line
    		})
    		Signal(SIG_SPRINT)
	end
	--End sprint code

Unfortunately, the unit still slows down after a moment. Re-issuing the move order while in sprint mode still has the exact same reaction as before.

Am I doing something wrong with the requestedSpeed and requestedTurnRate?
Or is my analysis of the problem just plain off track?

Edit: (Spelling fix).

Edit 2: Also, tried adding wantedSpeed into the mix (using it the same as requestedSpeed. No, change in unit reaction.

OT: Can someone explain to me what the difference between requestedSpeed and wantedSpeed is?
Should a unit not always aim to travel at the requestedSpeed? (Which might not be possible given certain limitations, but still that should be the aim, no?)

Edit3: Probably should have checked all of this so I didn't have to edit so many times.

In LuaSyncedMoveCtrl.cpp I found that the eventual end for changes to maxSpeed via the Spring.MoveCtrl.SetGroundMoveTypeData is:

Code: Select all

static inline bool SetGenericMoveTypeValue(AMoveType* mt, const string& key, float value)
{
	// can't set goal here, need a different function that calls mt->SetGoal
	// FIXME should use setter methods here and in other Set*MoveTypeValue functoins, but they mostly don't exist
	if (key == "maxSpeed") {
		mt->SetMaxSpeed(value / GAME_SPEED); return true;

I noted the comment about the goal not being able to be set. Does this effectively mean that the problem experienced here by Sanada is engine related? (I.e. only a new move command will cause the path and goals to be recalculated/re-issued)

If so, can I get some guidance in how to grab the current command (hopefully the move), insert a copy of it into the command queue, and then delete the current command (so that effectively the command was exactly reissued).

(On another note, will this even work?
On another another note is my original assumption correct at all?)

From the wiki I am looking at:

Code: Select all

  local cmdQueue = Spring.GetUnitCommands(unitID);
  if (#cmdQueue>0) then 
     local cmdTag = cmdQueue[1].tag
     ..
  end

and

Code: Select all

Spring.GiveOrderToUnit(unitID,
     CMD.INSERT,
     {-1,CMD.ATTACK,CMD.OPT_SHIFT,unitID2},
     {"alt"}
   );

and

Code: Select all

CMD.REMOVE

 options.ALT     -> use the parameters as commandIDs 
 options.CONTROL -> use the build queue for factories 
 params[0 ... N-1] = tags or commandIDs to remove

Okay, I'll stop now until someone with actual Spring coding experience replies...

Posted: **15 Mar 2012, 00:08**

It seems in 0.87 the whole concept of changing a unit's speed breaks altogether because you can't do it in Create()... So I guess this is pointless until the engine gets an update.

Posted: **15 Mar 2012, 00:23**

you mean http://springrts.com/mantis/view.php?id=3016 ?
i cant believe that was on purpose (doesnt make sense really) so eventually it will work again.
maybe see if it works on gadget:unitcreated

Posted: **15 Mar 2012, 04:02**

Yeah I was creepin' on your conversation in #moddev

I agree, no idea why they would change this. Sure there is *some* reason...

Like make a basic sprint gadget? I honestly like that approach more than having it half gadget and half LUS

Spring RTS Engine

MoveCtrl Help

MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help

Re: MoveCtrl Help