diwako

Script updated to v1.9.1. You can consider this a hotfix! So far the anomalies were not fully MP compatible which caused anomalies like the electra to not work proberly! That was because I did not fully read the command documentation and missed that some trigger commands are local only. This is now corrected! Changelog: -HOTFIX: Added mp compatibility for triggers -Teleport flash effect now uses "setAperture" instead of a ppEffect As usual download at GitHub and later at armaholic https://github.com/diwako/stalker_anomalies

Pushed an update to version 1.1 -Moved script compilation from initPlayerLocal.sqf to init.sqf -Added signal jamming script (see init.sqf for example and "radio frequencies and power.txt" for defaul radio information) -added a txt file for default radio frequency and power information I noticed, especially in the group I am playing with, that people people are excited for radio jamming in missions, but either lack skill or motivation to write their own jamming towers, so I am going to introduce a way to add jammers and still have signal boosting available. New script: Radio jammer Attaches a zone which jams comms to an object. Script has to be called from server! The jammer can be disabled by either killing/destroying the object that is supposed to jam radios or by setting the variable "jammer_active" at the trigger to false. The the jammer will have an effective area and a falloff area. Everyone inside the effective area is under full effect of the radio jamming. Everyone in the falloff area is affected to some extend. Here some illustration to make it hopefully clearer The jammer will have a set sending power and a set of given frequencies which will be affected. Which means it will be possible to block certain channels for certain radios if the mission maker desires. E.g.mission maker can set it up that only LRR channels are affected and others not. This also means it is possible to just block channel 1 for the PRC-343, but channel 2 is completely fine. The next thing is sending power. If a radio has more power then the tower, the radio will get a hit in sending range, but will still transmit and people will be able to hear it. Setting the jamming power way higher then any radio can send just means the falloff area will be way harsher! Signals sent from within a jamming area are already weakened, so if you are standing inside the same or another jamming area the signals will be weakened even further! That means people standing outside the jamming area will have an easier time hearing someone else then people standing inside the area. Script example /* // example for setting up a radio jammer zone // Params: // 1: object which is jamming // 2: Jamming strength in mW // 3: Array of frequencies jammed, Array in array possible, notation is [start frequency, end frequency] // 4: Effective zone, distance to jammer which fully applies the full jamming strength // 5: Falloff zone, zone in which units are still affected, but the strengths gets linear worse of the jammer */ private _trigger = [antenna, 5000, [[0,9000],9002], 50, 10] call diw_acre_fnc_createRadioJammer; Download: https://github.com/diwako/ACRE2-Custom-Signal-Calculation

Small update. Gibs now have collision with the world geometry and detector beep speeds are now more accurate but the function is now a little bit more expensive. Video of updated gib effect https://streamable.com/6gwdl Script updated to v1.9 Changelog: -Gib effect has now surface collision -Detector beep speed is now more accurate As usual download at GitHub and later at armaholic https://github.com/diwako/stalker_anomalies

Arma vanilla uses .wss files, so every time you see a path without any file ending you can slap a ".wss" behind it. It also is possible to go into config viewer and copy paste the sound path from the sound you want and then edit it with the @a3 annotation.

Here a video of it in action

Just updated the scripts a bit. I added support for Air vehicles and anything that is based on class "Man". Now helicopters and dogs/monsters should not just instantly vanish if they walk into an anomaly. Script updated to v1.8 Changelog: -Added support for air vehicles and objects based on class "Man" Download: https://github.com/diwako/stalker_anomalies

Yep, the mission included has two examples. One for jamming the other for boosting signals. You do not really need to "activate" the script besides running it from the initPlayerLocal.sqf, you are just setting a variable to a unit and it will work. You just need to keep in mind that the variable has to be set globally, that is why the "true" is at the end of every setVariable.

Seems it was too tired yesterday and actually forgot to include the link to the github page. Woops, it is added now.

Sadly no. I am using the BI command "setunconcious" to ragdoll units. That command will automatically put the unit into a revive animation after ragdolling. I am just overwriting the animation so it uses the ace one. As of now there is no reliable command or workaround to activate and deactivate ragdolling on units for any amount of time.

I just edited the OP as the group I am in was running this script now for 3 weeks without problems at 40+ players. So I removed the known bugs as these seems to be resolved. I also added a license for the script, pretty sure who ever runs ace on their server has no problem with it as well. The script had no update so far, so no need to update the script on your end.

Oh yeah, I forgot that part. It should be "_this" instead. I take it you execute the sqf with something like [0,0,0] execvm "script.sqf"? Then using "_this" would be correct. _this is basically whatever you give into the script. It could be anything thus knowing how you execute the code is kind of important.

Do not use "this" as variable to write to. Change that anything else really. The light you are creating is there for everyone as it was created with createVehicle and not createVehicleLocal. The next step is to set the right brightness and color. The commands you are using are the correct ones, BUT those are sadly local only. So only the machine that ran these commands will have the changes. What you can do is to remote exec those commands so everyone sees them. _light = "#lightpoint" createVehicle position this; [_light,0.015] remoteExec ["setLightBrightness",0,_light]; [_light,[0, 0, 255]] remoteExec ["setLightColor",0,_light]; [_light,[0, 0, 255]] remoteExec ["setLightAmbient",0,_light]; You will also add jip support as well well, as the command will run on any new client connection as long "_light" is still present and not deleted. But since you are creating the light with a logic object you want this to be local to all, that means your code needs some small changes. _light = "#lightpoint" createVehicleLocal position this; _light setLightBrightness 0.015; _light setLightColor [0, 0, 255]; _light setLightAmbient [0, 0, 255]; When you place a logic object and execute code through it, it will automatically execute on all machine connecting, so if you leave it as global there will be a new light for the server and every client connecting to it, even reconnecting clients will spawn yet another one.

A few things, _intelPool is only available when you apply the eventhandler, thus it is unavailable inside the eventhandler. Second "killer" is not really a variable like this, it is passed as an argument inside the "_this" object. I do believe you also wanted the killed unit and not the unit that killed them. _unit addEventHandler ["killed", { params["_unit","_killer","_instigator","_useEffects"]; _intelPool = ["Land_Wallet_01_F","EvPhoto","EvMoney","EvMap","EvKobalt","EvMoscow","EvDogTags","Intel_File2_F","Leaflet_05_Old_F","Leaflet_05_New_F","Leaflet_05_F","Land_Camera_01_F","Land_HandyCam_F","Land_Laptop_F","Land_MobilePhone_smart_F","Land_MobilePhone_old_F","Land_PortableLongRangeRadio_F","Land_SatellitePhone_F","Land_Tablet_01_F"]; // Get position of the killed unit _position = position _unit; // Create intelligence at the position of the unit _intel = selectRandom _intelPool; _spawnIntel = createVehicle [_intel, _position, [], 0, "NONE"]; // Execute script on intel _spawnIntel execVM "scripts\hm_hardIntel\hm_checkIntel.sqf"; }];

Second bug is addressed in reapplying the ace animation after 5 seconds. I left that note in as I could not test with my group so far. It only seems to happen only sometimes as well, so it is really hard to track down. So far that happened only once every mission we played with the script, but it was always in different situations. And that is with 25 to 40 players. I personally cannot recreate it at all, neither on a local dedicated server or in SP, it just tells me it is a sync/locality issue.

Pushed a small update after I got the use case that anomalies needed to be spawned in buildings and in the air. Script updated to v1.7 Changelog: -Anomalies can now be spawned in the air (useful to spawn them in buildings) -Switched from addAction to CBAs persisten player actions, which means CBA will handle readding the actino to players after resapawn The create functions do now consider the third number in the position array, thus spawning in the air is now possible. Keep in mind it uses setPosATL that is above ground level and not sea level! Download: https://github.com/diwako/stalker_anomalies

The group I play with only plays on their dedicated server, the bugs that I've posted in the OP are from the play sessions there. I already did several test sessions and applied some fixes before posting it here, so the third listed bug did not occur at all any more, but I will still leave listed as bug as you never know.

Certainly possible. All it needs it to add a CBA Class Eventhandler for class "CAManBase" instead of the player. Actually I added that to the file "initPlayerLocal-EnableForEveryThing.sqf" now. So people can interchange them if they want to.

That is just the definition of which functions are allowed to be remotely executed. Of course they need to be added there as well, but the cfgfunctions entry is needed otherwise those function will not even exist.

You are missing this in your description.ext class CfgFunctions { createShortcuts = 1; #include "scripts\funcs.hpp" };

Can you send me the mission in a PM so I can take a look at it? It sounds to me that the functions are not compiled when the missions starts.

What is the error message? Have you enabled debug mode to see where the anomalies are being spawned?

Correct that should work. I meant it because "player" is not available on a dedicated server.

Make sure you include funcs.hpp in your CfgFunctions in description.ext. Otherwise all the functions are undefined. initServer is best. Tho you should replace "getpos player" obviously ;)

Turns out I got sidetracked hard. Tho I managed to update the scripts a bit. Script updated to v1.6 Changelog: -Added function to create a randomized anomaly field. (it uses CBA_fnc_randPosArea as its core, so read up on their documentation) -Added Debug variable which will create markers where anomalies have been created if it is set to true -Added light when a burner anomaly has been activated -Fixed delete function not deleting everything -Hopefully fixed electra anomaly effects bug Media: Usage of new function: The new function is "anomaly_fnc_createAnomalyField". Which will take up to 5 arguments. _posParams - array containing parameters for the location function _springboard - how many anomalies of the type springboard should be created (default: 0) _burner - how many anomalies of the type burner should be created (default: 0) _electra - how many anomalies of the type electra should be created (default: 0) _meatgrinder - how many anomalies of the type meatgrinder should be created (default: 0) The function will return all newly created anomalies in an array. Example: [[getpos player, 50, 50, 0, false],5,5,5,5] call anomaly_fnc_createAnomalyField; Download: https://github.com/diwako/stalker_anomalies

Hey, sorry for disappearing for a bit. As I mentioned some weeks before I was going to be away for a bit. Now I am back home and can work on this again. That said, I am taking a look once I find the time.