Jump to content

Jochem

Community Member
  • Posts

    62
  • Joined

  • Last visited

  • Donations

    0.00 GBP 

Posts posted by Jochem

  1. 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.

     

    26 minutes ago, Stanhope said:

    As far as i've seen we don't have a single player on AWE that actually has any proper experience with it.  That might just be me tho.

    I felt kinda sad when I read this, as Mini is actually a very competent commander. This video (hopefully) proves that:

    Spoiler

     

    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.

     

    41 minutes ago, Stanhope said:

    I said it wouldn't lead to any better, let alone good, teamwork.

    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.

  2. 3 hours ago, hobnob11 said:

    1: They tend to take a very loose interpretation of ASL's orders, for example if being ordered to stay 200-300m behind ASL they will be 400m "near" ASL (usually in front)

    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.

     

    3 hours ago, hobnob11 said:

    2: They throw a tantrum when they don't get to do what they want, often disconnecting instead of switching to a more needed role like alpha, quoting how asking for more people in ASL than FSG is killing all fun possible.

    3 hours ago, Noah_Hero said:

    Fill out a player report because they broke Rule 3 (Listen to the Chain Of Command.)!

    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.

     

    3 hours ago, hobnob11 said:

    My solution to this "problem" is to tell FSG to go alpha / bravo as an inf squad, and have 3 pilots, 2 in a heavy CAS bird that can engage the kind of targets FSG is supposed too and one dedicated to transport. this provides the same level of "lol point and click no skill izi pizi tank dead" that a well equipped FSG team has, but only taking up 2 people instead of 5. And they have much less difficulty dealing with the specific target you want to die.

    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.

  3. 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.

  4. 1 hour ago, McKillen said:

    Problem is the cleanup script will clean anything that is dropped by players etc. This will mean that the eventhandlers will need to be added to every item that is dropped. Also used for the ejection seats which will then have the same issue. For units, yes i could see it working however there will need to be another script to add eventhandlers to each newly dropped items such as when an AI dies, and drops his weapon, or when a player drops his equipment on the ground then a way is needed to add the eventhandler to said item etc.

    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).

  5. 8 hours ago, Ryko said:

    For example, some exception handling in the cleanup script that skips the cleanup of units that are within X meters of a player, just in case that player wants to scavenge off the dead body.

    That's not what exception handling is, I assume you meant a regular if that checks for nearby players.

     

    8 hours ago, Ryko said:

    Trying to make a megascript to handle all scheduling of events becomes problematic the larger the script becomes.  If the script can't be completed within 3ms it gets postponed to the next cycle, where it is pushed to the back to allow other scripts an opportunity to complete.  So if you have other things waiting for that script to complete, your mission will start to fall apart.  Simplicity is key.

    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.

     

    16 hours ago, McKillen said:

    Sadly adding event handlers also hits performance

    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.
  6. 19 minutes ago, Ryko said:

    Generally I would put it like this: our emphasis would be on efficient scripting that results in good frame rates. I generally frown upon missions where every enemy is placed down in the editor with a bunch of waypoints, because this tends to reduce mission performance without providing a benefit to player gameplay.  Therefore it's a better practice to either create something with the intention of a Zeus to run (so enemy units can be spawned dynamically in better response to player position) or with a dynamic spawn system where units are spawned and removed as required by the mission (Gauntlet does this).

     

    New mission makers tend to dump a bunch of units and props, give them a bunch of waypoints, add some tasks and think that the mission will be perfect. This is often not the case.

     

    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.

  7. I knocked myself out, the code is a bit more complex, but I kept all the code in one file:

    Spoiler
    
    cs_spawnSniper = {
    	//Pos needs to be in PositionAGL
    	params["_pos","_target"];
    
    	//Create sniper
    	_grp = createGroup east;
    	_sniper = _grp createUnit ["O_T_sniper_F", _pos, [], 10, "FORM"];
    	_sniper setUnitPos "down";
    	_sniper setCombatMode "red";
    	_sniper setBehaviour "stealth";
    
    	//Sniper now knows about the target
    	_sniper reveal [_target,4];
    	//Sniper will engage target
    	_sniper doTarget _target;
    
    	_sniper setSkill 0.9; 
    };
    
    cs_getHighestPos = {
    	params["_pos","_radius"];
    
    	_highestPos = [0,0,0];
    	_highestHeight = 0;
    
    	_posX = 0;
    	_posY = 0;
    
    	_startPos = (_pos getPos [(_radius/2)-5, 0]) getPos [(_radius/2)-5, -90];
    	_currentPos = _startPos;
    
    	for "_posY" from 10 to _radius step 10 do{
    		for "_posX" from 10 to _radius step 10 do{
    			if((getTerrainHeightASL _currentPos > _highestHeight) && (west countSide (_currentPos nearEntities 250) == 0))then{
    				_highestHeight = getTerrainHeightASL _currentPos;
    				_highestPos = _currentPos;
    			};
    			_currentPos = _currentPos getPos [10, 90];
    		};
    		_currentPos = _startPos getPos [_posY, -180];
    	};
    	
    	_highestPos;
    };
    
    cs_init = {
    	//https://community.bistudio.com/wiki/remoteExecCall
    	{
    		//https://github.com/michail-nikolaev/task-force-arma-3-radio/wiki/API%3A-Events
    		["DetectLRTraffic", "OnTangent", {
    			params["_unit","_notUsed","_radioType"];
    			if(_radioType == 1)then{
    				if(player getVariable["LRIsSpeaking",false])then{
    					player setVariable["LRIsSpeaking",false,true];
    					player setVariable["LRTransmissionTime", ((player getVariable["LRTransmissionTime",0]) + (diag_tickTime - (player getVariable["LRStartedSpeaking",0]))), true];
    					player setVariable["LRStartedSpeaking",0,true];
    				}else{
    					player setVariable["LRIsSpeaking",true,true];
    					player setVariable["LRStartedSpeaking",diag_tickTime,true];
    				};
    			};
    		}, player] call TFAR_fnc_addEventHandler;
    	} remoteExecCall ["bis_fnc_call", 0, true];
    
    	[{
    		{
    			if(player getVariable["LRTransmissionTime",0] >= 10)then{
    				_posSniper = [getPosATL player,1000]call cs_getHighestPos;
    				[_posSniper, player]call cs_spawnSniper;
    				player setVariable["LRTransmissionTime",0,true];
    			};
    		} forEach allPlayers;
    	} , 1, []] call CBA_fnc_addPerFrameHandler;
    };

     

     

    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:

    Spoiler
    
    call compile preprocessFileLineNumbers "sniper.sqf"; 
    []call cs_init;

     

     

  8. 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.

  9. 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)

    Spoiler
    
    _pos = getPosWorld player;
    _radius = 1000;
    
    _highestPos = [0,0,0];
    _highestHeight = 0;
    
    _posX = 0;
    _posY = 0;
    
    _startPos = (_pos getPos [245, 0]) getPos [245, -90];
    _currentPos = _startPos;
    
    for "_posY" from 10 to _radius step 10 do{
    	for "_posX" from 10 to _radius step 10 do{
    		if(getTerrainHeightASL _currentPos > _highestHeight)then{
    			_highestHeight = getTerrainHeightASL _currentPos;
    			_highestPos = _currentPos;
    		};
    		_currentPos = _currentPos getPos [10, 90];
    	};
    	_currentPos = _startPos getPos [_posY, -180];
    };

     

     

  10. 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:

    Spoiler
    _pos = getPos player;
    _radius = 1000;
     
    _highestPos = [0,0,0];
    _highestHeight = 0;
     
    _posX = 0;
    _posY = 0;
     
    _startPos = (_pos getPos [245, 0]) getPos [245, -90];
    _currentPos = _startPos;
     
    while{_posY < _radius}do{
        while{_posX < _radius}do{
            if(getTerrainHeightASL _currentPos > _highestHeight)then{
                _highestHeight = getTerrainHeightASL _currentPos;
                _highestPos = _currentPos;
            };
            _currentPos = _currentPos getPos [10,90];
            _posX = _posX + 10;
        };
        _posY = _posY + 10;
        _posX = 0;
        player setPos _startPos;
        _currentPos = _startPos getPos [_posY,-180];
    };
     
    player setPos _highestPos;

     

    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!

  11. 55 minutes ago, Remixer said:

    I would say TFAR is more "realistic" and more fun to use, since it uses frequensies instead of channels. I have never seen a radio irl that uses channels.

     

    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.

  12. 10 minutes ago, Blue-958- said:

    A new player does not need to learn any of these things, maybe a bit of medical but just to the extent of 'Use elastics and packing' They do, however need to understand the radios from the very first time they play

     

    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. 9 hours ago, Ghostdragon said:

    ah ok, on another point the stable release for ACRE was released 05.17.15 and TFAR 06-10-2015 making tfar the more up to date either way it is looked at.

     

    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):

    Quote

    We have been in active development this whole time, it is just that there are significant changes in the next version and we really want to flesh them out.

     

    That being said though, things have been hectic with real life the last few months for everyone on the ACRE team. Luckily all good news for everyone, but still busy busy busy. We've been on the verge of a public release for 6 weeks now, we just need to get a couple more tests out and done.

     

    Also my real life stuff is that I am now working on programming real life radios.

     

    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. + 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)

  15. Uniform mods I'm just gonna keep my hands off since I don't really care about what I'm wearing anyway, as long as I can have a camo that suits the environment.

     

    The chally on the other hand, and I'm really doing this with a pain in my heart, is gonna get a no from me. Like mini said, the thing is as OP as the 230mm artillery piece is. It destroys everything. Helicopters, infantry, tanks, rabbits, doesn't matter what, it will die. The gun is too good with an insanely short reload time and a quadrillion penetration, and it has HESH (if you don't know what this is just imagine I once accidentally wiped out the whole of alpha with one HESH shell (again, sorry josh)). It was fun while it lasted and I admit I at first supported posts to get it back, but I'm over it know and know it will always have a place in my (virtual) heart. 

     

    Wow, that got emotional, time to kill some Russians to forget this.

×
×
  • Create New...