dreadedentity

Hello! Do you play KOTH and been flown in by a badass pilot that flew in and landed after just a few seconds? Ever wanted to learn to do that yourself? I created this "mission" for that very purpose The trainer aims to emulate KOTH to provide a realistic training simulation for players to learn in. To that end here are the currently supported features: All KOTH battlefields supported Exact replica of the starting spawn building Spawn any helicopter to train with Random number of NPC AI is spawned that will get in your helicopter and jump out upon landing in the AO Repeat as many times as you like This project could be massively improved and I would absolutely be willing to work on it more if this is something people are interested in and actually use but I'm going to release it anyway because I've already gotten what I wanted out of it, which was learning how to do those epic youtube-worthy landings with hummingbirds. I'm definitely not the best pilot ever, but I can land successfully more often than I crash. I learned how to do it with the mission currently as it is, and if I can do it, you can too If I continue to work on this here are some of the features I will eventually add: F1 to lower/unlower volume just like actual KOTH Better/more accurate markers for each battlefield (right now it just comes from config and they are wildly off) Better/more accurate spawn zones for each battlefield (literally I just guessed for most of them, I don't play that much KOTH, could be crowdsourced pretty easily also) Adding Towers Dynamic landing zones (randomly chosen from inside the battlefield) Scoring system Ambient fighting between BLUFOR, OPFOR, and Independent (You might be targeted as well) Career statistics tracking (this is kind of a hard maybe) Anyway without further ado, here is the KOTH combat landing trainer (Github). To be honest, in it's current state this "mission" is best played in the editor so you can quickly restart. If it were to keep working on it then I would make it good enough to actually be playable as a scenario; but like I said, I already achieved my goal with this which was to learn how to do those combat landings, so I am simply providing this as-is

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