X Pro Octane

I think that the intended implementation of @Arkensor's method (first part) is to be a script inside the mission folder rather than directly into the vehicles init field, so for that kind of situation, you wouldn't use the this keyword to add the handler - you'd refer to the vehicle object itself, which is what _vehicle = _this is doing - assigning the object that called the script to run into a variable. @mrcurry 's method however is intended for the init field, but you're getting that error. I'm assuming it has something to do with the params command being used, but I don't know. You can just use @Arkensor 's example (second part), and instead of using _vehicle, use this. And as he also does, just use the passed arguments (vehicle, engineState) using _this select 0, and _this select 1. I can't format code because of my current OS and browser, but here's the line you'd put into the init field. this addEventHandler ["Engine", {if(!(_this select 1)) then {{moveOut _x;}foreach (crew (_this select 0));};}];

Then wouldn't something like _distanceCheck = _shooter inArea "NOFIREZONE"; work?

Dynamix I'll try to keep this thread as short as I find suitable and on point. No promises... I'll start with giving ya'll little background on the system. I've been developing this script for a good many weeks now, and have come up with what I'm calling the Dynamix System. The system is a set of only a few scripts that act quite similar to EOS, but are structured much differently to allow the beloved functionality to be presented in a very up-to-date and optimized manner. This is actually my first script I'm releasing to the public, so please expect bugs that need squished. Prior to me creating the script, I barely had any SQF know-how. The only knowledge that I had was of JavaScript, which seemed to be the most relatable language. I went ahead and found up the BI Wiki, and spent a good bit of my time to create this puppy. The system has went through some of my very "newbie" stages of development, such as where I had first implemented a matrix system to handle marker and unit status, but I found that to be obsolete after I matured it into simply getting the status from the map, and not throwing around the amount of enemies for each marker from the client and server. Performance Demo As I continued to roam around in the demo video, you could clearly tell that the system was performing at a pretty swell level. Apologies that the FPS wasn't overlayed for you to watch, but I can admit it was a constant 50+ frames - despite all of those active enemy AI and the DS being ran on the same machine. Now, please take in mind that my system is not built for something as bada## as Arma 3. Or, at least I would say it isn't. OS : Windows 7 Ultimate 64-Bit Motherboard : MSI 970A-G43 AM3 ATX GPU : AMD R9 270 925MHz 2GB GDDR5 (Crimson ReLive Software Version 16.12.1) CPU : AMD FX-6300 (Six-Core) 3.5GHz (Overclocking to 4.19GHz (Yes, the damn thing is stable)) Memory : Kingston HyperX Fury 240-pin (2x4)GB DDR3 (Overclocking to 1866 w/ HyperTransport) Storage : (OS Internal) Seagate HDD 1TB 64MB Cache, (Secondary Internal (Arma 3 Installed Here)) Samsumg EVO 850 250GB Last thing to note and wrap up this section is that over the time that I've been developing this, I made only one hardware upgrade, and that is the SSD (my very first). I can assure you that while I was still developing this system in the early days of my little HDD, it performed only slightly worse than it does today. I find this difference to be insignificant, because the margin of performance from system-to-system varies regardless, so it wouldn't much matter under certain conditions. Features Smooth AI spawning Marker status changes are logged Many editable variables Markers don't unload units Enemies occupy buildings Vehicle spawning Editable unit spawn banks An up-to-date system Open to suggestions Fully explained system Works with SP and MP Only 4kb's How-It-Works It actually works in a fairly simple to understand route. I'll just list out the main steps below. The server either sequentially generates all the marker names to report, or it reads them from a manual bank. It applies to all of the valid ones a certain "initial" color, and logs the invalid ones for debugging. Every X seconds, players will report their object, appropriate marker status colors to be applied, and load distance to the server. The server compares these values to every marker, and activates, captures, or recaptures those whom meet certain conditions. Considering an initialized marker needs to be loaded, it runs another thread that spawns the enemies. From the numbers 2 to 5, are generated units from a set enemy bank. The server takes a break after every unit spawned to reduce stuttering. For every building within a marker, is a chance to occupy a building with a single unit. A break is taken inside this as well. Finally, if there is a road inside a marker, there will be a chance that an enemy vehicle will spawn on that road. A break is taken inside this as well. Let's consider only 2/3 units have been neutralized inside our marker, so we'll look at this comparison. The capture comparison is based off of player knowledge to whether the square is clear or not. Even if an enemy is still inside a square, but the player doesn't know about them, it turns blue. This prevents players from cheating by observing a squares status to see if enemies still occupy it. That wraps the system up... Downloads There is a readme.txt inside the folder that you can take a look at. I've got a heap of comments inside the main script for you to take a look at how to configure the script. This is a personal agreement, where I state that you ONLY redistribute this system under the conditions that you apply proper attribution to all contributing authors, and a link to this OP. MediaFire - V11.8 Took me two whole hours to write this damn thread where I could have been playing Arma all that time, so I hope I covered everything. Enjoy! If you find bugs, I suppose you know what to do.

Well, considering that, I'd fully agree to including this feature in Arma. I'll personally in fact look around into if this could possibly be a scripted feature mission makers can include, until BI decides to give it some attention.

When reproducing the situation on Altis, I placed a Bungalow building object at said coordinates of 22081.963, 10731.634, 1600, and I place a unit nearby on land. While still in the editor, when I place the player on the position of the Bungalow by manually setting it's location parameters, it seamlessly is moved to the exact position inside the Bungalow. Although, when starting the scenario and using the in-game debug console to teleport the player to the coordinates, the player is spawned an additional 1600 meters over the object at z=3200. Concluding this, it seems that all object positions are measure by ATL in the editor. Correct me if I'm wrong on this, but again in-game, the player position is then measured in AGLS. This is why the setPos isn't broken.AGLS will measure z over x and y. So when we have this bungalow on x and y, we are telling it to teleport the player 1600 above said object. In-game, the Bungalows position is measured in ATL, so to solve this would be to either use the command setPosATL on the player, or you can simply keep the z position in setPos at 0.

Though I wouldn't call the current markers completely useless without a time stamp, I would certainly find this to be a handy little feature. Although, I have to ask. Aside from players who wouldn't dare add it themselves, for those whom would, the current game time is in the top right of the map as shown in your screenshot, so why not just manually add the time stamp?