Ryko

New favourite word!

You're hilarious. That was literally the first thing I thought of when I saw that statement. 🙂 I do like your idea, but I think that particular variable is the wrong place to do this. I would submit that you need a two variables: <group> setVariable ["lambs_disable_AI",true]; - for disabling the routine completely, and <group> setVariable ["lambs_danger_AIprofile","recon"]; - if you had different styles of AI to load into the AI. If the variable isn't set, it's default (of course, "default" could be a setting). Just my two cents, for greater clarity from a user point of view.

Is there a particular reason for the second true statement (which synchronizes the variable across all clients)? Assuming the server is running the FSM, this is just needlessly spreading data across the network. I could see a case for it if the MP session is using a headless client.

Just asking, and your response lets me know that people are still working on it, which is all I wanted to know.

@nkenny I'm looking forward to the release of the next version of this mod; are you nearing that fateful day?

@nkenny have you done any performance testing to see what kind of impact of this additional scripting will have on the server? As well - is your FSM running in addition to the vanilla FSM, or do you somehow disable the original vanilla FSM to run yours? If so - how? Thanks

I would agree with your sentiment. Here's a video however that shows the problem, which occurs regardless of the distance. Two CSAT squad leaders (Katiba with optic, 50% skill), 500m away from me on the Terminal runway on Altis. I fire a few shots initiating danger; the first squad leader has the FSM disabled with this setVariable ['dangerAIEnabled', false];. He will lie down and fire aimed shots at me. The other guy will move slightly, re-engage, and then pop off a shot as he's turning. Because he's moving, his accuracy is terrible. He'll continue to do this until he runs out of ammo. The example video shows his performance at 500m, but I've run it at 200m and closer, and have seen the same results. At closer ranges, he will sometimes fire aimed shots after the first. And if you scale up his skill, he'll achieve more hits, probably because his aim won't be as affected by aim. What I'm getting at with all this is that you might want to balance between BIS' behaviour (where the unit prioritizes the most stable shooting situation before shooting, to guarantee hits) and yours (where the unit prioritizes movement over accuracy), perhaps by adding an additional state where the unit is set to forceSpeed 0 for a short time when they are firing, so while the first shot may go wild, follow-on shots can be a bit more accurate, then return to a movement option.

Comparing your FSM to the vanilla FSM, the vanilla FSM builds in a forceSpeed 0 for 4-8 seconds, presumably, to allow the AI to aim before firing. I haven't fully parsed through your FSM, but I see in CQC assault mode they are made to forceSpeed 3, which will allow them to move and shoot (which I love!) except it probably plummets their accuracy. But what I can't figure out is how a stationary AI (no other mods than yours, by the way) can miss me from around 100m until they run out of ammo. I believe this (though I can't find out the exact dynamics of what gets affected). However your code checks both the current level of enemy suppression and a flat random to your zettings file variable, so you're overriding an enemy's behavior with your own constant. I suppose I could as a mission designer override you by just making that variable (lambs_danger_panic_chance) astronomically high.

I'm really intrigued with this mod. Things I've noticed: 1) The AI is really, really inaccurate. Even at distances of 20m, they will unload on each other and rarely hit; they will only score hits when they have walked right up to each other to practically point blank distance. I figure that this is because the vanilla AI allows the AI to aim until it reaches a certain probability of a hit, and then fire, while the implementation you've introduced perhaps lets the AI shoot well before they have a probability of a hit. I haven't tested this extensively (default units have 0.5 skill?) but raising the skill of a unit to 1 didn't seem to have a practical impact on accuracy. 2) The AI doesn't seem to take into account the weapon they are using. In your last video example, AI: Dylan Faulkner is using an MX with underbarrel grenade launcher, and doesn't think to use it, preferring instead to charge to CQB. I can only imagine what the AI would do if they were equipped with a sniper rifle. 3) The settings (fn_zettings.sqf) file allows you to set the danger_panic_chance, where I feel this should be intrinsically linked to the unit's courage skill. That said, the changes you are bringing to the gameplay are excellent and I would love to see where this mod goes. For mission makers you'd do them a great service by providing toggle variables to allow them to disable any of the custom behaviours you have implemented (panic and AI suppression, for example). Best regards Ryko

You know the vehicles I'm talking about - the HEMTT ammo / fuel / repair truck, the Huron containers, Taru pods, Zamaks, etc... you drive up to it and it just automatically repairs / refuels or rearms you, as is the case. I've searched high and low through the functions and config files, and I can't find the scripting that is making this effect happen. Does anyone know what it is, or where it can be found? Please don't answer with references to your own or other's Rearm / Refuel / Repair scripts, I have a ton of those but that's not what I'm asking - thank you! Why am I looking for this, specifically? 1. Vehicle rearming, with turrets and especially with dynamic loadouts, is especially problematic. I challenge you to reload 13 out of 19 rockets, exactly, on a rocket pod that's not on the vanilla configuration of a dynamic loadout aircraft. The vehicle rearm script on the Huron pod just works, it an cosmetically appealing way: the numbers just increase while you're next to the rearming source, until you're fully reloaded, and it doesn't seem to care whether it's a vanilla loadout or a dynamic one, whether the turret is local or not, etc. 2. There's no way to adjust the "flow rate" of vehicle rearming, repairs, or refueling. 3. The effect itself is capricious. Sometimes it works as intended (drive up to the box/ car/ whatever) and the vehicle resupplies as intended. Sometimes it doesn't, but it provides you with an action (complete with a lovely icon) to perform it. And sometimes it doesn't work at all. Thank you in advance! Ryko

Thanks sarogahtyp, I tried adjusting the flow rate by adding a loop which uses setRepairCargo and the other two functions; essentially setting it all to 0, sleeping, then setting it back to 1, then sleeping again, and this does indeed adjust the flow rate fairly nicely. My problem however is with the other two issues, where the action sometimes does not function reliably.

Hello, I am working on a mission and having some difficulty: some time into the mission, every player who has a zeus slot assigned will find their game crashes with the following: 0xc000005 STATUS_ACCESS_VIOLATION I'm kind of at my wit's end trying to debug this issue, as it makes administering the mission a bit problematic if the admin users are being kicked every 20 minutes or so. The mission begins fine, but as units spawn and the player count rises, the odds of the kick happening increase. The interesting thing is it doesn't isolate some users: it's all users that have a zeus module assigned. My initial approach was the dynamically create zeus modules and assign admin users to them, but then I went back to a standard pre-placed module approach, with UIDs as the assignment, to see if that was the issue. Both methods produce the same results. In the .rpt, we get the following: 2018/12/19, 21:11:01 Client Username - client's ticket has become invalid. Code: 6 2018/12/19, 21:11:01 NetServer: cannot find channel #264769362, users.card=45 2018/12/19, 21:11:01 Message not sent - error 0, message ID = ffffffff, to 264769362 (Username) and that happens every second until every Zeus user has crashed. I've tried to be very efficient in the coding of the mission, but there are some loops that run for various reasons. I've used diag_tickTime to clock how some of the longer scripts are performing, and nothing goes over 0.52ms... there were probably around 300 units running in the mission at the time. Any ideas, or suggestions of what to check? I'm at a loss. - Ryko

Thanks, Larrow. Adding the following allowed edit functionality to work properly: _curatorModule setVariable ["owner", str _owner, true]; _curatorModule setVariable ["curatorUnitOwner", str _owner];

Hi folks, I'm trying to get away from editor-placed zeus modules, and I've got everything working except editing units. With the following code, a connected player is assigned a curator module that's dynamically created, and can create/delete/move/issue waypoints to spawned units: but double-clicking on the unit does not produce the editing dialog. What am I missing? curatorGroup = createGroup sideLogic; addMissionEventHandler ["PlayerConnected", { params ["_id", "_uid", "_name", "_jip", "_owner"]; _player = (allPlayers select {owner _x == _owner}) select 0; private _curatorModule = curatorGroup createunit ["ModuleCurator_F", [0, 90, 90], [], 0.5, "NONE"]; _player assignCurator _curatorModule; _player setVariable ['curatorModule', _curatorModule]; }]; (My code is a bit more elaborate than this, but this stripped-down version produces the same results.) Thanks, Ryko

Thanks for the responses. As stated, everything works (moving, adding, deleting, assigning waypoints) but double clicking does not produce the edit dialog.

following up: I think I've gotten around it by adding code from the fn_moduleCurator.sqf function in the curator addon: _curatorModule addeventhandler ["curatorObjectDoubleClicked",{(_this select 1) call bis_fnc_showCuratorAttributes;}]; _curatorModule addeventhandler ["curatorGroupDoubleClicked",{(_this select 1) call bis_fnc_showCuratorAttributes;}]; _curatorModule addeventhandler ["curatorWaypointDoubleClicked",{(_this select 1) call bis_fnc_showCuratorAttributes;}]; _curatorModule addeventhandler ["curatorMarkerDoubleClicked",{(_this select 1) call bis_fnc_showCuratorAttributes;}]; Though strictly speaking, I don't think this should be necessary. Edit: works in local multiplayer, but doesn't on dedicated server.

Try using #include "\adminpass.txt"; That said, if every client does not have this file on their computer in the root directory for arma, your mission will crash. Every arma installation has arma3_readme.txt, which you can edit to include whichever data you wish on the server, and the connected players will include harmless text.

What is this evaluating? I don't think your setVectorUp etc commands will every be run in this setup.

Hi there, been getting this error since installing this F-16 mod: Cheers -R

Hello all, I've been playing on the Ahoyworld EU3 modded server, and it sounds a lot like what you're looking for: http://www.ahoyworld.co.uk/ There are typically around 10-20 people on at any given time during UK's evenings (and USA's afternoon), and regular game nights are typically scheduled over the weekend. They run several I&A servers with vanilla Arma, but also a modded EU3 server (it's around 15GB of mods, so buckle up) with a custom game mode called Gauntlet which spawns missions on the various maps. It's a good group of people, with the aim of fun but serious game play. -Ryko