Jump to content

Jochem

Community Member
  • Content count

    54
  • Joined

  • Last visited

About Jochem

Contact Methods

  • Steam Name
    Jochem

Profile Information

  • Gender
    Male
  • Location
    Belgium

ArmA 3

  • ArmA 3 Player Name
    jochem

Recent Profile Visitors

1,701 profile views
  1. 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.
  2. How does the dead/destroyed despawn script work?

    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).
  3. How does the dead/destroyed despawn script work?

    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.
  4. 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.
  5. 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:
  6. 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.
  7. 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)
  8. 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.
  9. 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!
  10. ACRE or TFAR

    This is just not true, do some fact checking before posting. In fact you can set frequencies on the 148 and the 117F (in ACRE and rl), the 343 and 152 are preprogrammed with channels.
  11. ACRE or TFAR

    So, it is overly complicated to fill in 3 names on a form to get a password to a teamspeak channel, that you, god forbid, have to manually join?
  12. ACRE or TFAR

    The same thing you said about medical is true for radios (TFAR and ACRE): you get a radio, open it's interface, select a channel (either by inputting it yourself or selecting the right channel), and you can talk. All the advanced stuff comes, like with the medical system, by using it. Oh and about terrain interception, as a new play I don't think you'll be more then 300m away from your team anyways. I wasn't really giving an argument against TFAR here, more trying to stop the thing about EU3 not being realistic and ACRE being way more difficult to use. You'll have your point though that ACRE can be annoying sometimes, one can only hope that will be fixed in the next version.
  13. ACRE or TFAR

    True, but TFAR isn't being worked on anymore (their might be a release for a bug that pops up with a new ArmA version, but no new features are in the make), while ACRE, and I quote NouberNou, the guy from ACRE (25th June 2016, two days ago): Also on the whole realism discussion, I have to say that the mentality changed since the server was first out: people used to be more patient and planning a mission could take a good 20 minutes, something I can't imagine today. So say what you want about EU3 not wanting realism, know some (a high amount of the ones that were here early) do want that realism. And to end, think about this: you don't want people learning some keybindings (they can change) and learning not to talk at the same time, but you do expect them to learn an advanced medical system (wich even I don't know everything about and I've been using it for more than a year), advanced ballistics, a mortar system wich requires a couple a minutes of preparation to even fire a single shell and not to turn to hard in jets, or they pass out? And to clarify, just in case it wasn't clear: I'm on team ACRE
  14. ACRE or TFAR

    It does not, ACRE has a setting to make it full-duplex
  15. ACRE or TFAR

    + While it is true that communication satellites are used (such a suprise, I know), those aren't used on platoon level comms, because why on earth would you use satellites to communicate when you're a couple of clicks apart? Sat-comms are (as far as I know) mostly used in bases to communicate with HQ, not by units in the field (except for FAC's)
×