Wolfenswan

Our group uses a script-based system to set the AI skill values, as it is easier to tune for our mission makers and can be changed by parameter depending on number of players. To my knowledge ASR_AI3 overrides all script-set skills. I was hoping that we could still use the other features of the module that aren't related to the skill settings.

Are all settings within sysAISKill scope ignored if enabled is set to 0 or does it only affect the setting of the AI skill values? In other words would dynamic view distance and wounding coefficient (etc.) still apply when enabled is 0 ?

Searched the thread, couldn't find this reported before so: Got an error message for the indoor sound of the autonomous static HMG being missing. AAF version if that should matter.

Is it possible to whitelist only specific .pbos included? I might be mistaken but would using the included .bisigns to create key-files be enough?

Xmedsys is an addon right? If you don't enable F3's wounding system then there shouldn't be any conflicts.

Does it still do this if ASR_AI skill settings are disabled? And if someone could just very quickly sum up how to correctly setup TPWCAS on a HC it would be appreciated. Do I only need to install the mod in the HC's directory, settings identical to dedi and run it with whatever the setting for "HC mode" is? The dedicated server is running the "dedi only" mode, no clients are running TPWCAS. And a third question: Is there a point in enabling TPWCAS's search cover functionality if ASR_AI3 is running?

Hey, I just realized that the groupMarker page on the wiki is indeed lacking a "adding custom groups" entry. I'll fix that when I get around to it. For now, adding a group just means adding another line like ["GrpNATO_ASL", 0, "ASL", "ColorRed"] spawn f_fnc_localGroupMarker; In your example that would be ["INFGRP1", 1, "What the marker text will show", "ColorRed"] spawn f_fnc_localGroupMarker; This has to be added in the correct faction scope ofc. The number refers to the shape of the marker. You can see which refers to what on the wiki page.

The latter. To remove the Medic markers, just remove the lines in the groupMarker script where it refers to a specific unit, such as ["UnitNATO_CO_M", 0, "COM", "ColorBlack"] spawn f_fnc_localSpecialistMarker; This is somewhat tricky as the groupMarker component is made with only one group per marker in mind. You could only run it for the first group but then it would obviously stop working once that group is dead. Have you had a look at the in-game modules for displaying ORBATs? Maybe they are closer to what you want to achieve. The forum's cool, I tend to check it every few days. I'm also active in the armadev sub-reddit if you use that. @Nefiron: An easy way to do this would be to add a new variable containg the rifle classes _rifleRandom = ["rifle1","rifle2"]; and then at every instance where a unittype uses _rifle class replace _unit addWeapon _rifle; with _unit addWeapon (_rifleRandom call BIS_fnc_selectRandom); This assumes they all use the same magazines. If magazines differ it's doable too though.

Use -showScriptErrors and try removing/commenting the common local variables script. If you don't get any complaints about variables missing you should be good. I'm not sure I understand what you mean. Do you want weapon selection to work like uniform selection? So _rifle would be an array?

Hey phant, f_fnc_setGroupID is defined in the part from description.ext you've quoted. You can read more about the function library here. In a nutshell it looks for a file in the given path "scripts/f/setGroupID", named as set in the class below (setGroupID{}) and prefixed with a fn_; in this case for fn_setGroupID.sqf. This is then compiled as f_fnc_setGroupID. So if you've moved the file to let's say "framework/myGroupIDs/fn_setGroupID.sqf" then your description.ext part should look like If you keep the default folder structure then the group IDs work out-of-the-box with the pre-placed groups and how to add custom groups is explained in the wiki. But feel free to suggest an addendum or explain where it's lacking. Thanks for the feedback.

The important question is: Will this work with L_ES? I know from my own experience that the sound of a person standing in a valley shouting "POW" is completely different from what the same person sounds like when shouting over a flat plane or against a wall and it's really important for immersion imho.

It's rather easy to do, at the top you'd just replace the "faction player" with "side player" and check for the side instead of the faction further down. But you can also add/replace custom factions easily. If you're ingame just slot as a unit of said faction and put "faction player" in one of the monitor fields of the debug console. You can then use this in briefing/assignGear scripts. Check the FIA lines for an example on how to give multiple factions the same briefing/gear. If you want I can post proper code examples once I get home. A general note on simple wounding system: Please let us know if you're using the new wounding system and any issues you encounter, as well as general feedback. We've tested it as extensively as we're able to and don't know of any outstanding bugs. But as with all brand new features unforeseen things can happen, especially with the multitude of various configurations that exist for Arma. One thing we know of that might cause possible issues is heavy desync on client-side at mission start. To prevent this tripping up SWS you can increase the initial sleep in line 39 in f/simplewoundingsystem/init.sqf

Are you refering to the Group Markers that indicate the group location (like "A1" etc.) or the markers for the fireteam units (the little triangles)? The latter should work by default but the coloring won't due to code restrictions. A fix/improvement that'll let you set the colors more easily is in the pipeline but probably only for the release after the next one. For now, open f\common\f_setTeamColours.sqf and remove the line where it checks if the fire team is bigger than 4. If you can't find I can dig up the exact line for you, just not at my PC atm. Edit: Just saw your Edit. I'll leave this standing here in case as it might come up anyway.

Hey CaptainGalaxy, there shouldn't be a case "AAF": anywhere in that file, as aaf is not a correct faction designation and it should be case "ind_f": That aside, replacing the faction name is the correct method. I don't know the addon you're using but the easiest way to find out the faction you need is to launch a quick mission with the player as a unit of the faction and put faction player in the debug console. If you have the correction faction but it still doesn't work, make sure you've assigned the correct group names as well. To help trouble-shooting you can also but this at the bottom of folk_setLocalGroupMarkers.sqf: ["UnitAAF_CSL_M", 0, "CM", "ColorBlack"] spawn f_fnc_localSpecialistMarker; }; [color="#000080"]default {player globalchat format ["%1 is not defined!",_unitfaction]};[/color] }; It'll display an error message should you're using a wrong faction. Not that you need to put the blue parts between the last two }; and not at the total end of the file. Let me know if that helps.

Hey goldenfiver, Is AI enabled on those slots? The gear script should run when units are initialized, so if the AI is present they should get the adequate gear. However due to some quirks in A3 is is currently run only on the server (or the host in a non-dedicated environment) which explains your issue. We're still trying to figure out a good way to solve this. This is experimental, but try replacing the usual gear stuff with this in the unit init: [["r",this],"f_fnc_folk_assignGear",false] call BIS_fnc_MP; "r" is the gear obviously. If that doesn't work try replacing the false with true.

Very nice tutorial Terox. Another page you might want to link is Arma3 Assets in the Biki? Scripting commands by functionality can also be useful sometimes.

Had the exact same issue, removing workshop content fixed it. Wish I had seen this thread before I tried literally everything else :D

Steam just started a ~700MB download for A3 stable. I assume it's the update.

I haven't gotten around to get a full look at the issue yet, but replacing nul = [_loadout,player] execVM "f\common\fn_folk_assignGear.sqf"; with [_loadout,player] call f_fnc_folk_assignGear; in line 47 of f_JIP_reinforcementOptions.sqf should fix the gear selection.

I might be mistaken, but I think that is the Coop loading (and everything to the left is idle state, then adversarial). Bit hard to judge, as ASM doesn't have any timestamps or a scale ( ;) ).

We ran our first successful 35+ players session yesterday without any hick-ups and constantly high server (40+) FPS. 1.10 stable seems to be a vast improvement. Links lead to screenshots of bandwith/FPS graphs. 36 Player adversarial, no AI. 37 Player coop, 186 AI (all present at start), using global caching (hideObject and disabling Simulation). Same Coop further in (players dropped) The minimal FPS (grey) are somewhat weird, but might be due to the (un)caching of groups. It's safe to assume that even without caching missions with <100 AI should be playable with those player counts. A headless client does not appear a necessity but might be worth investigating for higher player counts. Client FPS was not massively affected by caching as there was no Fog present and thus GPU provided the bottleneck for most ppl. However, in single testings before it became clear that even with light fog caching can provide a significant FPS boost (up to 10) as the GPU stops bottlenecking the system and the CPU is relieved. This is the caching solution I used in the missions. This was the COOP played. Server CPU: xeon e3-1245v2 @ 3.4ghz Server.cfg:

Care to elaborate?

The guide contains some outdated information though, essence is still true however. Anyway as you're writing for A3 you can save yourself A LOT of headaches with bis_fnc_MP as well as the expanded functionality of the function library. (Instead of using publicVariables and publicVariableEventhandlers for ugly workarounds). Locality can still be a PITA, depending on how complex your scripting is. I'd also suggest to not consider JIP-compatibility unless you absolutely have to.

Nice addon. Btw. If you replace the check _key == 37 with _key == (actionKeys "Compass" select 0) it will be whatever the user has the compass bound to.

You can't modify the cfgAISkill entries inside/during a mission (which is what the addon does). Using the debug console you can setSkill individual units however.