dreadedentity

Remember that getVariable has an alternate syntax that allows you to specify a default value if it is not found _rating = player getVariable ["rankRating", 0]; In my experience, assuming the variable exists often quickly leads to a script error, the alt syntax ensures that you will always get a value and hopefully avoid any script errors. It will remove the need to check with isNil

Yes, very easily. In your function you can just use spawned code and using _this you can transfer all arguments from the original call to the spawned code myFunction = { //bunch of code _this spawn { //new code that needs scheduled enviornment } } I don't know the specifics, but an alternative thing you can do is simply spawn the code rather than call myArgs spawn myFunction; In SQF the "code" type you can think of it as just a container for the code, and using spawn or call determines the scheduling behavior of the executed code

It looks like a Hold Action, though I'm not sure how they were able to use a custom key, perhaps it is a custom hold action? The code can be viewed from the function viewer

Is something not working?

At the end of the day this is just a loop: while {true} do { switch (random x) do { //get random task }; waitUntil { task complete || timeout}; call cleanupTask; };

just wait for it to mature a little lol

You need to create "WeaponHolder" then add backpack to it

allGroups select { side _x == west }

Yes this is mostly accurate, though it is not a result of long mission time, but rather a side effect. Long missions are likely to accumulate an ever-increasing number of scripts for one reason or another and due to the way the scheduler works this causes the effect above. Specifically, all spawned code is only given a 3ms window to run each frame, any further processing is halted until the next frame. On the next frame, whichever script has not executed in the longest time is resumed, thus the creation of the aforementioned infinite upper bound. See scheduler for (probably) a better explanation In this case I traded some code size for performance reasons. I wanted there to be as little processing as I could manage, and have it not affect the accuracy of the timer. Unfortunately, I did not fully grasp how the scheduler worked back then so the timer is probably even less accurate than I thought it was due to the behavior described by @ZaellixA above. Notice that the scheduler page did not exist when I made this post. Anyway, here is the reasoning for some of the choices I made: spawn and waituntil - I wanted to make sure that processing time would not affect the accuracy of the timer so eventually I came up with this. Notice that the effect is the calculation and formatting is done before the next cycle, so once the next cycle starts the only processing that needs done is display/saving variable. Otherwise the script would wait for 1 second, then do processing/formatting, then display. It's not much, but it would make the timer permanently inaccurate by a few milliseconds while those calculations are being performed custom formatting - An effort to keep the processing as lightweight as possible. It may seem inefficient at first but it is just 1 comparison then adding 1 character. I would expect this to be many times faster than the BIS function. Essentially I am taking just the functionality that I needed and throwing away everything else, I hoped the result is that less code runs overall and so would be faster

In CfgVehicles I found extCameraPosition that seems promising, although I didn't spend enough time playing with it to figure out how it works

Try asking them really nicely

Can you explain a little more what you mean with this? Both conditions in your waitUntil should return true and so should move on immediately VectorUp changes with the terrain, so you'll probably really only find this in the VR map and you check if vehicle is alive right above

Use switchCamera, it will force the players camera into the supplied mode; can do external, internal, and other modes

Cool concept, this seems like an excellent way to bring in large datasets without adding them directly to scripts. I'll have to play around with this and figure out some good ways to use it Sidenote: It's really not clear in the post that you are trying to bring forward an interesting command and generate discussion on it. In the past, I have made several tutorial-like posts, you may wish to follow my format or expand upon it and you might have more luck

Due to this the following would also work (vehicle player) != player And was the only way to do this for a very long time. But nowadays, the "objectParent" method is better because it runs faster