Jump to content

stick_hogue

Member
  • Content count

    24
  • Joined

  • Last visited

  • Medals

Community Reputation

10 Good

2 Followers

About stick_hogue

  • Rank
    Private First Class
  1. 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
  2. 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.
  3. 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
  4. Grimes Simple Revive Script

    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?
  5. Role Selection Screen is blank.

    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
  6. [IceBreakr/IBIS] Isla Duala for A3

    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.
  7. [IceBreakr/IBIS] Isla Duala for A3

    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?
  8. Live feed control (LFC)

    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. :)
  9. Live feed control (LFC)

    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
  10. 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
  11. [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?
  12. 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
  13. 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
  14. 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
  15. Latest Beta Patch: 72107

    Let my map sit unattended overnight in HOSTED mode. When I returned the game had crashed with this error shortly after the onplayerconnected had fired: Exception code: C0000005 ACCESS_VIOLATION at 0059D1E2 graphics: D3D9, Device: ATI Radeon HD 5800 Series, Driver:aticfx32.dll 8.17.10.24 resolution: 1600x1200x32 Addons: <long list of loaded stuff omitted> Mods: ca;expansion;Expansion\beta;Expansion\beta\Expansion;dua Distribution: 1485 Version 1.52.72107 Fault address: 0059D1E2 01:0019C1E2 C:\Program Files\Bohemia Interactive\ArmA 2\Expansion\beta\arma2oa.exe file: co@13_LAID_OAv2_2 (__cur_mp) world: isladuala Prev. code bytes: 87 94 05 00 00 6B F6 24 8B 74 30 0C 85 F6 74 DB Fault code bytes: 83 BE E8 02 00 00 00 7E D2 8B 86 E4 02 00 00 8B Registers: EAX:1E48A800 EBX:2C3B1000 ECX:2C3B1578 EDX:00000007 ESI:66664565 EDI:2C3B1000 CS:EIP:0023:0059D1E2 SS:ESP:002B:017DF690 EBP:017DF7DC DS:002B ES:002B FS:0053 GS:002B Flags:00010206 ======================================================= None of my code has ever crashed the game with a graphics error like this, so I wonder if it's possible for a client player with a custom face or other such tweaks to crash a hosted server. DXDIAG reported system info: Operating System: Windows 7 Home Premium 64-bit (6.1, Build 7600) Language: English (Regional Setting: English) BIOS: BIOS Date: 07/15/09 10:09:10 Ver: 08.00.15 Processor: Intel® Core i7 CPU 920 @ 2.67GHz (8 CPUs), ~2.7GHz Memory: 6144MB RAM Available OS Memory: 6136MB RAM Page File: 1870MB used, 10397MB available DirectX Version: DirectX 11 User DPI Setting: Using System DPI System DPI Setting: 96 DPI (100 percent) DWM DPI Scaling: Disabled Card name: ATI Radeon HD 5800 Series Chip type: ATI display adapter (0x6898) DAC type: Internal DAC(400MHz) Display Memory: 3824 MB Dedicated Memory: 1012 MB Shared Memory: 2811 MB Current Mode: 1600 x 1200 (32 bit) (60Hz) Driver Name: aticfx64.dll,aticfx64.dll,aticfx64.dll,aticfx32,aticfx32,aticfx32,atiumd64.dll,atidxx64.dll,atidxx64.dll,atiumdag,atidxx32,atidxx32,atiumdva,atiumd6a.cap,atitmm64.dll Driver File Version: 8.17.0010.0024 (English) Driver Version: 8.732.0.0 DDI Version: 10.1 Driver Model: WDDM 1.1 Driver Attributes: Final Retail Driver Date/Size: 5/4/2010 20:18:36, 584704 bytes Driver Strong Name: oem17.inf:ATI.Mfg.NTamd64.6.1:ati2mtag_Evergreen:8.732.0.0:pci\ven_1002&dev_6898 Video Accel: ModeMPEG2_A ModeMPEG2_C DDraw Status: Enabled D3D Status: Enabled AGP Status: Enabled
×