Repairing Wheel Script - Need help

[Ranwer135 308]

THREAD HAS BEEN SOLVED:


You can find the release link here:

 

https://forums.bistudio.com/topic/183681-repair-wheel-and-engine-script-release/

 

 

Kind Regards,

 

 

 

Rawner135

[Schatten 290]

Vehicle's init:

this addAction ["Repair", {[_this select 0] call dss_fnc_repair_wheel;}];

Also, if I'm not mistaken, script suspension (using sleep, etc.) is not allowed.

[Ranwer135 308]

Vehicle's init:

this addAction ["Repair", {[_this select 0] call dss_fnc_repair_wheel;}];

Also, if I'm not mistaken, script suspension (using sleep, etc.) is not allowed.

 

Thanks for spotting the problem, works perfectly!  ;)

 

However, what do you mean by "script suspension is not allowed"?  :blink: (I thought sleep and waitUntil were great for delaying something such as a condition or action?)

[Schatten 290]

what do you mean by "script suspension is not allowed"?

... in this context.

Check RPT-file. If there are no errors, then I was wrong.

[R3vo 2654]

  Executes the function string. The argument(s) (if any) are passed as _this. (argument(s) are passed in an array). To execute a sleep function in the called code, execute it with spawn instead.

 

 

 

Source

[Greenfist 1863]

Script suspension means waiting (sleep or waituntil). You generally don't use them with 'call', but with spawn/execvm instead.

 

https://community.bistudio.com/wiki/call

 

And enable showscripterrors, so you don't have to look at RPTs that often.

[mobilemick 13]

Can you post the working code :) :) :)

 

Soldier goes through the motions of reparing wheel on hunter, but nothing gets repaired

[dreadedentity 278]

You generally don't use them with 'call', but with spawn/execvm instead.

 

It goes a little deeper than that. It's not that you don't use suspension, it's that you can't use suspension. In Arma, we have scheduled environments and non-scheduled environments. In a scheduled environment, commands are put into a queue and run when it's their turn. This is what causes something called "script lag"; when a mission designer has too many active scripts running, they must all wait for their turn to execute, which can cause scripts to take much longer to run.

 

However, in a non-scheduled environment, all of the code is executed on the spot. Everything else is stopped until all non-scheduled code is run (that includes rendering and playing sounds). If you had a sleep in that code, the game would freeze until it ended. At some point during development, a BIS dev thought that would probably not be a good idea and added some code to stop suspension commands from being run and throw an error.

 

Some common non-scheduled environments include:

• The debug box (accessed by pressing esc)
• Initialization fields of objects placed in the editor
• Event handler code (includes mission event handlers, object event handlers, and GUI event handlers)
• The code in an addAction command
• Function calls

It's a good idea to keep in mind whether your code is in a scheduled or non-scheduled environment when it will be run, you can eliminate some errors before they even happen.

 

Any non-scheduled environment can be turned into a scheduled environment through use of the spawn command.

[Ranwer135 308]

Thanks for the great info guys.

I did a little searching and found some good resources and pages like in the community page, "optimizing code".

@thesh1tgamer

Will post a public release today, so no need to rely on the already made code there. :P

 

 

EDIT-----

 

 

Script released!

 

 

Link: https://forums.bistudio.com/topic/183681-repair-wheel-and-engine-script-release/