Jochem

Thanks @Minipily for the great evening

@Ryko didn't have the time to go check in-game, but something like this might work:

Look what I did just for the hell of it: Code in file (tested ONLY in SP, it's entirely possible it doesn't work in MP) helmetCam.sqf

As for getting penetrated on the front of the turret, I saw that rocket fly towards us and I can assure you it wasn't the tandem PG-7VR but the normal PG-7VL, and that one has around 500mm pen, so shouldn't have penetrated. But like you said, ArmA ain't real life. I felt kinda sad when I read this, as Mini is actually a very competent commander. This video (hopefully) proves that: But then again, we it has been a while since we (or anyone) played Hammer during regular play, so I understand where you're coming from. I'll say this about that gamenight: mistakes were made, I won't argue by who since I wasn't listening in on LR. Just don't base your whole opinion of Hammer on that one night. In my experience, Hammer is THE role that truly requires teamwork to do succesfully. The reputation it gets of being a lone wolf killing machine is mostly due to the inexperience most PltCo/Asl have when dealing with an armoured element. Many times command just tells us to go to the opposite side of the AO, instead of supporting infantry. The times we did do infantry support though were actually very rewarding for both us and the infantry, with good teamwork on both sides.

If you see a team doing something they shouldn't and you're in command, tell them. If they don't comply tell them more direct. After you've done this and they still don't comply (almost never happens in my experience) get an admin. Except in my opinion they didn't. Apart from that you obviously can't force people to pick a slot, this rule was (originally) never intended to apply to slotting: you could fill any role the rules allowed you to, no permission from acting command needed. This seems to have changed recently, but when I command I hold the principle that the only thing I do when a slot is filled I don't want/need, I just mention it to the player(s) occupying the slot(s), but never force them out of it. I adjust and make it work. I don't agree with 3, I guess it depends on the players. Point 4 is valid, but a 5 man FSG team already isn't allowed without a full alpha, so if people follow the rules that shouldn't happen. As for your solution, I don't agree. A CAS bird is even more prone to misconduct than FSG is, speaking from experience. As for the "lol point and click no skill izi pizi tank dead", for an FSG team equipped with a SMAW or even a MAAWS to take down a target requires teamwork: someone gets the range, another makes sure that after the gunner fires a new round is supplied to the gunner. In conclusion: just because some team isn't as effective as another doesn't mean that team needs to get killed off. If that was the case, we would all be flying jets, Apaches or driving tanks and IFVs.

I agree with that it would've been better to ditch command and fill BSL instead. I found that the whole operation felt somewhat weird to me. I found myself asking for SITREPs wich were basically useless other than giving me a better idea of what was happening (useless because most of that information wasn't used after I got it), those took time wich Amentes could've used for managing his teams. I could've managed the fireteams more directly, but then ASL turns into a glorified retransmitter. Plus command really shouldn't be micromanaging. Add to that I had no comms with Vortex untill he got close because the main base was located so far from the AO, and it resulted in me just wandering around, marking an LZ now and than, and shooting a few guys because I had nothing better to do at the time (I got 8 kills, IMO a count a bit too high for someone supposed to hang back and manage things). I don't blame Amentes for not keeping me in the loop all the time (after all, he had no reason to other than protocol) or Karate. It was just the relativly low playercount that forced us to improvise on slotting and it wasn't perfect (for me). But if it worked for the rest of the players then I don't mind, I can't expect anyone to organise things to maximise only my enjoyment. One last thing that might better belong in the new thread but I'll say it here because it stays close to the above: next op we'll have more or less the same situation because, since I assume the two recon teams will be more or less autonomous, command will be left to only manage Alpha and maybe Vortex for reinsertion. And while I love playing as command, I'm not sure I wan't to repeat last week for the reasons stated above.

Items dropped by dead units are still connected to said unit, so if you delete the unit it's weapon get's deleted. It even works when a player swapped it's own weapon with that of the unit. For players dropping items you could use this EH: https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#InventoryClosed It's true you'll always need to combine it with a script that runs periodically, thing is that script doesn't impact performance as much as it otherwise would. I personally use the first solution I suggested in my missions, runs every minute, never had any performance problems with it (and it even checks for nearby players).

That's not what exception handling is, I assume you meant a regular if that checks for nearby players. If you use scheduled execution yes, but not if you use unsheduled execution. Unscheduled execution executes code roughly 7x faster and doesn't care about the 3ms limit. The catch is you can't use infinite loops (since the code runs until it is done), sleep, uiSleep and waitUntil. You still shouldn't run a lot of expensive commands, but for what you'd need to do here, it wouldn't give any problems. Event handlers are AFAIK very performant, but I've got no data to back it up. I tried testing it but I ran into this problem: since a few eventhandlers on units didn't change performance you'd need to place a large amount of AI, but at that point it's the AI ruining the performance, not the eventhandlers. How I see it there's a few ways to optimize the script: Remove the loop from the script, compile preprocessFileLineNumbers the script, put it in a CBA_fnc_addPerFrameHandler (CBA would need to run on the server, but not the client). Go the eventhandler way and either do a []spawn{} or even better, use CBA_fnc_waitAndExecute. Keep the code, compile preprocessFileLineNumbers the script and spawn it instead of execVM. preprocessFileLineNumbers buffers the script in memory and compile prepares it for execution beforehand instead of having it redone every iteration of the loop.

I used to have the same opinion and avoid placing units in the editor, but with the introduction of the dynamic simulation system(https://community.bistudio.com/wiki/Arma_3_Dynamic_Simulation) it can actually be beneficial to place all units in the editor (or spawn them with a script in the beginning of the mission). When the mission doesn't require an insane amount of units (+1000 units) there's no real reason to use dynamic spawning anymore for a simple mission, especially if you combine it with a headless client. So if you're unfamiliar with scripting I'd just place everything in the editor, and enable dynamic simulation.

I knocked myself out, the code is a bit more complex, but I kept all the code in one file: The main thing about this is that it works in both SP/MP (altough for pure MP use some slight adjustments should be made for performance), is JIP compatible and doesn't contain any scheduled code (spawn, execVM). If you want to test it paste the code in a file (i.e. sniper.sqf) in the mission folder and execute these two lines:

Nah, I broke it apperently, fixed the code in the post above. 245 = ((_radius/2) - 5) It get's the uppder right corner of the square. I was a bit lazy and harcoded it in, but you can replace it with ((_radius/2) - 5). For your script, make it like this: []spawn{ _z=500; [player, (player call removebackpackback)] call setbackpackonchest; player addbackpack "B_Parachute"; player setpos [getpos player select 0,getpos player select 1,_z]; sleep 5; waitUntil {getposatl player select 2 < 1}; player call removebackpackback; [player, (player call removebackpackchest)] call setbackpackonback; } https://community.bistudio.com/wiki/sleep You dicovered scheduled and unscheduled execution, welcome to the complications of ArmA scripting.

Tried indexing the map, like I expected didn't work nearly as fast as the other solutions (for a 1000m radius). Also did some optimizing of my first code, runs around 38% faster (29ms vs 41ms)

For the terrain objects like trees and rocks: https://community.bistudio.com/wiki/nearestTerrainObjects Amazing work with the new version, I'm impressed you managed to cut off half the execution time. When I'm home I might try one of your suggestions about indexing the map at the start of the mission. I'm not very optimistic about it but we'll see, 20ms is a hard time to beat.

Let me just say: great job so far! Since I personally think programmers should encourage and help each other, especially if someone's starting out, here's some tips: Avoid spawning objects when not it's not needed. It is one of the most expensive (read performance hitting) things a script can do. Always uses local variables instead of global ones when you can (_variable is local, variable is global). It's more secure and will prevent weird things from happening. Don't interpret these tips as something you should be ashamed of, I'm really quite impressed you managed to write something like this seeing you just started out. If it can help you, this code finds the heighest point in the given radius with 10m accuracy (altough it actually searches a square of that size not a circle) and is around 83x faster (42ms vs 3500ms execution time) when executed with a radius to search of 1000m: Don't let that discourage you though. Nobody learns programming on a day and optimization will come naturally over time. I'm interested to see what you'll do next, keep up the good work!