stick_hogue

I need expert help from the Arma dev experts here to understand a fundamental behavior difference between hosted/editor and dedi-MP. * Nutshell: ObjectX (not a vehicle, has no brain) was placed in the editor at Position 1. The sole player in the mission starts near Position 1 but is teleported *very far* away (>10km) to Position 999. The player takes action that tells the server to perform a REMOTEEXEC target=0 SETPOSASL command on ObjectX to move it 100m to Position 2. * Expectation: ObjectX should be at Position 2 on both the server and the client. * Actuality: In hosted/editor runs ObjectX is at Position 2 on both the server and the client even when the player is at Position 999, but on dedi-MP ObjectX is at Position 2 only on the server but remains at Position 1 on the client, regardless of what the mission scripting does with information age commands ON THE CLIENT (setTargetAge, Reveal, disabling dynamicsimulation). I've confirmed in dedi-MP that ObjectX on the server has moved to Position 2 by executing a 'localize' command to dump a getpos ObjectX to the server .rpt file. I've confirmed using Debug Console on the client that ObjectX on the client remains at Position 1. * Confusion: Even with the dynamic simulation system disabled entirely this still happens. Since the player is at Position 999 very far away, information age issues are expected, but they should be controlled by setTargetAge and Reveal commands. * My guess: Maybe dedicated servers are by default configured to override a mission's control over information age? I don't see a setting in dedi server .cfg that could change that. What the frakkin frak is going on??? <<edited 5/31: ObjectX has dynamic simulation DISabled, by the way. But I suspect the game is applying dynamic simulation anyway at long distances>> <<edited 5/31, pt2: To be clear, when the player is near ObjectX, sending the command to the server to have the server move ObjectX via that remoteexec call works just fine. But when the player is very far from ObjectX that's when that same process simply does not move ObjectX on the client. (even with dynamic simulation disabled for that object and disabled via enableDynamicSimulationSystem false, even after setting "prop" setDynamicSimulationDistance 60000;. (Also, as an aside, the reason this is an issue is because I'm trying to attach a camera object to ObjectX to use from afar, sort of like a UAV but not a UAV.)>> <<edited 6/2, pt3: Is it possible that static objects are *always* treated on dedicated server similarly to dynamically simulated objects, but separately from the dynamicSimulation system? (I could see it being like that, since normally static objects are always just that, static.) If that's true, it could explain everything I'm seeing. If so, any idea if there's a workaround aside from making a descendant class as a mod and altering whatever property(ies) cause this? <<edited 6/2, pt 4: I'm going to have to conclude that on dedicated server, dynamic simulation is always enabled beyond a certain distance, regardless of mission settings. Dealing with that will require some radical re-thinking of my approach, but I do have some ideas. Admins, you can retire/delete this post if you like.>>

Background: I decided that since Arma 3 is stable now I should try to revamp my StickSub scripting (and remove Nimitz mod dependency using USS Freedom objects instead, and other important improvements). General implementation: The sub is a static object ("Submarine_01_F") instantiated on the server, and controlled by a master loop script. Clients make changes via dialogs which use setvariable commands to change the commanded speed, commanded depth, and commanded heading of the sub. The helm/pilot's dialog includes cameras attached to various positions on the sub, and the NavINT dialog creates a Remote Designator object attached to the sub for use as a periscope. Each client creates 2 local markers in elliptical shape to represent the submarine, and those markers are constantly updated to the position of the sub. The immersion works like this: when you board the sub, you are SETPOSed to the theatrical set off map (USS Freedom interior). When you open your map, it centers on the sub. When you exit the sub, you are SETPOSed back to it. It doesn't take much smoke and mirrors - you immediately feel like this is all real and you're getting on and off the sub like it's a real boat. All that works splendidly with hosted server. I only recently gained local dedi testing capability. Problem: Dedicated server and hosted server behave completely differently in one way: on hosted server, the static object is synched with the clients even if they are far away from it on the theatrical set, and so the markers also correctly move in synch with the location of the sub, and the remote cameras attached to the sub show it moving through the world. But on dedicated server the static object is not synched with clients who are on the theatrical set far away, and so the markers also never move, and the remote cameras show the sub not moving. The moment I exit the sub and am SETPOSed to it, the game updates its position to my client, and so the markers update, too, and the cameras reflect the new position (when I return to the theatrical set and open the helm control dialog), but then they remain frozen in the new position again. What's been tried: EnableSimulationGlobal true EnableDynamicSimulation false SetTargetAge "Actual" Reveal EnableDynamicSimulationSystem false Hell, I even created an AI diver, set it to TriggerDynamicSimulation true, and attached it to the sub, and still the sub is not synched with clients who are far away (although I can see the diver marker on the map). All the setvariable data sent out by the server's control loop is fine, and the setvariable based info in the dialogs correctly reflect its movement, but the object location never updates for clients who are far from it on the theatrical set. My theory: There seems to be an in-built dynamic simulation system for static objects that's independent of the one for 'live' units controlled by the above-listed commands. I've seen comments that seem to confirm this, but nothing substantive. Does anyone know of a way to force a dedicated server to broadcast a static object's data to clients who are far away? Is this just a fundamental game optimization that can't be beaten? thanks in advance, Stick_Hogue

Thanks. I'll go to the editing forums. The point behind my scripts is that they do not require a mod. There's definitely a segment of the Arma population that would prefer to keep mods to a minimum. Plus, there are differences between those mod subs and mine.

Background: I decided that since Arma 3 is stable now I should try to revamp my StickSub scripting (and remove Nimitz mod dependency using USS Freedom objects instead, and other important improvements). General implementation: The sub is a static object ("Submarine_01_F") instantiated on the server, and controlled by a master loop script. Clients make changes via dialogs which use setvariable commands to change the commanded speed, commanded depth, and commanded heading of the sub. The helm/pilot's dialog includes cameras attached to various positions on the sub, and the NavINT dialog creates a Remote Designator object attached to the sub for use as a periscope. Each client creates 2 local markers in elliptical shape to represent the submarine, and those markers are constantly updated to the position of the sub. The immersion works like this: when you board the sub, you are SETPOSed to the theatrical set off map (USS Freedom interior). When you open your map, it centers on the sub. When you exit the sub, you are SETPOSed back to it. It doesn't take much smoke and mirrors - you immediately feel like this is all real and you're getting on and off the sub like it's a real boat. All that works splendidly with hosted server. I only recently gained local dedi testing capability. Problem: Dedicated server and hosted server behave completely differently in one way: on hosted server, the static object is synched with the clients even if they are far away from it on the theatrical set, and so the markers also correctly move in synch with the location of the sub, and the remote cameras attached to the sub show it moving through the world. But on dedicated server the static object is not synched with clients who are on the theatrical set far away, and so the markers also never move, and the remote cameras show the sub not moving. The moment I exit the sub and am SETPOSed to it, the game updates its position to my client, and so the markers update, too, and the cameras reflect the new position (when I return to the theatrical set and open the helm control dialog), but then they remain frozen in the new position again. What's been tried: EnableSimulationGlobal true EnableDynamicSimulation false SetTargetAge "Actual" Reveal EnableDynamicSimulationSystem false Hell, I even created an AI diver, set it to TriggerDynamicSimulation true, and attached it to the sub, and still the sub is not synched with clients who are far away (although I can see the diver marker on the map). All the setvariable data sent out by the server's control loop is fine, and the setvariable based info in the dialogs correctly reflect its movement, but the object location never updates for clients who are far from it on the theatrical set. My theory: There seems to be an in-built dynamic simulation system for static objects that's independent of the one for 'live' units controlled by the above-listed commands. I've seen comments that seem to confirm this, but nothing substantive. Does anyone know of a way to force a dedicated server to broadcast a static object's data to clients who are far away? Is this just a fundamental game optimization that can't be beaten? thanks in advance, Stick_Hogue

Meister Grimes, My guys have a drag script that's very similar to this one, and possibly was based on an earlier version of it. Thanks for that. But they have stopped using it because of a variety of issues that happen in special-but-unfortunately-not-rare-enough circumstances, like if someone disconnects while being dragged, or just getting broken animation states, or breaking TFAR, etc. I'm convinced that the issues have to do with using the attachto command for the drag, because attachto undoubtedly does things to player objects that BIS doesn't protect against in the rest of the game engine (why should they? that'd be a lot of code just to protect against exactly this odd situation). So I've begun experimenting with replacing attachto (and its closeout detach) with something like this: [_target] spawn { params ["_target"]; [_target,player] remoteexec ["disableCollisionWith",0]; while {FAR_isDragging} do { try { if (!isNull _target && alive _target && !isNull player && alive player && ((lifestate player) in ["HEALTHY", "INJURED"])) then { [[_target,player],{ (_this select 0) setposatl ((_this select 1) modeltoworld [0, 1.5, 0.092]); (_this select 0) setdir (getdir (_this select 1)); }] remoteexec ["call",0]; uisleep 0.1; } else { FAR_isDragging = false; }; } catch { FAR_isDragging = false; }; }; }; I'd be curious to know if you've had complaints about problems that you think might be related to attachto in the drag functionality, and whether or not you've ever tried an approach like this. It's really a simple idea: setpos/setdir instead of attachto. Why not? attachto must cause problems with player objects - we've all seen it. Thoughts? Anyone? Anyone? Bueller?

I just had the same problem develop magically overnight on the latest A3 release. On my end it was network protection related. After removing old Arma related exclusions and making brand new ones with TCP and UDP 2302-2303 ports allowed in Windows Firewall and my anti-virus software, it’s working again. My anti-virus software was also apparently downloading an update for itself when this happened, so it may have interfered. Either way, it's probably good to clean out old exclusions and try again, especially if old exclusions didn't specify the allowed ports. good luck, -Stick

I understand. We do what we can. No, thanks, I've already implemented the teleporting. What would really be nice is for the bridges to be destructible, too. I manually did setdamage 1 and they didn't blow up. My goal for the workaround was to only allow the teleporting if all segments of the bridge were still intact, but alas, I couldn't blow up the bridge segments. Best wishes, all.

Ack! I love Isla Duala from my "Limited Assets: Isla Duala" experiences, so I'm trying to make a new mission on it, but AI drivers (even with VCOM running) are coming to a dead stop on the Hazena bridge. I tried using a trigger to jump them past whatever might be stopping them, but it seems like they stop hard anywhere in the middle of the bridge (starting from a position about halfway between the first two pairs of street lamps on the west side of the bridge going east - haven't tried any other configuration yet). I have terrain setting on "high" and the AiA Lite pack. Could it be the Lite version causing this trouble?

I echo this request. My application really would benefit from being able to use camera objects as sources instead of units with MP/JIP support. Thanks for your work (so far) and thanks in advance if you add support for camera objects! Stick **EDIT** That said, using allowdamage, disableAI, hideobject and enablesimulation I'm cheating the system by using units as cameras. This is not ideal because they occupy space, but if it works I'm going with it for now. :)

TrooperWally, BIS_fnc_MP runs a script snippet you define, with whatever parameters you want to pass in. I don't know that it has limitations on which commands work and which don't. I think the idea is that it's just a platform for making sure code is run on all clients. Here's an example. In your init.sqf you define this function: SwitchActionMP = compileFinal " (_this select 0) SwitchAction (_this select 1); "; //parameters for SwitchActionMP are [unittoanimate, animationstring] And you call it like this: ... _Operator = unitwhatever; ... [ [_Operator, ""], "SwitchActionMP" ] call BIS_fnc_MP; //parameters for SwitchActionMP are [unittoanimate, animationstring] unless I misunderstood your request... (watch out for your nested quotation marks in the function definition, of course - and it seems to disallow comments inside those function definitions) -Stick

In hosted MP mode, with the FSF unmoving, I fall right through the platform when walking from the flight deck onto the starboard aft platform. Coming up from the well deck works, just getting onto the stairs platform fails. My workaround is to use a trigger attached to the ship that sends me directly to position "well3R". Here I'm sharing how to do that. Make a 1m radius named trigger set for BLUFOR PRESENT REPEATING, I called mine “trgFSFdescendstairsâ€, and attach it to your FSF with this attach command (I named my FSF “MyFSFâ€): trgFSFdescendstairs attachTo [MyFSF,[8.68,-29.5,-6.7]]; This model position is right at the starboard aft corner of the flight deck near the stairs. Leave the Condition field just “thisâ€, and put the following in the On Activation field of the trigger: {if ( (((getposasl _x) select 2)>7) and (_x==(vehicle _x)) and (abs((asin ((((vectordir _x) select 0))/(sqrt(((((vectordir _x) select 0))^2)+((((vectordir _x) select 1))^2)))))-asin ((-1*((vectordir MyFSF) select 0))/(sqrt(((-1*((vectordir MyFSF) select 0))^2)+((-1*((vectordir MyFSF) select 1))^2)))))<45) ) then {nul = [_x,MyFSF,"well3R"] execVM "\GNT_FSF\position.sqf"; _x setdir (getdir MyFSF);};} foreach thislist The getposasl z>7 makes sure it only triggers if you're on the flight deck, the vehicle check makes sure you're not in a vehicle (if you're concerned about this triggering if you're paradropping into this location, put another z check for <10 as the flight deck elevation is about 8.5, at least for the soldier unit I used for testing). The complicated vectordir stuff is to make sure only those facing the stairs (within 45 degrees of the aft of the ship) will trigger the trigger, so you don’t trigger it when coming up the stairs onto the flight deck (just comparing getdir results versus getdir+180 is problematic because of 0/360 wraparound). Seems to work for me, and I’m liking it! (At first I added an action to the ship, but you can only see the action near the front of the ship, and people might still try to take the stairs, so this seemed like an over all better solution for me.) cheers, Stick

[EDIT] Never mind the below note; as of now it appears to be working... Unfortunately, I've learned that the weaponstate command is problematic at the moment. https://dev-heaven.net/issues/28763 That's really a shame. Are there no other methods of detecting if a weapon safety is on?

Hell, I'd never heard of the SWITCHWEAPON action until Mik and I started working with these scripts. Good stuff drives research to make it perfect. :) Another approach to the F / control F issue might be to require the weapon mode to be SAFE before allowing an attachment switch (even more realistic), then remove the SWITCHWEAPON action. So the user must go to SAFE mode first then must come out of SAFE mode after the operation is complete. I like that idea and intend to implement it, but I only know how to do it using ACE. The condition can have this added to it: and (weaponState player select 2 == "ACE_Safe") and the SWITCHWEAPON action should be removed. enjoy, Stick

It's NOT necessary to rewrite these scripts. The first error you're seeing is because the loadingscreen is not included in that TWAT.Desert sample mission. Don't bother adding a preload manager module, just comment out the loading screen commands (there's an endloadingscreen command at the end of the init.sqf, too). There are other errors which may be related to race conditions or overloading the menuing system - they may be innocuous, I haven't proven that, but I do know they are random. Sometimes it's one weapon (not the one I'm holding), other times it's other weapons. If it's not innocuous and random weapons are broken every time you load, then the solution is to restrict the number of weapons using this TWAT system. Edit the initweapons.sqf to remove the ones you don't need. My buddy Mik and I tailored this only for the M4A1SOC and fixed a couple of issues: 1) you no longer need to press F or control F to get back to firing mode - using the SWITCHWEAPON action fixes that (the chosen index in the was-now code below might be specific to this weapon, but for other weapons you can experiment to find the index that works, and it might always be 1), 2) we removed the restriction on being near a crate, but to represent a delay and prevent you from switching modes essentially between rounds fired, there's a "bandaging" animation that closes with a "kneeling with weapon idle" animation. The bandaging animation actually places the gun on the ground, so it does appear as if you're working on your weapon. If you want a longer animation to force a longer delay, choose a longer animation (http://community.bistudio.com/wiki/ArmA2:_Moves). If you want to do this, edit your fn_menuDef.sqf files (all of them) to include the changes shown below: WAS: ["Add Suppressor",{ player removeweapon "ACE_SOC_M4A1"; player addweapon "ACE_SOC_M4A1_SD_9" },"", "", "", -1, 1, (primaryweapon player == "ACE_SOC_M4A1") && player distance box1 < 10], ["Remove Suppressor",{ player removeweapon "ACE_SOC_M4A1_SD_9"; player addweapon "ACE_SOC_M4A1" },"", "", "", -1, 1, (primaryweapon player == "ACE_SOC_M4A1_SD_9") && player distance box1 < 10] NOW: ["Add Suppressor",{ player removeweapon "ACE_SOC_M4A1"; player playmove "AinvPknlMstpSlayWrflDnon_medic"; player switchmove "aidlpknlmstpslowwrfldnon_idlesteady02"; player addweapon "ACE_SOC_M4A1_SD_9"; player action ["SWITCHWEAPON", player, player, 1] },"", "", "", -1, 1, (primaryweapon player == "ACE_SOC_M4A1") ], ["Remove Suppressor",{ player removeweapon "ACE_SOC_M4A1_SD_9"; player playmove "AinvPknlMstpSlayWrflDnon_medic"; player switchmove "aidlpknlmstpslowwrfldnon_idlesteady02"; player addweapon "ACE_SOC_M4A1"; player action ["SWITCHWEAPON", player, player, 1] },"", "", "", -1, 1, (primaryweapon player == "ACE_SOC_M4A1_SD_9") ] obviously leaving the weapon classes as is (just add the playmove, switchmove and SWITCHWEAPON commands and remove the && player distance box1 < 10 from the condition. Mik reconfigured the options for the M4A1SOC to A) remove the M203 because we would not screw around with adding or removing that in the field and if you want one you can get a weapon that already has an M203, B) remove the CCO because if you have a Holo (which allows for the 4x option) why bother with a CCO?, and C) added an option to have the 4x Holo attachment if there's no suppressor. So you can do long range or close quarters and in long range mode you don't have the suppressor option, and all these are "reasonable" to be changed out in the field, so we think. Having removed the F / control F interruption but adding the animation improves the immersion while preventing instant switching "between rounds fired", and we feel that's better than restricting it to crate proximity (if you're near a crate, just pick a different weapon). many thanks to the source authors, enjoy, Stick

It's been a long time since I messed with this on Limited Assets, but I think I had it working as follows: Passing _name into an onplayerdisconnected.sqf script: _connectedplayername = _this select 0; if (_connectedplayername == (name playerAssault_1)) then { playerAssault_1 setvariable ["lastconnectedplayername", _connectedplayername, true]; }; if (_connectedplayername == (name playerAssault_2)) then { playerAssault_2 setvariable ["lastconnectedplayername", _connectedplayername, true]; }; if (_connectedplayername == (name playerAssault_3)) then { playerAssault_3 setvariable ["lastconnectedplayername", _connectedplayername, true]; }; //etc. for each playable slot I also passed _name into my onplayerdisconnected script and did stuff like this: _disconnectedplayername = _this select 0; if (_disconnectedplayername == (playerAssault_1 getvariable "lastconnectedplayername")) then { _disconnectedunit = playerAssault_1; Assault1teamkilled = false; publicvariable "Assault1teamkilled"; }; if (_disconnectedplayername == (playerAssault_2 getvariable "lastconnectedplayername")) then { _disconnectedunit = playerAssault_2; Assault2teamkilled = false; publicvariable "Assault2teamkilled"; }; //etc. for all playable slots dostop _disconnectedplayername; //etc. (This was back when I was still using publicvariable and transitioning to the "new" setvariable/getvariable commands.) hope this helps, Stick