demon cleaner

You want to read and understand this post: https://forums.bistudio.com/topic/190132-major-fps-drop-after-playing-10min/?p=3013267 Specifically read and understand the "To quickly DETAIL THE FIXES" before making any changes. Optional step: Try using the latest TBB4 memory allocator. Download link is here: https://www.threadingbuildingblocks.org/download#stable-releases I'm not going to step by step this one because downloading the correct archive depends on knowing your machine arch and installed software as well as replacing original files from your ArmA3 installation. Please understand that this might break your ArmA installation if done incorrectly and has not proven to actually solve any issues. I've done this purely out of curiosity and have since reverted back to the original files as the proposed fix is working for me regardless of whether or not I'm using the TBB4 replacement.

Try giving the latest TBB4 a shot. I'm playing for over an hour now (SP) without any performance issues. Not saying this is a solution but it's working for me so far and might just be good enough as a workaround until BI finds out what's really going on. I'm using the precompiled binary version 4.4 Update 3. Download link is here: https://www.threadingbuildingblocks.org/download#stable-releases

Yes I'm using the 3D Editor.

Please be more specific. What exactly is the problem ? You've downloaded the archive and it's empty ? This sounds like a browser or packer/unpacker issue. Re-download using a different browser and/or newer version of your packer/unpacker software. Personally I use 7zip. If this does not solve the issue please let me know the download location and I'll go check the file. If you want to look at the example missions in the Editor you should load them into the 3D Editor. Also try if this download works for you.

I haven't done any performance testing tbh. I suppose it'll perform ok as it only reads location information from the map config, spawns vehicles and generates waypoints. Unless you're spawning tons of patrols it shoud not negatively affect performance. Area patrols should be easy. You can set a marker and specify a search radius for locations around that marker. The script will then only fetch locations within the specified range. Check the example mission files as that's what I've done there.

Foxhound to the rescue! Thanks

haha ... someone is getting it right. Keep on listening to the good stuff :) Actually I've released v1.41 as v1.4 contains a rather serious bug :blink: Download links updated in first post

I've updated this script ... it's been a while. Mirrors updated in first post. v1.4 - Fixed an error in waypoint generation - Added code to remove Air Patrol specific markers when not in debug - Refined waypoint generation and added debug markers - Added OPFOR air vehicle class names - Removed functions folder for simplicity - Fixed cfgFunctions.hpp Someone remind me again how to get stuff onto Armaholic. I guess I'm old and keep forgetting things. :wacko: BTW: I guess I'm back ;)

Guys I'm long gone from the game and the community. I'll probably not touch this script again but I just figured it would just be fair and try to help people one last time. I've downloaded the latest version from either of the 3 available sources and I can't replicate any issues with downloading the files. After unpacking the archive files are just fine and I can load up the example missions in the editor. So I don't know why people seem to have issues with the downloads. @brunohxcx: 1. Your mission already contains cfgFunctions. This can only be defined once. Try including this into your existing cfgFunctions definition: class DMC { class ServerFunctions { file = "functions"; class spawnAirPatrol { // 1 to call the function upon mission start, before objects are initialized. // Passed arguments are ["preInit"] preInit = 0; // 1 to call the function upon mission start, after objects are initialized. // Passed arguments are ["postInit"] postInit = 0; // 1 to recompile the function upon mission start // Mission functions are always compiled on init. No need to be redundant. recompile = 0; // Set file type, can be ".sqf" or ".fsm" (meaning scripted FSM). // Default is ".sqf". ext = ".sqf"; }; }; }; 2. As you can see the file locations in your mission are different than what's in my demo mission. You will need to edit the all references of file locations in my scripts to reflect your mission specifics. @JAndrews1: The error basically says that "dmc_fnc_spawnairpatrol" is undefined. It's telling you that the variable that is used to reference the air patrol spawning function is empty. This can have any number of reasons. Just a wild guess ... did you create "mkrAirPatSta_01, ..." markers in your mission ? Because the script relies on those markers being present in the mission.sqm. Also verify that any references to file locations in your scripts as well as my scripts are correct. Beyond that please understand that I won't be able to help further. If you can't get it working please ask an experienced scripter in the forums to maybe review your mission init files. Good Luck

Most excellent ! Have been playing around with it a lot. Maybe a config option for the timings (arty reload, standby ...) would come in handy. Thank you !

That's exactly what I'm doing. I'm checking the contents of _tN right before the switch control structure (and with right before I mean no other code lines between the typeName and content check of _tN and the switch control structure). To illustrate it: (NB: I've converted everything to lower case values just to not run into case sensivity issues) _res = format ["varValue:%1,varType:%2",_tn,typeName _tn]; <- results in _res=="varValue:x,varType:STRING" _tst = switch (_tn) do { case "x" : {"a"}; case "y" : {"b"}; }; _res = format ["varValue:%1,varType:%2",_tn,typeName _tn]; <- results in _res=="varValue:TRUE,varType:BOOL" I'll spend some more time on this later today. Thanks by the way for the link to the discussion pages. I honestly never noticed the tab... :banghead:

You are correct. The default case goes without ":". Thanks for the link to the discussion page.

Interesting since http://community.bistudio.com/wiki/switch doesn't mention it. Neither does http://community.bistudio.com/wiki/Control_Structures. I know that http://community.bistudio.com/wiki/getVariable is case sensitive. In any case I made sure to use the correct case converting all strings to lower case. Still no difference. ---------- Post added at 08:47 ---------- Previous post was at 08:34 ---------- The explanation seems logical though http://community.bistudio.com/wiki/Control_Structures and http://community.bistudio.com/wiki/switch don't mention it. I cannot reproduce the behaviour in any other way than what you did in the above example and this is weird because I'm doing a typeName check for _tN right before the switch control structure and the variable at that point is of type STRING and contains x or y.... _tst = typeName _tN; // STRING hint format ["_tst: %1",_tst]; // x || y _tst = switch (_tN) do { case "x" : {"A"}; case "y" : {"B"}; }; _tst = typeName _tN; // BOOL hint format ["_tst: %1",_tst]; // TRUE ---------- Post added at 09:11 ---------- Previous post was at 08:47 ---------- Hmmm I guess I finally understood what the default case can do for me ... _tst = switch (_tN) do { case "x" : {"A"}; case "y" : {"B"}; default : {"C"}; // <-- Use me to figure things out quicker };

OK I kind of solved it but the weirdness remains. I've now exchanged the STRING type values for NUM type values (e.g 0 and 1 instead of x and y): _tst = switch (_tN) do { case 0 : {"A"}; case 1 : {"B"}; }; This appears to work as the above results in _tst either being "A" or "B" depending on the value of _tN. Still I don't get why type STRING comparisons will result in BOOL ...

Hi! While working on some scripting I came across some weirdness when using the switch control structure on the STRING data type. I'm using setVariable to store a variable in a game logic. The data type I'm storing is STRING I've verified that. _object setVariable [_var,_val,_sync]; To test the data type I'm retrieving the variable value like this: _tN = _object getVariable _varName; Checking on the data type I'm getting what I expect. _tst = typeName _tN; At this point _tst is of data type STRING which is expectable and it contains whatever STRING I've stored earlier. So far so good but now I'm using a switch control structure like this: _tst = switch (_tN) do { case "x" : {"A"}; case "y" : {"B"}; }; At this point _tst contains TRUE and is of type BOOL instead of containing A or B of type STRING. Testing the contents of _tN beforhand reveals it contains either x or y of type STRING. Using the same control structure on a different data type gives me the expectable result. _tst = switch (_tN) do { case "x" : {[1,1]}; case "y" : {[2,2]}; }; At this point _tst is of type ARRAY and contains either [1,1] or [2,2] depending on the contents of _tN. DOH! Ideas anyone ?