Jump to content

thy_

Member
  • Content Count

    266
  • Joined

  • Last visited

  • Medals

Everything posted by thy_

  1. CSWR is an Arma 3 script that allows the Mission Editor to spawn AI units and vehicles (by ground or air paradrop) and makes those groups move randomly to waypoints forever in life, where spawn-points and waypoints are easily pre-defined by Mission Editor through Eden marker's positions. CSWR accepts faction loadout customization, including additional customizations for sniper teams and paratroopers. CSWR almost doesn't change any original Arma AI behavior, saving server performance and Arma 3 integrity. Creation concept: bring life to the mission through non-stop units' movements with some level of unpredictability without losing control of server performance and what AI units can do. Special thanks: To the old (but gold) "T8 Units" script for the inspiration over the years. How to install / Documentation: https://github.com/aldolammel/Arma-3-Controlled-Spawn-And-Waypoints-Randomizr-Script/blob/main/_CSWR_Script_Documentation.pdf What to expect from the CSWR script: No dependencies from other mods or scripts; Manually define which markers the faction can use as spawn-points; Create unlimited different types of spawn-points: Common spawn: for units and ground vehicles; Vehicle spawn: exclusive for ground vehicles; Heli spawn: exclusive for helicopters; Paradrop spawn: for units and ground vehicles; Sectorized spawn: all spawn types can be sectorized to be available only for specific groups/vehicles inside a faction; Spawn-points can be triggered by: Mission starts: right after the mission gets started; Timer delay: a down count; Trigger delay: when some editor's trigger is activated; Target delay: when a specific unit or vehicle or building is killed/destroyed; Once the spawn-points are created, the script will spawn the groups randomly through their faction spawns; There is no re-spawn. Death is death for units and vehicles spawned by CSWR; Vehicles with turrets spawned by CSWR, when damaged, their gunners never leave the vehicle, doing the last standing in combat until death; Manually define which markers will be used as one types of destinations (waypoints) for AI units and vehicles; Create unlimited different types of destinations: Move: groups will move randomly through your predefined move-markers; IMPROVED! Watch: sniper groups will search for the best high position to cover one of your predefined watch-markers; Hold: soldiers, civilians, or ground vehicles (mainly tracked ones) will set position facing a specific direction predefined by you with hold-markers; IMPROVED! Occupy: soldiers and civilians will search for a building around a predefined occupy-marker, and will go there, get in, and stay; IMPROVED! Sectorized destination: all destination types can be sectorized to be available only for specific groups/vehicles inside a faction; Once the destination markers are created, CSWR will take care of taking (or not) the groups there, randomly; Manually set the number of soldiers, who they are, their loadouts, who belongs in each group type, and even ground vehicles and helicopters; Add or remove Night-Vision-Goggles and Flashlights for one or more factions, easily through "True" or "False" management; There are 7 infantry templates and 8 vehicle templates to customize (with modded or vanilla things) for each faction; Define easily how many AI groups are in-game, what squad types they belong to, and their behavior: safe, aware, stealth, combat, chaos. For more details, check the documentation; IMPROVED! Available white and blacklist for buildings and ruins when groups are using Occupy movements; All vehicles and units spawned by CSWR can be (ON/OFF) editable by Zeus; Set if the CSWR should wait for another script load first on the server; Debugging: friendly error handling; Debugging: hint monitor to control some AI numbers; IMPROVED! Debugging: full documentation available. . Video demo: Video tutorials: Check the file above on GitHub. Check the file above on GitHub. Link on this post header. (Above) Editor set if all one side can use night vision goggles (or just parachuters, or only sniper teams), or only flashlights, or both gears or none. If flashlights are available they need to be on all the mission long or just when each AI decides. (Above) WATCH destination (specific for sniper groups) is working much better with high natural terrains, regardless of whether the map is an official one. (Above) Group executing OCCUPY destinations can get in high towers with better distribution positions inside. (Above) Group executing OCCUPY, if they select an acceptable ruin/destroyed building, the group will always get in a crouch in this kind of position. (Above) Even heavy ground vehicles can be paradropped. (Above) All groups paradropped, when touched the ground, they will focus on regrouping with their squad leader before starting their missions. (Above) Helicopters automatically identify where all safe and not busy helipads are to land if they need to rearm, repair, refuel, or heal their wounded crew. Dependencies: None 😉 Download: - On GitHub: https://github.com/aldolammel/Arma-3-Controlled-Spawn-And-Waypoints-Randomizr-Script - On Steam Workshop: https://steamcommunity.com/sharedfiles/filedetails/?id=2740912514 Missions using it: Tanks & Helicopters (light): https://steamcommunity.com/sharedfiles/filedetails/?id=2424050518 Escape from Kherson: https://steamcommunity.com/sharedfiles/filedetails/?id=2878171355 Ukrainian ATGM Team: https://steamcommunity.com/sharedfiles/filedetails/?id=2847369831 Fake SDF in Syria: https://steamcommunity.com/sharedfiles/filedetails/?id=2728537885 Tanks Theater: https://steamcommunity.com/sharedfiles/filedetails/?id=2160397214 ISIS VBIED: https://steamcommunity.com/sharedfiles/filedetails/?id=2732654349 - - - - - - - - - - - Changelog: Apr, 14th 2024 | v6.5.2: news, fixes and notes. Known issues: - Watch > Sniper groups still not considering buildings when no natural highlands to take a position for overwatching; - Occupy > If you hide a building and the building can be occupied, the groups will consider that hidden building as a regular place to occupy; Paradrop > When parachuters are civilians, they're crouched right after landing and stay like this forever. - Move Hold > Sometimes tracked vehicles are not facing exactly the marker direction configured by the editor;
  2. The script and its information in the main post have been updated! Apr, 14th 2024 | v6.5.2: Small update, that just makes the installation process easier and is supported by this video tutorial:
  3. Hey, @silvernik22 Did you try the CSWR? You can easily create an entire faction with customized uniforms, gears, and even behaviors.
  4. Hey, @Play3r pretty sure this might helps you to build your mission context: Look at "UXO Doctrine" over there 😉
  5. Hello! ETHICS is a full solution script for ARMA 3 that provides wide creation and management over statics kill zones like minefields, UXO zones, and trap zones. Built for single-player and multiplayer, ETHICS include kill zone doctrines such as land anti-personnel, land anti-materiel, naval anti-materiel, unexploded ordnance, and booby-trap. How to install / Documentation: https://github.com/aldolammel/Arma-3-Ethics-Minefields-Script/blob/main/ethics-minefields.Altis/ETHICSMinefields/_ETH_Script_Documentation.pdf What to expect from ETHICS script:   Drag and drop a marker on Eden to create a full and unique kill zone such as minefields; Also easy to build naval minefields, Unexploded ordnance zones (UXO), and Trap zones; Ethics control (ON/OFF) to avoid planting explosive devices through civilian areas; Topography control (ON/OFF) to avoid planting over rock clusters and mountains; NEW v1.5 UXO doesn't respect Ethics or topography rules, and can be dropped under the water; NEW v1.5 Boobs-trap doesn't respect topography rules and they are always hidden, never in the open; Anti-personnel (AP) landmines avoid roads and streets; Anti-materiel (AM) landmines can be planted (ON/OFF) only on roads and streets; Classic minefields can be also hybrid, bringing AP and AM mines features; Customize each doctrine's explosive with devices from RHS, CUP, or anyone mod; Set (or not) for each kill zone has a faction owner; NEW v1.7 Set (or not) for each kill zone a percentage of presence, controlling the kill zone spawn probability; Easy explosive devices amount management through the global intensity presets: lowest, low, mid, high, or extreme; Easy way to hide all markers on the map (ON/OFF), even to kill zone owners; Debugging: friendly error handling; Debugging: a hint monitor, and systemChat feedbacks for the mission editor; Debugging: full documentation available. Video demo: Soon. Script config: Dependencies: None 😉 Download: On GitHub: https://github.com/aldolammel/Arma-3-Ethics-Minefields-Script On Steam Workshop: https://steamcommunity.com/sharedfiles/filedetails/?id=2926204522 Missions using it: Escape from Kherson: https://steamcommunity.com/sharedfiles/filedetails/?id=2878171355 Sharia in Raqqa: https://steamcommunity.com/sharedfiles/filedetails/?id=1849325560 Adsumus: https://steamcommunity.com/sharedfiles/filedetails/?id=1838939661 Tank hunting: https://steamcommunity.com/sharedfiles/filedetails/?id=2468255648 - - - - - - - - - - - Changelog: Feb, 11th 2023 | v1.8: news, fixes and notes. Known issues: UXO cosmetic smokes are not working properly on Dedicated Server (WIP); Dynamic Simulation looks not work properly with mines; Mines is not editable by the Zeus module yet;
  6. @Kaarlo-7173a00cd297f8d9 , the error is pointing to this line on fn_ETH_playerLocal.sqf, a file that you shouldn't touch: // Check if the main script file is okay to keep going: if ( ETH_doctrinesLandMinefield OR ETH_doctrinesNavalMinefield OR ETH_doctrinesOXU OR ETH_doctrinesTraps ) then { ... That said, I guess the error's happening because something in fn_ETH_management is not right. Did you check if your file fn_ETH_management.sqf is correctly filled? The error you are facing could be some ";" missing or something like that. Make sure you're following all installation steps and doing exactly what the doc instructs you to do for each type of doctrine you are requesting with true (image above). If you need more support, let me know, bringing screenshots and/or a piece of code.
  7. There is the CSWR script that makes all you need: Spawn CUP TK Militia or any other vanilla or custom faction, including ground vehicles and helicopters; You can custom basically everything for each side; Set 4 times waypoints: move, hold, watch, and occupy; about the language: it's the scope of the new version that is coming out soon.
  8. Hey, folks. I am noticing that my missions sometimes are getting weird dependencies and it's coming not exactly because I am setting assets from DLCs intentionally but because things like these below happen. Am I missing some Arma 3 Cfg understanding or are those examples of true "errors"? Unit: B_soldier_M_F With bipod from Marksmen DLC: With no bipod: With bipod from Apex Expansion: PS: No mods loaded. Only vanilla content here. Another example is this dependency from Argo (Malden): There is even no asset icon to identify the dependency.
  9. Guys, any command recommendation? I will dive into this matter (post title) this weekend to improve my AI sniper team in the CSWR script. How the sniper group works at CSWR (before v6.5): Mission Editor sets a marker in the region that some sniper group should overwatch; AI sniper team spawns and make a search of high spot around the watch-marker (using nearestLocations); With a location found, the sniper group goes straight on there and stays facing forever that watch-marker position. Issue: Sometimes a bush or tree or other map asset stays right in front of the sniper, blocking their vision of the region they should overwatch. Rare, but happens: the terrain blocks the view of the target/region. Any suggestion of logic and commands? https://community.bistudio.com/wiki/getTerrainHeightASL
  10. // Listing all spots found in reverse sorted: _spots = [_building] call BIS_fnc_buildingPositions; // Take each spot ([x,y,z]) and its Z axis and sort them by highest to lower: _spots = [_spots, [], {_x select 2}, "DESCEND"] call BIS_fnc_sortBy; Above, a code where I'm identifying the highest spot in a building, but reading the BIS_fnc_sortBy, I'm pretty sure there are ways to figure out which two of those spots are closer to the object-target outside. My goal here is to let snipers know which position inside the building will provide a better view of the target zone far away, avoiding at least the center building walls itself. Any idea? I think perhaps using apply? My brain... Edited 45min later 😂: // Selecting only those spots that are near the target-zone when compares the the building center position (regularly the middle of the building asset): _spots = _spots select { _x distance2D _objTarget < (_building distance2D _objTarget) }; Running some tests, it's working well with towers (assets that often are narrow buildings) but not with churches where their bell towers are at one end of the building. Used: https://community.bistudio.com/wiki/BIS_fnc_buildingPositions https://community.bistudio.com/wiki/BIS_fnc_sortBy https://community.bistudio.com/wiki/select
  11. // [spot height, spot distance to the target, spot position] You're rock! Why exactly set that "1 divided" before the distance result?
  12. I'm having a couple of snipers (same group) reach their spot and then keep watch over a static position (in the image below represented by the lighthouse). What we noticed is that the more distant the lighthouse, the more untidy the "distracted" snipers' direction in relation to the position (lighthouse) they were supposed to be watching. I've given many go to align the group leader's position but the image was my best. Here are some commands that I've already tried: setDir, getDir, setFormDir. But doWatch and lookAt work better and, of course, because of the purpose, I chose to use doWatch. initServer.sqf (just for testing): waitUntil { !isNull grp1 }; private _sniperPos = [3801.55,4266.83,0]; private _wp = grp1 addWaypoint [_sniperPos, 0]; waitUntil {sleep 0.2; ((leader grp1) distance _sniperPos) < 8 }; grp1 setBehaviourStrong "AWARE"; grp1 setSpeedMode "LIMITED"; { _x setUnitPos "DOWN" } forEach (units grp1); systemChat format ["Before formationDirection '%1'", formationDirection (leader grp1)]; waitUntil {sleep 3; ((leader grp1) distance _sniperPos) < 1 }; { sleep 2; //[_x, (_x getDir LIGHTHOUSE)] remoteExec ["setDir"]; //_x setDir (_x getDir LIGHTHOUSE); //[_x, (_x getRelDir LIGHTHOUSE)] remoteExec ["setDir"]; //_x setDir (_x getRelDir LIGHTHOUSE); _x doWatch LIGHTHOUSE; } forEach (units grp1); grp1 setFormation "DIAMOND"; // better than LINE 'cause the spotter doesn't get in the sniper's way most of the time. grp1 setFormDir (getDir (leader grp1)); while { true } do { ["behaviour '%1' / formationDirection '%2' / eyeDirection '%3' / ", behaviour (leader grp1), formationDirection (leader grp1), eyeDirection (leader grp1)] call BIS_fnc_error; sleep 2; }; Demo: https://drive.google.com/file/d/18QGkzuj53y4LwcPvxpYBASMhiQROB76a/view?usp=sharing If you got some more to share, please, keep going!
  13. After your explanation, it became so obvious. Your enlightening answer was greatly appreciated. Basically: use remoteExec only if the LA command will be executed by an object that could have a new owner (e.g. when a vehicle spawned through a server code, and a player ramps in, transferring automatically that vehicle ownership to that specific player machine). Otherwise, regardless if the code is on the server or on the client (player), if the ownership will be always on the same machine, no reason to use removeExec "to transfer a command" for the new owner. More: if we are talking about a simpleObject, there is no reason to apply removeExec to something (in 99,99%) that won't leave its current ownership to another machine ('cause simpleObjects aren't interactive). 😅 So, applying what I've learned here: For those AI units (snipers): _unit setDir (_unit getDir LIGHTHOUSE); // in this case, units wouldn't have issues with collision with rough terrains, so setPosATL not needed. But if the setDir must be applied to a vehicle (perhaps) will be taken by some player for example: [_veh, _veh getDir LIGHTHOUSE] remoteExec ["setDir", _veh]; _veh setPos [getPos _veh # 0, getPos _veh # 1, (getPos _veh # 2) + 1]; // [x,y,z + 1 meter high from the ground] to avoid rough terrain collisions;
  14. A question, @pierremgi About this ["setDir",_veh,_veh], am I saying that the command effect will be addressed only to _veh? What's happen if we leave just one _veh after the "setDir" instead of two? Just for testing purposes, I did it (["setDir",_veh,_veh]) to a simpleObject, and the simpleObject didn't point to the desired direction. 🤨 But removing the "_veh, _veh", the result was the object pointed in the new direction as expected.
  15. Interesting... Even though I never noticed some odd behavior about my goes, I gonna fix it here. Thanks for the head up. 🤗 Actually the vehicle is local for the server because is a AI vehicle BUT sometimes, if zeus is playing, they can take that vehicle controll (but 99% that won't happen). 🧐
  16. Hi @thy_. A message from the future: You were almost there. Works for single and multiplayer: [_unit, _unit getDir LIGHTHOUSE] remoteExec ["setDir"]; It's not smooth anim, but works. If you're using setDir for vehicles, pay attention when the ground (right below where the vehicle would stay) is not flat. To avoid explosions or a rocket vehicle flying in the sky, set a new position for the vehicle before change its direction: _veh setPos [getPos _veh # 0, getPos _veh # 1, (getPos _veh # 2) + 1]; // [x,y,z + 1 meter high from the ground]; [_veh, _veh getDir LIGHTHOUSE] remoteExec ["setDir"]; Cheers.
  17. The script and its information in the main post have been updated! Dec, 1st 2023 | v6.5: Fixed > Sectorizing > Now is forbidden to sectorize the movement "_move_ANY" because it doesn't make sense at all; Fixed > Occupy > When the mission editor hid a building, the group still considered that building as a possible location to occupy; Fixed > Occupy > An error (caused only in v6.0) when the group leader kicked a unit out of the group if the unit was too far from them; Improved > Occupy > Now groups are able to occupy big towers like Military Cargo Towers; Improved > Occupy > If the building is a ruin, and its type is an accepted one, the group when into it will stay in a crouch to units get a lower profile on it; Improved > Occupy > Expanded the amount of forbidden buildings and acceptable ruins based on the Western Sahara DLC map; Improved > Occupy > Expanded the amount of forbidden buildings and acceptable ruins based on Global Mobilization DLC maps; Improved > Occupy > If a building is badly added by the Editor as forbidden and acceptable building at the same time, CSWR in debug mode will point out this; Improved > Watch > Watch logic was totally overhauled, making the watch-destination more feasible and reliable in wild and urban environments; Improved > Watch > Sniper groups can set positions in urban places too as a secondary approach; Improved > Watch > Minimal range to sniper group sets watching position was increased from 100 to 200m; Documentation has been updated. Updated files: fn_CSWR_globalFunctions.sqf fn_CSWR_management.sqf Now, group executing OCCUPY destinations can get in high towers with better distribution positions inside: Group executing OCCUPY, if they select an acceptable ruin/destroyed building, the group will always get in a crouch in this kind of position: Watch destination (specific for sniper groups) is working much better with natural terrains, regardless of whether the map is an official one (and debug mod is a bit more visual for mission editors, showing what position the group has been selected, and the direction of the watched zone, and another arrow showing the watched zone itself):
  18. Context: Empty vehicles at the main base are protected (allowDamage false) and this protection is controlled by a custom pre-compiled server-side function. For each player protection, just another function file is called by execVM in onPlayerRespawn.sqf or initPlayerLocal.sqf. Issue when dedicated server: When the vehicles are parked at the protected main base, the vehicles are unbreakable. Players are immortal. Both are as expected. However, when any player gets a vehicle, immediately the vehicle gets its natural state: breakable, even with the server-side function telling that vehicle to be unbreakable. When the player leaves the vehicle, the vehicle remains (badly) breakable, with the server (at least for a while) not protecting that anymore. Am I right: Reading some posts here, when a player ramps in a vehicle, this object is immediately transferred to the player's machine ownership (client-side). Question: With a simplified example specifically aiming at this matter, how can we manage this vehicle protection when a player is inside the vehicle? And how do we give back to the server the ownership as soon the player leaves the vehicle withing the protected main base range? Script setup: fn_THY_clientSide.sqf (called on onPlayerRespawn.sqf or initPlayerLocal.sqf) fn_THY_serverSide.sqf
  19. @pierremgi, I will check this out. Just a comment: this looked a bit confusing for me. First part you're saying to keep (?) the loop check, and in the second one it's not the way to do it? 😅 fn_THY_clientSide.sqf is being called through onPlayerRespawn.sqf (and other cases via initPlayerLocal.sqf already. I will take some tests and keep you all posted. Thanks for investing time here, boys.
  20. Right... At night I'll check it on a dedicated server: // vehicle inside the protected zone: _obj allowDamage false; // Getting the current crew: private _crew = (crew _obj) select { isPlayer _x && alive _x }; // Checking if some player in veh: if ( count _crew > 0 ) then { // Broadcast the settings for the players' machines: { (group _x) addEventHandler["VehicleAdded", { params ["_group", "_newVehicle"]; _newVehicle allowDamage false}] } forEach _crew; }; Should I broadcast also the EH vehicleRemoved when the player leaves the vehicle or the vehicle is destroyed? (I'm at work, so I'm not thinking deeply about whether makes sense).
  21. Nov, 12th 2023 | v6.0.1 Hotfix > Fixed a typo in "fn_CSWR_globalFunctions.sqf" (line 3587) that was printing out an error specific if only sectorized spawns were dropped on the map, without any non-sectorized ones (Thanks to reporting, VR_NotKilled);
  22. One more basic script for your PvP or TvT missions. 🙃 SD is an Arma 3 script that's a smart protection against damage for players, vehicles, and AI units when they are within pre-defined zones. The protected zones have automatic removal of wrecks and rolled-over vehicles, in addition to small automation relating to the protected zone's integrity. Super-Dome script works both at the server layer and on each player's machine, allowing the editor to turn resources ON and OFF. Creation concept: turn specific game zones into safe places for players, areas proof against their enemies and themselves. How to install / Documentation: https://github.com/aldolammel/Arma-3-Super-Dome-Script/blob/main/_SD_Script_Documentation.pdf What to expect from SD script: No dependencies from mods or other scripts; SD works with two layers: player protection is managed by client-side, meanwhile vehicles and AI units by server-side; NEW! No need to set variables on Eden or anywhere else; Set up to 10 protected zones easily with drag-and-drop Eden markers; Turn ON/OFF the protected zones to cover all vehicles and static-weapons (turrets) inside; Turn ON/OFF the protected zones to cover all AI units inside; Turn ON/OFF the protected zones to cover all players by side; NEW! Support to Eden Respawn Vehicle Module; Auto-removal for wrecks and rolled over vehicles in the zone; IMPROVED! Smart speed limit (to disable the protection and accept hard collisions) and wreck delete when inside the zone; IMPROVED! Debugging: friendly feedback messages; Debugging: automatic errors handling; IMPROVED! Full documentation available. Check the file above on GitHub. Dependencies: None. Download: From Github: https://github.com/aldolammel/Arma-3-Super-Dome-Script From Steam Workshop (missions with no respawn): https://steamcommunity.com/sharedfiles/filedetails/?id=3068011817 From Steam Workshop (missions with respawn): https://steamcommunity.com/sharedfiles/filedetails/?id=3078633743 Missions running it: Tanks & Helicopters Light; - - - - - - - - - - - Changelog: Nov, 11th 2023, v1.5.1: changelog. Known issues: Bug > At dedicated-servers running maps with Eden Vehicle Respawn module working sometimes protected vehicles are not really protected. (WIP) Bug > when Eden Vehicle Respawn Module is working with lot of vehicles, Super-Dome nor that module works fine; Not support vehicle respawn: after the original vehicle blows up, the new copy won't be protected anymore; When a vehicle rolls over 2 or more times inside the protected zone, the anti-rollover system stops working properly (Hot fix soon).
×