Jump to content

Wolfenswan

Member
  • Content Count

    212
  • Joined

  • Last visited

  • Medals

Posts posted by Wolfenswan


  1. I don't know if this happened to anybody else but i'm having problems often with the Simple Revive System.

    Basically what happens is that the player gets hit and is wounded, then when another player tries to treat him, the revive just doesn't work and the wounded player remains in a state of constant wounded-ness ( ).

    No matter how many first aid kits we throw at him there's no way to revive him.

    Hm. No, that's how it's supposed to work and how it's working fine for us. Are you running any mods or scripts which might be interfering?

    Also, from time to time the PreMount Component bugs on our dedicated server.

    It doesn't seem to work correctly with the vehicles that now have Firing From Vehicle slots.

    I tested this with the Assault boat, in the editor the units are moved correctly in all the slots.

    On dedi only the drivers are spawned correctly on boats, all other slots are left empty.

    Odd. We tested it with the new FFV vehicles and it worked fine, but the new "cargo-turrets" will only be slotted if the "crew"-flag is set to true.

    However, if it works locally but not on dedicated then the issue might be something else, are you moving player units or AI into the boat?


  2. I've thought it was straightforward, but I can't make it work, in fact. Could you, please, provide some instructions how to set it up separately from framework?

    You need the f/spect folder and the relevant sections from the description.ext (cfgFunctions and spawn-templates). It's probably easier if you describe what you did and how you set it up so I can point out the mistake. You can also take a look at this mission, the creator is using an extracted version from F3 as well.


  3. Your spectator script looks interesting. How about releasing it as standalone script for the community? It may be useful for mission makers who don't need the whole framework functionality.

    It's pretty straightforward to extract the spectator script from the framework and use alone (no inner dependencies) and for us it's better to focus on developing the framework as a whole rather than having to maintain several sub-releases besides F3 itself.


  4. Hehe all good mate, any help is appreciated. Will look into it, but i should have mentioned that we are an online coop clan meaning friendly AI are never used. Will see if it has what im lookin for. Cheers

    I wrote a few functions to get AI into buildings for our sessions, they are part of my library (under /AI/). I wrote those with perfomance in mind, so the AI won't necessarily face out of windows or react dynamically (ASR_AI3 does usually take care of that well enough). If you need something like that have a look at Zorilya's script.


  5. Another funny thing, even after running setskill everywhere, skillfinal gives a lower skill on server than on local machine:

    global exec setskill ["general", 0.2] => skillfinal 0.44 on server, 0.6 on pc

    global exec setskill ["general", 1] => skillfinal 0.94 on server, 1 on pc

    The difference stays the same with or without equal profile settings server vs. client and regardless of having ASR AI3 running on client or not (so it's not about cfgaiskill interpolation).

    A tracker-ticket exists.

    And I can confirm that it has nothing to do with ASR_AI3 or any script-set skillsets. The return values for skill are always identical and what you'd expect them to be. For the time being I've set this in our server.cfg:

           skillAI=1;
           precisionAI=0.3;
    

    which produces results at least similar to what one would expect. But ofc. it doesn't help with the issue if AI is local to a client and the client has set up some sort of über-AI.


  6. Why did you put everything into the call compile, and why do you assign _grpName a variable to then overwrite it with a newly created group? Does the created group keep the designation as _grpName?

    _grpName = call compile format [%1,_compStr];
    _grpName = createGroup (side player);
    [player] joinSilent _grpName;
    _grpName setGroupID [_compStr];
    [[[_grpName,_compStr],{(_this select 0) setGroupID (_this select 1) }],'BIS_fnc_spawn',true] call BIS_fnc_mp;
    

    Though your BIS_fnc_MP parameter should work as well if it is able to distinguish between multiple parameters when a script command instead of function was passed (would be good to know, honestly).


  7. How does BTC revive work? Does it create new units for the dead ones?

    I don't see a reason why you wouldn't count the playableUnits array?

    Also, instead of the two waitUntils you should use a trigger or at least add some sleeps into the waitUntil checks. Otherwise it's wasteful and waitUntils have the nasty habit of carrying over.

    You could also consolidate those checks into a single one: If either the players win the mission or all die a global variable (let's call it missionOver) flips to true, a trigger registers this change and then shows the correct ending screen, depending on whether > 0 players are still alive.


  8. In some vehicles, such as the newly added Huron or the Ghosthawk, the crew has access to a GPS and map when in specific slots, even if they don't have either in their inventory. This includes the "fire from vehicle" turrets, no matter if they are disabled or not. Is there a way to disable this feature?


  9. That should do it. You only need to worry about asr_ai3_sysdanger_{debug,radionet,radiorange,seekc over,throwsmoke,reactions,usebuildings} variables because everything from sysaiskill is server side.

    To clarify: Would units created by a ZEUS player use the client's sysdanger values but the server's sysaiskill values? In any case I'd like to suggest a new variable to enable the server overriding all client values at mission start as a feature.

    OK now I'm worried. I have a garrison script aswell, and I need the units to stay inside. I can't confirm if they are getting dragged outside, but I use the same method Wolfenswan is using, so I'm guessing they are going to leave their garrison too. That would be a show stopper for me. Could you implement some way to exclude some groups from whatever it is that is forcing garrison units to leave their positions?

    It's pretty easy to test locally, just garrison a town and place a few hostile AI with allowDamage false and FSM disabled in the center. This is enough to trigger the scripted attack response which seems to cause them to leave position. You can also try making everyone invulnerable and engage each other to see the same happening with the scripted defense response.

    A straightforward workaround my group is employing curently is to have the host set asr_ai3_sysaiskill_reactions to [0,0,0] in missions reliant on garrisons using the debug console.

    If you don't notice your garrison leaving despite reactions enabled I wouldn't mind if I could have a look at your code to see if I can implement it on my end.


  10. If you are testing it locally then the script will exit because isServer is true and you do have an interface.

    Try commenting the very first line for testing purposes.

    Beekan's code looks solid otherwise but if you're completely out of luck try mine. However, it's more general, as it affects all units in the mission minus player units.

    {
      private ["_unit"];
         _unit = _x;
    
         // Only run where the unit is local, it isn't a player and doesn't have a flashlight
         if (local _unit && !isplayer _unit && !("acc_flashlight" in primaryWeaponItems _unit)) then {
    
         // Remove laser if equipped
         if ("acc_pointer_IR" in primaryWeaponItems _unit) then {_x removePrimaryWeaponItem "acc_pointer_IR"};
         _unit addPrimaryWeaponItem "acc_flashlight";   // Add flashlight
    
         // Removes NVGs from unit
         	 {
               if (_x in assigneditems _unit) exitWith {_unit unlinkItem _x};
            } forEach ["NVGoggles_OPFOR","NVGoggles_INDEP","NVGoggles"];
         };
    
    	      // Forces flashlights on
    	       // _unit enablegunlights "forceOn";
    } forEach allUnits;


  11. I assume stopped would apply to doStop as well, but might also fire when stop/doStop commands are used from the FSM?

    Personally I'd be happy enough if I could set a variable on individual units or their group to exclude them from being affected by specific ASR_AI3 components.

    Unrelated to the issue at hand:

    Is there a good way to override a client's ASR_AI3 settings with those the dedicated server is using? This is mostly relevant for missions using ZEUS where the curator is (hopefully) using ASR_AI3 but might have different settings in place. Would collecting the ASR_AI-generated global variables on the server and making them public do the trick?

    Edit:

    I did some limited local tests and it seems that reactions[] is indeed the culprit. A setting of {0,0,0} does not cause the AI to leave their positions but enabling any single value does.


  12. There were always checks in place for uncompleted waypoints and that hasn't changed. I'm guessing it might be another mod doing that. You can of course disable reactions in userconfig - set them to {0,0,0} to completely disable any code that might assign AI new waypoints. You may also try disabling moving into cover and see if that changes anything. Let me know if you figure out what's going on.

    We're not running any other AI Mods. My script creates the units directly on the position and doStops them. Does group-size have any influence on when AI considers to charge? For perfomance reasons my script places them all in one big group, using enableAttack false to allow them to engage individually. So depending on how our mission-makers set it up the groups might be very big.

    I will try what you suggested and see if it helps. Thanks.


  13. I noticed that with the recent update AI likes to attack players very aggressively and leave their position if it seems advantageous. Which nice and awesome to watch. But unfortunately it also plays havoc with my function to garrison towns, which puts AI into building positions and keeps them in place with doStop (which used to work fine). As of recently I've watched whole towns be "evacuated" and the AI swarming out to overwhelm the players. Is there a way to disable this behavior on specific units, say by setting a variable?


  14. 3. Since there's the new Site Module I wondered if someone already had a look into the code and maybe knows of a new way to occupy bulding positions, especially because I read of some problems with soldiers in buildings in the old threads.

    The Site Modules only work with Military buildings. They are pretty insane, as in they don't calculate the building positions on the fly but rather contain long stacked arrays for each possible mil-building class, containing the relative position and direction for a unit to be placed.

    Last time I tried them in Multiplayer they didn't really work, but that was a few patches ago.

    Here's my function to collect all positions of a building, in case it helps.


  15. I'm not sure how to fix this (I've taken a look at the code, but I'm a bit lost) but when a unit respawns, a unit defined under f_radios_settings_tfr_backpackRadios does not spawn with their backpack radio.

    Try adding

    [] execVM "f\radios\radio_init.sqf";

    after line 57 in JIP/f_JIP_playerRespawn.sqf and after line 34 in JIP/f_JIP_reinforcementOptions.sqf.


  16. Great, thanks :) I don't think we've ever played with respawn before, but I want to make the TvT last a bit longer and I think ticket respawn would do it. Ticket respawn works okay as it is, but I have no idea how to bring up the spectator script when you're dead and out of tickets.

    Is there any event handler that fires only when a player dies the "final death"? In that case you could call the spectator-init function from that event handler.

    Update 3.1.2 and still missing changelog ?

    3-1-2 was only a small hotfix for the mission conditions selector. Fer probably forgot to update the OP.

    Is this compatible with ACRE2?

    I'm getting weird behavior when using the acre option in parameters.

    Not yet but the upcoming 3-2-0 release will be fully compatible with ACRE2. Take a look at our dev branch on github if you're curious.


  17. Hi Folks,

    I want to do a "big" military parade on the big airfield on Altis.

    The big boss is standing on a tower/viewing point and some tanks should drive by.

    Unfortunatly the tanks don´t drive from one waypoint to another (which are (exactly pinned ON the runway) along the street near the viewing point), instead they drive offroad...

    Behavior "careless" or "save" doesnt change anything, I already tested, but they should be in that mode, because I want to see the crews head out of the hatches.

    They should drive from A to B (Formation: File in two rows ).

    And they should drive in two rows and I don´t want to use the staggered column.

    Even they´re set by me in a "file"-like starting-formation, they need to reconfigure their postions until they´re in formation.

    Is there a posibilitiy to get two rows of a military parade, which are starting in a two row formation and which is staying on the road?

    How ca I get this?

    They just need to drive by in two rows, no big thing, but I don´t get it.

    Greetings Purzel

    If it's a SP mission you can try recording the movement. For MP you might want to experiment with disabling various AI modes and using commands such as doMove.

×