Scripting commands you want in a future patch

[ffur2007slx2_5]

I want a command which can move an object from one 3d position to another smoothly regardless simulation.

i.e. Move a land vehicle to the air and then move it to another position in the air so that I can create a kinda of enviroment loss gravity! lol.

What's more, I also wanna a command which can return the bullet drop position directly so that I can write the dust effect more easily when a bullet hit on someplace.

[Big Dawg KS]

I'd like SQF scripts to be able to use the goto command. If they did, it would be the ultimate scripting format. Getting to return or skip to any part of a script would save tons of effort by not having to write a single huge wall of code that has to take every possible situation into account multiple times.

But the whole purpose of SQF is to be more structured and get rid of harmful gotos...

[NouberNou]

I still would like to have setHeight which basicly should be a shortcut for "this setPos [(getpos this select 0), (getpos this select 1), height_variable]";

I don't know how often I wrote that line, but I guess it was several thousand times in the past 10 years.

slightly easier way...

_pos = getPos _obj;
_obj set[2, _heightVar];
_obj setPos _pos;

[Celery]

But the whole purpose of SQF is to be more structured and get rid of harmful gotos...

I don't consider it harmful. It's one of the two big reasons I prefer SQS to SQF because I'm able to write scripts that would be a nightmare to organize without the goto command, such as a zombie behavior script. And those who don't like it wouldn't have to use it in any case.

[Big Dawg KS]

I don't consider it harmful. It's one of the two big reasons I prefer SQS to SQF because I'm able to write scripts that would be a nightmare to organize without the goto command, such as a zombie behavior script. And those who don't like it wouldn't have to use it in any case.

Why not use FSM then? They are actually pretty much the same thing as using lots of gotos, only better. Sounds like that's what you need. Also since SQF can return values, gotos wouldn't really work so well, so I say keep them out of SQF.

[NouberNou]

If you feel you need gotos in SQF you are doing it wrong. Its that simple.

[Celery]

Point taken, I fail at scripting.

[AnimalMother92]

Made a ticket for this awhile back, would be nice to have.

Similar to defining a unit's eye-wear through the description.ext but without the need for CfgIdentities.

This would be like the current setFace command except that it would make a unit wear a certain type of glasses.

example:

Unit1 setGlasses "BlackSun";

This would avoid the need to go through setting an entirely unique identity, for something so simple. Also, it would allow mission makers to override the cases where units are given random glasses that may not fit the scenario (eg soldier with aviator sunglasses during a night mission). Essentially an extension of the setFace ability.

http://dev-heaven.net/issues/13245

[NouberNou]

Point taken, I fail at scripting.

I didn't mean it like that, its just that syntax wise with SQF you do not need the goto command. If you come to a point where you go "I need the goto command" then you are not coding SQF the right way.

[Evil_Echo]

Request for ability to get non-classed objects...

nearestObjects with an empty array does that
However that would include all objects, and not the non-classed ones specifically, perhaps that's what you meant.

You got it. While possible now, it takes two nearestObjects calls ( [] to get everything, ["All"] to get the classed objects ), and then a subtraction operation to find the difference. Very expensive in terms of CPU and memory allocatied. I'm just asking for a more efficient direct method to accomplish this task and lighten the burden on the players. Or assign items like fences and trees to a real class and get rid of non-classed items altogether....

Request to explictly kill a FSM.

While I agree, you may quite easily design your fsm quitable. Just have some variable in your fsm, say _quitFSM, and incorporate a simple check in the "main-loop" of the fsm. Once _quitFSM is true, the fsm quits.
Now you can simply setFSMVariable _quitFSM to true from anywhere and the fsm will quit the next loop. Sure, maybe you want to

waitUntil{(completedFSM _fsm)};

or something prior to starting a new fsm or whatever...

Works pretty nice, aslong as you do it the same way for all your fsm. Also this way you may incorporate something like a clean-up routine in your fsm before it really quits. I doubt you could do something like this, if you'd simply kill the fsm. But ok...

killFSM handle

Again true, you can code them to catch a signal. But that adds a lot of overhead to your design if you wish to be able to trap that event everywhere and does nothing for FSMs you did not code up or have gone rogue on you. IMO you need a way to kill the FSM with certainty, something like your idea of killFSM handle.