demon cleaner

CWR2 - Domination Everon - 1985 Edition I've ported Xeno's ever so popular Domination to the new CWR2 island of Everon. I've created the following Domination flavors based on the Domination 2.60 release: Standard versions: Domination West Combined Operations Domination East Combined Operations Domination West Operation Arrowhead Domination East Operation Arrowhead ACE Mod versions: Domination West Combined Operations ACE Domination East Combined Operations ACE Domination West Operation Arrowhead ACE Domination East Operation Arrowhead ACE About: Basically I've kept things close to the original Domination version but have exchanged all vehicles, weapons, ammo and units to what CWR2 currently had to offer. Exceptions exist for vehicles as in cases where there is no suitable replacement or where removing or exchanging a certain vehicle would have created to much of an imbalance between the opposing factions / different versions or give one side an overly unfair advantage over the other, i've kept the vehicle from the original version. The standard versions are basically vanilla Domination versions except some unit slots have been changed. The ACE Mod versions deviate a bit more from the originals and should be considered to be an alpha trial. As of yet I've converted about 20 side missions to suit locations on Everon. I will probably convert the rest of them as well but fixing bugs will take priority. I haven't done much testing and am basically releasing the missions as is in order to get some feedback on where they need fixing. Please don't report problems with this particular version of Domination to Xeno. Report them to ME as it's highly likely that I broke stuff. I'll see if I can get proper bug tracking and some web space over at Dev Heaven but until that's sorted you can send me PMs in case you find stuff that's broken. Before reporting a bug please check whether the bug appears in the original Domination (v2.60 as of now) as well. If it appears also in the original version of Domination, file a bug report here. Lastly I'd like to point out that the license under which Xeno distributes the original version of Domination of course also applies to this derivative. Update 1 available Changelog: - Fixed chopper reload/rearm - Transport choppers are unarmed now - Fixed bonus vehicle spawn positions - Fixed several broken missions - Added 5 more missions - Changed service point descriptions - Added more ACE equipment to weapon/ammo crates - Changed wreck chopper position and model - Fixed AT4 launcher being in the wrong ammo crate - Changed position of medic tent #2 - Other small tweaks and fixes I forgot about Direct download: CWR2 Domination Everon 1985 Edition Update 1 CWR2 Domination Everon 1985 Edition Mirrors: Armaholic Credits: Xeno - For creating Domination and generously letting people use his stuff For those who don't know about CWR2: Download link: CWR2 Forum discussion: CWR2 For those who don't know about ACE Mod: Download link: ACE Mod Forum discussion: ACE Mod Enjoy ! Demon Cleaner

DMC Air Patrol This is something that has been gathering some dust on my hard drive. Originally written for one of my ArmA II missions I've decided to revive it for ArmA III in the hope that somebody might find it useful. If you do implement it into your missions I'd be happy if you would let me know where to download them. I'd love to see how people make use of this script. What does it do ? DMC Air Patrol is a script that can spawn a configurable amount air patrol vehicles including crew. It will read the configuration file of the current map and use the predifined locations in this file to plot a randomized flight course for each patrol vehicle. If an air patrol encounters an enemy presence in it's flight path it will attack and try to obliterate the enemy. When done the air patrol will return to it's flight path and repeat as new enemies are encountered. If a patrol vehicle is destroyed a replacement will be spawned after a configurable timer runs out. Which options can be configured ? 1. Search radius for pre-defined map locations 2. Spawn positions for the air patrol vehicle 3. Name of the marker representing the area of operations center for the air patrol 4. Type of vehicle used by air patrol 5. Side of the air patrol 6. Flight altitude 7. Rules of engagement 8. Combat behaviour 9. Movement speed 10. Skill of the crew 11. Amount of patrol vehicles to spawn 12. Time to wait before spawning a new instance of a patrol vehicle if destroyed 13. Whether or not to randomize waypoints How do I implement it in my mission ? The download contains 2 demo missions (Stratis / Altis) that should be pretty much self explanatory. I've also provided an init.sqf that can be ripped apart to cater your needs. Basically all that's needed in your mission is some markers that represent spawn locations which will be read and then randomized by the script upon init. Since version 1.3 there's a readme.txt included which describes the implementation in even more detail. Does it work in Multiplayer ? Actually it should. Since the script is only run on the server and does not need to communicate with clients I don't see why it would not. Though I haven't tested it and if you encounter any multiplayer weirdness let me know. Where is the download ? Dropbox mirror: DMC Air Patrol Dev Heaven mirror: DMC Air Patrol Changelog: http://dev.withsix.com/projects/dmc-air-patrol/news Bugtracker: http://dev.withsix.com/projects/dmc-air-patrol/issues Hints for mission editors: - If you want three air patrols in your mission you need to define three starting positions - If the script throws errors relating to waypoints, make sure your location search radius is big enough to contain map locations (Towns / Villages)

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 !

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 ?

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

Sounds like a broken download... Download the archive again just to be sure. When you open the downloaded archive it should contain the following files and folders: functions functions\fn_spawnAirPatrol.sqf cfgFunctions.hpp cfgHints.hpp description.ext init.sqf mission.sqm readme.txt If you have verified the archive contains the above files, load up the mission in the editor. There should be a couple of vehicles at the Altis International Airport (if you're using the Stratis version check the airfield complex) as well as the player starting position. You can start the mission from the editor as you would with any other singleplayer mission.

The check for empty cargo positions is easy but the logic of when to deploy the units in cargo is a bit more tricky. Let's assume you only have one patrol waypoint. Well that's easy then. You reach the patrol waypoint and deploy the troops. However the script can generate a random flight path from the available waypoints which means that you don't know if the waypoint you placed some enemy will be first, last or anything inbetween. Secondly you can only really deploy the in cargo units once (respawning units into empty cargo positions in flight could be done but that doesn't really solve the issue of WHEN to deploy). Anyway I'll play around a bit to see what I can come up with. Thanks for the suggestion anyway. I'll report back on this one.

An update is available. Version is v1.3 now. Download links in first post have been updated. Enjoy! Changelog for v1.3: - Reworked waypoint randomization - Added DMC_spawnAirPatrol function to autoinit (auto compilation) - Removed uneccessary check for BIS fnc init (functions are preloaded) - Added debug markers for mission designers (check variables in init.sqf) - Larger waypoint completion radius - Default patrol time (vehicle respawn) changed to 60 minutes - Changed combat behaviour to make air patrols more agressive - Changed air patrol vehicle crew default skills - Changed air patrol vehicle default flight altitude - Changed air patrol vehicle default speed to FULL - Added a readme.txt explaining how to implement this script

No need to specify the current game world name as parameter anymore. I feel kinda useless that I didn't spot worldName the first time I was looking into this ... Anyway the script has been updated to v1.2. Download links in the first post have been updated as well. BTW: I'm using the bugtracker over at dev-heaven now so file bugs and feature requests over there please. Enjoy!

Nice one Shuko. I'm always on the lookout for your stuff. Keep it coming!

Thanks m8! I was hoping someone would find it useful.

As per request the number of patrolling vehicles can now be specified as a parameter. Actually I've changed things around quite a bit. The script is now pre compiled on init and thus can be used as a function and be called when needed. I've also changed the way vehicle respawns are handled. If a patrol vehicle is destroyed it will now automatically spawn a new vehicle automatically after a configurable timer runs out. The init.sqf has changed quite a bit as well but it's all well commented so the transition if you've used the old version should be easy enough. The link in the first post has been updated. Enjoy.

Thanks Hajimoto. You could always make the script into a function and compile it on mission init. Then when you feel you need another patrol simply call the function to generate a new instance. However I'll take a look at whether I can implement a parameter to specify how many patrols to spawn.