Page 1 of 1
Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 02:19
by Alchemist
I have a mobile unit, which is initially set to OFF.
I can move this unit wherever I want while it is OFF.
Ideally, when it is turned ON it does an animation and
should stop.
Then, when it is turned OFF, again, it is free to move.
The problem is, when I hit ON, it continues to move freely as if it were turned OFF.
My code:
Code: Select all
Activate()
{
some cool animation here;
set MAX_SPEED to [0];
start-script RequestState(0);
}
Any ideas?
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 02:27
by Peet
Setting MAX_SPEED to 0 doesn't work. Set it to 1 (not [1]!), which is tiny enough to be 0 for all practical purposes.
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 03:54
by Argh
Yes. Set to 1. I really don't think it's moving at all at that point, at least I've never seen it move.
You cannot do this with turning, however, and you will find your newly-immobilized unit still turns, as if it is moving.
Instead, you must run a loop where to you keep turning the unit every frame to the desired heading, while a condition lasts. Which is rather expensive to run, CPU-wise, so you definitely don't want to plaster this kind of code willy-nilly on things that don't actually need it.
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 04:52
by lurker
"must", Argh? The unit now uses a call to Spring.MoveCtrl.Enable() to shut off all movement, turning, and pathing.
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 05:12
by Argh
Meh, truthfully, I haven't played with that.
When reset, does the Unit return to its previous behavior? If so, it'd probably be far cheaper to run that and then supply no MoveControl stuff. Lemme go look at that, I did all of this before messing with BOS-->Lua...
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 05:36
by Argh
Okie doke, just tested it... it's easy, and it works. Only problem that I see is that you lose the previous move commands, so you cannot do it for a unit in the middle of a Patrol and expect it to resume, etc., without storing it somewhere. Better by far than running COB all the time, though.
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 06:05
by aegis
You could call a function in lua to store the current move queue then apply the movectrl. On removing the movectrl, simply reapply the queue (and update it with any new orders if desired).
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 11:39
by KDR_11k
I use morphing but whatever floats your boat...
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 20:40
by Alchemist
How would you do the store and reapply of queue?
Re: Mobile --> Immobile --> Mobile
Posted: 09 Jun 2008, 20:50
by Pxtl
Alchemist wrote:How would you do the store and reapply of queue?
See Kernel Panic - the Virus/Exploit units are such an example of a unit that morphs into an immobile... I'm pretty sure it has queue persistance.
Re: Mobile --> Immobile --> Mobile
Posted: 10 Jun 2008, 07:19
by yuritch
Some things about immobilizing via MoveCtrl that I'm not sure about:
Wouldn't Spring.MoveCtrl.Enable() also prevent things like unit being thrown off by high-impulse explosions? And what happens if a crater is made under such unit, won't it stay 'afloat' midair?
Re: Mobile --> Immobile --> Mobile
Posted: 10 Jun 2008, 09:29
by lurker
Being immune to impulse is good with this unit pretending to be a building, and ground deformation is an issue, but you have to consider the survivability of such a blast.
Re: Mobile --> Immobile --> Mobile
Posted: 10 Jun 2008, 12:00
by trepan
Are you sure that ground deformation
would be an issue when using MoveCtrl?
