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
