Jump to content


  • Content count

  • Joined

  • Last visited

  • Medals

Everything posted by Sparker

  1. I couldn't find any script/tool/addon which would provide such a basic functionality: how much is ARMA's SQF scheduler loaded right now? Can I run a check every X milliseconds, with the given other scripts running in background? When we are spawning many different SQF scripts with infinite loops we want to know how much the SQF scheduler is loaded with these scripts. Typically we would try to force the scheduler to execute a simple script and observe the delay between spawning the script and its output. For instance you could spawn a lightning with Zeus and estimate the delay. How it works: The script I suggest uses the same idea: it runs an infinite loop, where it tries to execute a piece of code as often as the scheduler lets and measuring time intervals between executions. If the scheduler is flooded with many heavy scripts then sequential executions of our tiny script will happen less often. The script also performs exponential averaging of measured intervals. What it shows: It shows the delay between executions described above. The delay can help us understand the maximum frequency at which your loops can run(average). It also outputs the overload, measured in percents, which is equal to: overload=100*game FPS*delay=100*game_FPS/SQF_FPS. So if the "overload" is around100%, SQF scripts are running at roughly the game's frame rate. If it is 200%, then spawned SQF scripts are running at half the game's frame rate, and so on. Why not just measure performance of single scripts with standard methods? Maybe you are running other people's scripts in the mission, or you want to get an overview, how much load all the scripts produce. How to use it: Run this locally: Measurements will be output to system chat. You can fine-tune _a to perform smaller or bigger averaging (smaller _a -> bigger averaging). [] spawn { sl_prev = time; private _i = 0; private _ds = 0; // Smoothed value of delta private _a = 0.009; // private _N = 30; while {true} do { sleep 0.001; private _t = time; // Get current time private _delta = _t - sl_prev; // Calculate time passed since previous measurement sl_prev = _t; // Store the new time back _ds = _a * _delta + (1-_a)*_ds; // Exponential averaging //Output value every N measurements _i = _i + 1; if (_i == _N) then { _i = 0; private _overloadPercent = round(100*diag_fps*_ds); systemChat ((format ["Scheduler delay: %1 ms, overload: %2", round(_ds*1000), _overloadPercent]) + "%"); // Calculate new value for N to produce outputs every 0.5 seconds _N = ceil(0.5/_ds); }; }; If you want to quickly test the script here's a dummy load you can use. Just run it a few times: for [{_i=0}, {_i<5}, {_i=_i+1}] do { [] spawn { sleep random 1; while {true} do { sleep 0.5; private _a = []; //6 ms @ Core i7 3770 _a set [70, 0]; _a = _a apply {2}; { private _sum = 0; { _sum = _sum + _x; }forEach _a; } forEach _a; }; }; }; Please share what you think about this!
  2. AI Driving - Feedback topic

    Yes indeed. Since they can't do this I was forced to make a simple controller for that, might be helpful for you. It checks the maximum separation between vehicles in convoy(that is, maximum distance between pairs of cars following each other). Then if the distance is lower or higher a threshold it changes the lead vehicle speed linearly. Those who know the control theory might implement a PID controller for that.
  3. AI Driving - Feedback topic

    If that vehicle is a part of multi-vehicle convoy group, try to select a new leading vehicle, if you notice that the convoy has stuck. It helped me a lot. Also I wouldn't do "forceFollowRoad true", because then they won't be able to drive around an obstacle in the middle of a road.
  4. AI Driving - Feedback topic

    Here's a script I made a while ago to prevent friendlies driving over friendlies to death: private _unit = _this select 0; //: Object - Object the event handler is assigned to. private _source = _this select 3; //: Object - The source unit that caused the damage. private _instigator = _this select 6; //: Object - Person who pulled the trigger if ((side _source == side _unit) && /*(_projectile == "") &&*/ (isNull _instigator)) then { 0 }; Add it to the "HandleDamage" event handler with addEventHandler of the unit you want to protect from vehicle collision dammage. Now, if you do want a specific soldier to be killed with a vehicle... just don't give him this event handler, or remove it from him.
  5. AI Driving - Feedback topic

    How exactly does the magic 'modular' design going to revive the AI? After all, the AI 'module' will have to do exactly the same things. Get data from same kinds of entities, analize what's going on around, and perform the same actions as now. Maybe the new engine's AI will be build not with FSMs but with something else? Of course if they redo the AI from 0 it might improve things, because, as you said, the core of AI has been there from OFP times. As I see it, arma's AI is pretty good, apart from some cases when it severely fails.
  6. Now it should be used like this in mission.sqm: briefingName="@STR_MISSION_NAME_SQM"; Actually now there is a hint in the mission editor saying how to use it, if you put the cursor over the mission name field.
  7. AI Driving - Feedback topic

    I've found another condition when a vehicle gets stuck: if you order an inf. group to board an assigned vehicle and assign a "MOVE" waypoint to the group at the same time. They won't even attempt to turn on the engine. But if you add the waypoint after they have boarded the car, they start moving instantly. Steps to reproduce: //m0, m1 are guys of group g0. //"car" is the vehicle m0 assignAsDriver car; m1 assignAsGunner car; [m0, m1] orderGetIn true; // If you execute the second part (below) after they get in, the car starts moving fine wp0 = g0 addWaypoint [[2700, 3800, 0], 0]; wp0 setWaypointType "MOVE"; g0 setCurrentWaypoint _wp0;
  8. AI Driving - Feedback topic

    Apart from all the things already mentioned, sometimes AI ground vehicles are stuck so much that they don't even switch on engine to move to the waypoint. Happens both whis wheeled and tracked vehicles. I have found out that assigning waypoints without index (groupName addWaypoint [center, radius] instead of ... addWaypoint [center, radius, index, name]) reduces the chance of such event a lot. Anyway they still might get stuck. Also I've found that if they get stuck, assigning a new leader usually solves the problem. I guess that their brain gets reset or something like that. If this is not going to be repaired any time soon, maybe we can get at least some commands to debug what's going on in their brain? Like why he doesn't want to move: because his pathfinding has failed or something else. Or even better, some commands to reset their FSMs, redo the planning, etc. Really, my attemts to make them move sometimes remind me of something like this:
  9. Thank you for making this! I've been using your plugin for a while and I must say it does a great job!
  10. Hello! As ARMA's scripts spawned inside the scheduler behave as separate threads, it seems logical to me to have a way to estimate how much percents of total scheduler run time is taken by every spawned script, similar to what a task manager in any OS shows for started processes. Am I missing something, or is there really no such feature in ARMA? Thanks!
  11. How do you check if they are disturbed or not? You can check their behavior with this command: https://community.bistudio.com/wiki/behaviour Their default behaviour is usually AWARE. After they have spotted an enemy, it changes to COMBAT. Once they forget about their enemies(~ 3 minutes when the enemy is out of sight, must be fastrer if they just kill all enemies) the behaviour switches back to AWARE and you can order them to get into their vehicles.
  12. Yes, unless the script has been suspended with waitUntil or sleep. Now, If I have the majority of scripts suspended and a single one running an intense piece of code, the scheduler will mostly spend time executing this script while quickly checking and moving other suspended scripts to the top of the queue. So, I could say that 99% of scheduler's resource is utilized by this single script. Did I make a mistake anywhere? Of course a different way to estimate scheduler load is to measure execution time of everything between suspension statements, but it would still be hard to see the whole picture of how multiple scripts run concurrently. What If I have scripts that are made by other authors and I want to see their impact on performance? Another method I'm aware of is to spawn some script that does something and see how many seconds it takes the script to reach the top of scheduler queue. It is very strange that such a feature is not built into the game engine, considering that we have some diagnostics functions. I hope it will be implemented in the future.
  13. I've tried the script and I like it very much! Well done!
  14. Vcom AI V2.0 - AI Overhaul

    I think there is a Github repository for VCOM: https://github.com/genesis92x/VCOMAI
  15. Sorry I don't quite know how remote control works in Arma, but it is in Antistasi and you can check how it's implemented. I've had some success customizing my units through the modified arsenal by remote controlling them. In Antistasi, you have to recruit some guys through the flag's menu at the HQ, then select one, press Y button and search for temporary AI control.
  16. Well if you remote-control AI and open the arsenal, then i think, yes. Or do you want it to work another way?
  17. Well at start you have some stuff in the crate's basic inventory. Go to arsenal, push 'to crate' button and the stuff from 'inventory' will get transfered to 'arsenal' and you can play with it. Some are infinite, yes, this is done on purpose for basic items.
  18. Yes, by 'items' i mean fixed amount of each item. The way you've described it is exactly how it works. https://github.com/A3Antistasi/antistasiofficial Check folder called 'JeroenArsenal'
  19. Check 'Antistasi' mission. Jeroen Notenbomer, our friend, has implemented the arsenal with finite amount of items by modifying the existing Arsenal.
  20. That's an amazing project! I like how much effort you've put into these interiors. They look great! If you don't mind, a question just for my own curiosity, why are you using triggers to detect player presense? What benefit do they give for solving the 'player presense' problem compared to a scripted solution?
  21. How did you get those numbers? 0.016(seconds)*300(meters/second) gives only 4.8 meters/frame for 300m/s shell and 13 meters/frame for the high velocity MRLS rocket. Anyway, by coincidence I've made a similar script a few days ago(To spawn an AI base if the player wants to mortar it). It uses the method proposed above, but it turns out that per-frame timing is excessive. First we can check with rather long time intervals(~1 second) until the mortar shell ascends to its apogee. Then we check with 0.1 time intervals the time until the mortar shell falls. I estimate it by dividing shell's altitude above the ground by it's vertical velocity. When the time is below some threshold(say, 8 seconds, but you can use a lower one for your case) we can roughly estimate where it's going to land by taking its current horizontal velocity and multiplying it by the estimated time-to-explosion(a linear approximation). Note that this gives higher errors if the shell is travelling above mountains. The method works not bad, but it depends on how big is the zone you want to 'protect'. You can tweak the timing constants to get more precision. If you want super high precision, i think I've seen a function that can tell you where a given line will intersect with terrain. Also the code comes with a bonus: it filters out the HMG/GMG turret fire by arma's default artilleries.
  22. Hi! I was looking for a similar "catch all" script and found this thread. Sinse beno_83au didn't find what he was looking for, i thought i'd share what I've achieved. The suppressor's value is located at configfile >> "CfgWeapons" >> _attachment >> "ItemInfo" >> "AmmoCoef" >> "audibleFire". My main trouble was the russian weapons from RHS. There are muzzle attachments in RHS which are in fact not silensers(flame suppressors or smth. like that), so they have "audibleFire" set to 1.0. Normal silencers typically have "audibleFire" below 1.0,:0.04 for standard silencers and 0.4 for RHS silencers. That's how we can filter out these 'fake silencer' attachments. For builtin silensers, the "audibleFire" from weapon's ammo seems to be a reliable indicator if the weapon is silenced(check the table in the code below). So, here's the function if someone needs it:
  23. Get road type?

    i also came across this thread and your idea to use isOnRoad is very good! So I made a similar function. It takes into account the direction of a road, then starts probing it with isOnRoad in both directions orthogonal to the direction of the road and returns decent results for segments of a road facing anywhere. I hope it's of any help. Also an interesting thing I've learned, the position returned by nearRoads is not always in the middle of the road, but the isOnRoad does its job well(in terms of symmetry). On the picture, blue arrow is the middle point returned by getPos road, and pink arrows show how isOnRoad works. Picture link: steam screenshot /* Measures the width of a road object with given precision paramerets: [_road, _precision, _maxWidth] _road - road object acquired by nearRoads _precision - the precision with which to find the width _maxWidth - the maximum width. If the road is wider, the return value will max at _maxWidth return value: number, road width or 0 if wrong road object was given Author: Sparker */ params [["_road", objNull, [objNull]], "_precision", "_maxWidth"]; if(isNull _road) exitWith {"Road is null"}; //Wrong data was given private _connectedRoads = roadsConnectedTo _road; private _numConnectedRoads = count _connectedRoads; if (_numConnectedRoads == 0) exitWith {"Road is not connected to anything"}; //Connected road not found, can't calculate direction private _direction = 0; if(_numConnectedRoads == 1) then //If it's the end of the road { _direction = _road getDir (_connectedRoads select 0); diag_log "Detected one connected road"; } else //Else approximate the direction by the direction between two nearest segments { _direction = (_connectedRoads select 0) getDir (_connectedRoads select 1); diag_log "Detected two connected roads"; }; //Spawn an arrow facing the road private _roadPos = getPos _road; //Create arrow for debug //_arrow = "Sign_Arrow_Blue_F" createVehicle _roadPos; //_arrow setVectorDirAndUp [[0, 0, 1], [sin _direction, cos _direction, 0]]; //Get orthogonal direction private _cos = cos (_direction+90); private _sin = sin (_direction+90); private _vectorDir = [_sin, _cos, 0]; //Find road width in one direction private _checkPos = _roadPos; private _testWidth = 0; private _width = 0; while {(_width <= _maxWidth) && (isOnRoad _checkPos)} do { _width = _width + _precision; _testWidth = _testWidth + _precision; _checkPos = _roadPos vectorAdd (_vectorDir vectorMultiply _testWidth); //Create arrow for debug //"Sign_Arrow_Pink_F" createVehicle _checkPos; }; //Find road width in another direction _testWidth = 0; _vectorDir = [-_sin, -_cos, 0]; //Rotate the vector 180 degrees _checkPos = _roadPos; while {(_width <= _maxWidth) && (isOnRoad _checkPos)} do { _width = _width + _precision; _testWidth = _testWidth + _precision; _checkPos = _roadPos vectorAdd (_vectorDir vectorMultiply _testWidth); //Create arrow for debug //"Sign_Arrow_Pink_F" createVehicle _checkPos; }; _width
  24. End Game MP Mode - Feedback

    Hello! I tried the End Game game mode an I like it. I have just thought, maybe disabling respawn at team leader's position could make this game mode more tactical(because players will have to approach the area again every time) and slow-paced(because players will not appear on the battle field of nowhere). What do you think?