Spring RTS Engine

Set / Get MAX_TURNRATE is the easiest to explain, but probably the hardest to actually implement. Like Set / Get MAX_SPEED, this would change the fundamental turnRate of the Unit, with a value of 1 = 0 turnRate.

Why do I want this? So that I can (finally) lock up mobile Units entirely, via script. It will probably be a pain to implement, since it'll have to be reflected in the pathfinder code (just in case we want to get fancy, and set this to non-zero values, for Units that can turn more / less quickly under certain circumstances).

Stop-Script is a command that would require a change to the Compiler.cfg in Scriptor to use. Basically, it would return a FALSE to any script started via Start-Script, so that any script using the syntax:

MyScriptName()
{
While(TRUE)
{
Do something
}
}

Would be halted, until restarted. Currently, there's no way to do this- and you can only get around this by having a variable check that makes the script exit every few updates, at best. It's wasteful, and I think it'd be better to just be able to stop the script.

Lastly, WeaponLockout. Basically, Spring calls up weapons whenever a valid target gets into range (for that matter, whenever invalid targets get into range, it at least calls, but will not continue). There is no way to keep this from happening. We (scripting folks) have coded various lockouts, using fake weapons, but they don't work reliably, at least in my experience (if anybody has a script that provably works 100% reliably, I'm listening, but I've tested several approaches, and they all lead to unbreakable locks under certain conditions, unfortunately).

Basically, we could go with two different approaches:

1. Just set up a minimum-range FBI tag.
2. Code a SET / GET WeaponLockout value that simply prevents the slave weapon from ever trying to activate, if the master is active. Which would be more flexible, but I'm not entirely sure that it'd be 100% reliable, given how weapons get / release their active states (a weapon, once active, is always active, until a script releases it with Return(TRUE), so far as I can tell, and even then, it may not work right).

For example... we could write up a script like this:

AimWeapon1()
{
If(aiming)
{
SET WeaponLockout Weapon2 to 1;
}
}

FireWeapon1()
{
SET WeaponLockout Weapon2 to 0;
}

Which would prevent Weapon2 from ever trying to aim when Weapon1 was active, period.

I just want a minimum-range method that works 100% reliably, basically. I don't care how it works, really, so long as it does. That's been a MTR for quite awhile, so I'm hoping that somebody has the time to look into this.

What's the difference between your "Stop-Script" and killing a script with a signal?

The only one I could think of is that you also want a "Resume-Script", that would resume it where it ws halted, but I'm not sure, since you don't mention a resume-script command, and instead talk about "makes the script exit" . Still, has you said, you have the workaround of checking a static-var, which works very well.

with a value of 1 = 0 turnRate.

That turnrate request made sense and seemed the only valid request of these three requests, until that bit.

Why ask for WeaponLockout special command, when locking a weapon with a "while" in its aiming has proved to work very well? In TA sometimes the weapon would feel vexed and not reaim until a new order is manually given, but in Spring, it works, without any of those unreliability and ubreakable lock you speak of. And in which way those fake weapon you speak of enter the process?

None of this is MTR by the way, first time I hear those requests

a weapon, once active, is always active, until a script releases it with Return(TRUE)

WTF are you talking about???

I just want a minimum-range method that works 100% reliably

If you want a minimum range, that's an entirely different question. Because, when you want a minimum range, you do not want the weapon to stay "locked out", but you want the weapon to pick another target. Something that isn't exactly a minimum range but can give similar result, is to have the turret rather fairly up, and to use a cone of fire that is centered around Y+, in such a way that the gun isn't allowed to aim too far down. For instance:
WeaponMainDir1=0 1 0;
MaxAngleDif1=240;
The only annoying bit is that in Spring, weapons aims from QueryWeaponX piece, and not from the AimFromWeaponX, which is a very annoying bug that should be fixed.
But a minimum range tag could be nice, too.

For example... we could write up a script like this:

AimWeapon1()
{
If(aiming)
{
SET WeaponLockout Weapon2 to 1;
}
}

FireWeapon1()
{
SET WeaponLockout Weapon2 to 0;
}

Which would prevent Weapon2 from ever trying to aim when Weapon1 was active, period.

I don't see how you can equal "playing aiming animation" to "active", but otherwise, it's funny, I once wrote for TA a unit that had two weapons but could only unfold one at a time, and scripted it so weapon 3 would have higher priority than weapon 1, and so that it would never ever jam. For TA, the "never jam" was a nice challenge, since TA won't recall a new instance of AimPrimary if the previous instance hasn't returned with a TRUE. But for Spring, which constantly calls AimPrimary, there isn't even any challenge in that, just any plain lock script would work.

From what I gather between the lines, you want a unit with two weapons, a short range weapon and a long range weapon, and you don't want the long range weapon to fire when the short range is firing. If so, you're quite a noob:
- For not formulating your request clearly.
- For thinking it requires changes to the Spring engine.
- For thinking it requires brand new script command.
- For not realising your approach is fail since the long range weapon could very well pick up a far away target, while the short range weapon picks up another, close target. (Althought you meantion something about slaved weapons, which maybe could solve that issue, but most probably just create more and messier problems.)
- For being unable to script it yourself. Especially under the Spring engine, which is far more lenient than TA about jamming weapons.

Hm... minimum range...

A weapon above the unit with a cone that excludes the minimum range and the unit's main weapon slaved to it?

Either way for script stopping you can use signals to kill them from the outside or return to do it from the inside.

Your set WeaponLockout example violates the set syntax btw, you can't write two parameters in a row like that (though you could do a trick like with emit-sfx to encode both parameters into one).

I think I requested set TURNRATE before so +1 me on that and I also asked for a WEAPON_ACTIVE set var that could be used to tell the engine that a weapon is disabled and the unit should stop acting like it can use it (e.g. for range checks).

I'm not sure I can follow you on the lockout, can you give any examples of a weapon firing while the "minimum range weapon" has a target?