Jump to content

Sgt. Dennenboom

Member
  • Content Count

    93
  • Joined

  • Last visited

  • Medals

Posts posted by Sgt. Dennenboom


  1. If the unit is in a vehicle, the vehicle command will return the vehicle.

    If the unit is NOT in a vehicle, the vehicle command will return the unit.

     

    _veh = vehicle _unit;
    
    if (_veh != _unit) exitWith {hint "The selected player is not in a vehicle!";};

    Will therefore exit when the player is currently in a vehicle.

     

    Fix:

    _veh = vehicle _unit;
    
    if (_veh == _unit) exitWith {hint "The selected player is not in a vehicle!";};

     


  2. Alright, so "setVehicleCargo" is the proper command, but it returns a boolean value when it's run to show whether the cargo loading was successful.

    Code run in the init box of an object may never return a value, so just putting the following code in the init box will result in an error:

    BR1 setvehiclecargo B1;

     To prevent your code from returning a value, you simply assign it to a local variable that's not used:

    _null = BR1 setVehicleCargo B1;

    This code doesn't return a value, so it can be used in an init box.

    This should work give the result you're looking for

     

    PS.

     

    You can load vehicles into other vehicles (including racks) in the editor, by just dragging the icon of the cargo vehicle on top of the icon of the carrier vehicle.

    • Like 1

  3. Got another update for you after all this time!

    • Added: EvorA: Altis Blue
      • Play as NATO vs. AAF
      • Infantry focused gameplay
      • Mostly close-quarters objectives in and around Kavala
      • Start on the USS Freedom in Kavala Bay
    • Added: Better TFAR & ACRE compatibility related to equipment saving
    • Added: Stringtable entries for all strings in all scripts (EN,DE)
    • Added: Functions for localizing remoteExec'd strings on client
    • Added: Objective & RT status hints to menu dialog
    • Added: Briefing about custom user actions
    • Added: Lobby parameter for disabling vehicle TI equipment
    • Added: Lobby parameter for RT marker
    • Added: Lobby parameter for reinforcement event warnings (reinforcements/base attacks/air patrols/artillery)
    • Tweaked: Number of enemies in AO (more but smaller groups)
    • Tweaked: Enemies now patrol the RT more
    • Tweaked: Vehicles spawned through FARP compositions now respawn
    • Tweaked: Enemy AI courage value baseline
    • Tweaked: Vehicles can now spawn & respawn as cargo inside other vehicles (exclusively used for boat-racks)
    • Fixed: Artillery marker had wrong marker class for opfor
    • Fixed: Vehicle engine is now turned off when editing loadouts to prevent random throttle increase
    • Like 1
    • Thanks 2

  4. On 2/4/2019 at 1:16 PM, Groove_C said:

     

    Is it ok if the mission will be translated to russian and changes will be made to CSAT/NATO equipment/vehicles?

    You should seriously consider to add earplugs.

     

    Vehicles one purches should be locked by default.

    Lock vehicle button shouldn't push other players out, as there can be player

     

    Russian is fine, although I'd like to have that translation as well since it can be put in the stringtable for the next version.

    You can edit the shops and objective units if you want.

     

     

    Earplugs are already in the mission, although it's not advertised very well:

    • "custom user action 1" toggles earplugs
    • "custom user action 2" toggles weapon holstering

     

    The locking mechanic is a bit complex:

    • If you are inside the vehicle: nobody is kicked
    • If you are outside the vehicle: other players and AI not commanded by you are kicked

    So if you want a locked vehicle that is still manned, put your own AI in it.

    It would be weird to lock people into your vehicle with you not inside it.

     

     

    6 hours ago, Groove_C said:

    @Sgt. Dennenboom

    Today I have found a server that runs your mission with mission name completely changed and authors removed everywhere and replaced as if the mission was done by somebody else. Mission weights ~2.7 MB, with a lot of script errors.

     

    I have the .pbo of the modified mission if you need it. 

     

    Interesting, I'll look into them.

    EvorA has an (easy to get around) mechanic that prevents you from changing the mission name, so they must've removed that as well.

     

    I'm not sure about how to go about stopping them though.

     

    • Thanks 1

  5. @varrkan_ua

    1. I have no plans for a system for saving mission progress and purchased equipment between server restarts. The EvorA missions should take about 6-10 hours to complete in their default settings, so I've never tested the stability of the scripts after such a long uptime (theoretically nothing should go wrong).

    The mission should only reset when it is completed or when the server is restarted.

     

    All purchased equipment should remain purchased during a session (unless you are playing multiple EvorA sessions at once, but this will be fixed eventually).

    Vehicles get cleaned up unless they are kept at base.

     

    2. I don't know, EvorA used the default BIS revive system and uses some variables from that (markers for example). There is also a custom hold-action healing functionality, which could interfere with added systems.

     

     

    There's a pretty big update coming "soon" for EvorA, so maybe wait for that.

    • Like 1

  6. Unscheduled scripts called from a scheduled environment such as the init.sqf are still in that scheduled environment.

    Your init.sqf therefore waits until "Scripts\MY_fnc_whatever.sqf" is finished before it continues with the sleep and with "Scripts\MY_fnc_whatever_2.sqf".

    If that first script takes a long time, you won't see the second script happening.

     

    If you want both scripts activated, spawn them instead:

    spawn compile preprocessFileLineNumbers "Scripts\MY_fnc_whatever.sqf";
    sleep 1;
    spawn compile preprocessFileLineNumbers "Scripts\MY_fnc_whatever_2.sqf";

     


  7. The vector from "selectionPosition" to "worldToModel" is the difference between them:

    For example:

    _attachPoint = OBJECT selectionPosition "SELECTION"; // Vector from OBJECT center to selectionPoint
    _worldToModel = OBJECT worldToModel(ATTACHMENT modelToWorld [0,0,0]); // Vector from OBJECT center to ATTACHMENT center
    _offsetFromSelection = _worldToModel vectorDiff _attachPoint; // Vector from selectionPoint to ATTACHMENT center

     

    • Like 1
    • Thanks 1

  8. GOM has the right idea with his script, but it could fail if used in multiplayer.

    There is no way to know which one of the two remoteExec's will be executed first on the receiving client.

    It could easily add the hellfire first, then remove it.

     

    A very simple way to avoid this would be to send over a script that does everything at once (highly unsecure though, write a function and send that over instead):

    _veh = yourAircraft;
    _mags = ["weapon1","weapon2"...,"weaponN"];
    
    [
    	[_veh,_mags],
    	{
    		params ["_veh","_mags"];
    		{
    			_veh setPylonLoadout [1+_forEachIndex,"",true]; // Numbers work too (uses 1-based indexing)
    			_veh setPylonLoadout [1+_forEachIndex,_x,true];
    		} forEach _mags;
    	}
    ] remoteExecCall ["call",_veh];

    Be aware that setPylonLoadout needs to be executed where the turret that pylon currently belongs to is local.

    If you want to switch pylon control from pilot to gunner, you'll have to remove it where the []/[-1] turret is local, and add it where the [0] turret is local.

    This gets real confusing real quick.

×