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

Hello! I was watching videos of milsim clans playing the game, people were out of ammo, they were being overwhelmed by enemies. In the heat of battle, a guy dropped a magazine on the ground and his teammate had to look down at the ground to pick it up. This isn't realistic! (well in a real battle you probably wouldn't throw mags) "Never again", I said and I got to work. 2 or 3 hours later, here's what I made. 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; };

Hello, I'm DreadedEntity pushing out another code snippet for everyone. This time it's a super-simple countdown timer. This script will count down from the amount of seconds you give it, and it will also display it in an optional debug parameter. Actually, all of the parameters are optional. So here's the script: DE_countdown.sqf: /* Usage: [60, "myOutput", true] spawn DE_countDown; (if using execVM: [60, "myOutput", true] execVM DE_countDown;) Parameters: P1: NUMBER - The number of seconds from which to count down from. (Default: 300, 5 minutes) P2: STRING - The string name for the global variable which you want to output. (Default: "DE_countdown") P3: BOOLEAN - Debug. True to display a hint with the current time, false to not. (Default: true) Returns: Script Handle, allows you to check if the countdown has finished -Second parameter also allows the content creator to use the timer in any way he/she desires (ie. within a dialog). Format of the output is [hours, minutes, seconds] and can be accessed using: _countdown = missionNamespace getVariable "DE_countdown"; */ DE_timer = { _seconds = [_this, 0, 300, [0]] call BIS_fnc_param;; _secondsTemp = 0; _minutes = 0; _hours = 0; _globalVar = [_this, 1, "DE_countdown", [""]] call BIS_fnc_param; _hint = [_this, 2, true, [false]] call BIS_fnc_param; while {_seconds > 0} do { _timer = [] spawn {uiSleep 1;}; _seconds = _seconds - 1; _hours = floor (_seconds / 3600); _minutes = floor((_seconds - (_hours * 3600)) / 60); _secondsTemp = floor (_seconds - (_hours * 3600) - (_minutes * 60)); if (_hours < 10) then { _hours = "0" + (str _hours); }; if (_minutes < 10) then { _minutes = "0" + (str _minutes); }; if (_secondsTemp < 10) then { _secondsTemp = "0" + (str _secondsTemp); }; waitUntil {scriptDone _timer}; missionNamespace setVariable [_globalVar, [_hours, _minutes, _secondsTemp]]; if (_hint) then { hint format ["%1:%2:%3", _hours, _minutes, _secondsTemp]; }; }; }; Enjoy!

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

I'd need a better description of this before I can say more; but: No. Units must have a group, and a group always has a side

I did some digging in the config and I found that the pause menu is display ID 49 and it's name in the config is "RscDisplayInterrupt". The following works in debug console: ((findDisplay 49) displayCtrl 2) ctrlEnable false; //Disable "CONTINUE" button But when I tried putting more code around it to make it automatic, it stopped working. It seems SQF gets paused as well when the Interrupt menu opens

displayAddEventHandler returns the id number or -1 if it fails, store that into a variable then use displayRemoveEventHandler to delete it: (findDisplay 46) displayRemoveEventHandler ["KeyDown", _id];

Nice thought, perhaps they are a proxy unit used to give the HC squads players orders. Could explain weird behavior with Guard waypoint (enemies are known on a group-level, implying the unit at 0,0 was joined or possibly led the HC squad for a short time). Unfortunately it's difficult to find answers to questions like this

Like I said I don't actually know if these really are the centers that I mentioned, so I'd recommend some general testing to find out stuff about them, but if they were then your trigger code could possibly be as simple as: { private _current = _x; thisList apply {_current forgetTarget _x}; } forEach thisList; What's nice about this is it leaves the centers alone (maybe not even an issue), and since they are hidden afterward they shouldn't be able to re-spot so if done at the right time you could probably get away with just running this once

Got nothing for the group event handler situation but perhaps CfgSentences can simplify (or way overcomplicate) the radio calls

In past games sometimes you would have to create a "center" for a particular side in specific instances before you can create units because the center is what allows groups on that side to be made. In Arma 3 all 3 centers are created automatically so this is no longer necessary. However this seems like they are the center units, and able to see 1 or more and target it before it can be hidden. I don't know if what you are seeing is the center units but now that you know a little about them you can see that it is a bad idea to delete them. Since you are able to find the center unit, perhaps forgetTarget will work?