Jump to content
Bohemia Interactive Forums

baermitumlaut

Member
 View Profile  See their activity

  • Content Count

    71

  • Joined

  • Last visited

  • Medals

Posts posted by baermitumlaut

  1. Posted

    Can I add FRIES via script?

    Yes, like this:

    [_vehicle] call ace_fastroping_fnc_equipFRIES

    With _vehicle being your helicopter. This function should be called serverside and is not public API (yet), so it might change at a later stage.

     

     

    OK, stupid question.  Is there any documentation about FRIES?  Are ropes added to any helicopters by default?  Or do they need to be synced via module placement in mission building?

    I can't find any information about them on the Wiki or here.

    You can find the documentation on the ACE3 Wiki. There is also documentation for modders available that want to make their helicopter fast roping capable (note that there's a formatting issue right now which should be fixed soon).

    Every fast roping capable helicopter automatically has infinite ropes available. Having a limited amount of ropes that can be loaded through ACE3 Cargo is planned but might still take a while.

  2. Posted

    Will FRIES have a zeus placeable module in the future?

    (Or an option to be enabled on all applicable choppers by default?)

     

    A Zeus module is definitely planned, a module option to equip all helicopters could probably be done too. Another suggestion that came up today is to make them mountable during a mission, although I am not sure if that's a good idea yet (because of multiple reasons, realism being one of them).

  5. Posted

    jones140 said he'd work on compatibility if it was well executed. So, maybe?

     

    There's only two lines in the config you'd have to add to make it compatible ;)

     

    YQcgfb9.jpg

    But as jonpas already said, it's neither finished nor integrated into ACE3 yet. It works perfectly fine in singleplayer for now, but still has issues in multiplayer (I've done some first multiplayer tests today). Those should all be fixable though.

    • Like 6

  7. Posted

    Update - Version 1.12

    • Fixed HUD not initializing for non-dedicated host
    • Fixed HUD not visible on mission start (added delay on startup)
    • Fixed CBA key handlers returning nil
    • Fixed missing IDC errors, restructured settings dialog (only internal, non-visible changes)
    You can download the newest version in the first post.

    Do you plan to add squad member list like in ShackTac?

    I will add something like that, but I'm still thinking how exactly I will implement it, it will most likely replace the command bar squad leaders currently have. It will also be able to get restricted serverside (SQLs only, everyone or noone).

    Donwloaded and found a problem. In editor it works but when I export mission and run it as server (not dedicated), I don't see HUD and settings in configure addons section. Tried with CBA and BlueHUD addons only.

    This was an oversight by me, I've just fixed it. Thanks for the bug report!

  8. Posted

    Suggestion: Have option to keep HUD when inside a vehicle.

    The HUD has been disabled in vehicles on purpose. Most vehicles provide you with a very narrow field of view, and you especially don't have any "feeling" for what is going on behind you.

    Interesting mod, any chance of adding an option to change the color? It can be very hard to see in certain conditions/maps.

    I am not sure, but I might add something like that.

  10. Posted

    Thank you for letting me know. This can happen with a faulty addon or mission script, if a postInit function takes too long to execute it will kill all following postInit functions. Unfortunatley, there isn't much I can do about this with the way I currently initialize the HUD. I'll see if I can create a workaround so that that doesn't happen in the future.

  12. Posted · Edited by BaerMitUmlaut

    It recently came to my attention how many addons use vulnerable userconfig files. Almost all addons that use userconfig files are able to get exploited to execute custom code, and I only found very few exceptions (don't worry, ACE is safe!).

    To help addon makers to fix their addons to stop such vulnerabilities in the future and to make it public so hacks that currently use these ways become useless, I decided to make a little guide on how to save and how to not save user settings for your mod.

    Below is a list with of methods to save user settings, each with a short list of pros and cons and a short example how it could be used and how it can be abused.

    What you need to know first

    If you didn't know yet, #include simply copies the content of a file into the #include line. It does not care what you include, it does not care about the file extension, it does not execute anything on it's own, it's a very "stupid" command if you want to say it like that. However, that makes it very abusable, too.

    profileNamespace Variables

    ProfileNamespace variables can be easily set with setVariable and are a great way to save settings for your addon. Because you can save raw datatypes such as numbers and booleans, these don't allow any possible attack points unless you save code in them which you want to execute. Don't do that and everything is fine.

    +fast and easy to use

    +can be set in game

    -need an interface to be set

    -cannot be changed on servers

    Example: 

    _settingA = profileNamespace getVariable ["MyAddon_settingA", false];

    Malicious example: 

    _settingA = call (profileNamespace getVariable ["MyAddon_settingACode", {false}]);

    Parsing files

    Parsing files manually (that means, you open a file and interprete its content manually without executing anything) is a safe way to read user settings. These files can be stored in the userconfig without any risks. However, it depends on the implementation of the parsing function how secure and how user friendly it is. I have implemented a safe parsing function for userconfig files here: https://github.com/BaerMitUmlaut/Arma-script-snippets/blob/master/fn_readConfig.sqf

    CBA also includes a YAML parsing function, you can find an example on how to use it here: https://github.com/CBATeam/CBA_A3/blob/master/addons/common/test_parseYaml.sqf

    +settings can be stored in a file & can be used on servers

    -safety depends on implementation

    -might be buggy if the user feeds you useless data

    Example: 

    _settingA = ["\userconfig\MyAddon\settings.hpp", "settingA", "BOOL"] call MyAddon_fnc_readConfig;

    Malicious example: -

    Executing SQF files

    This is a very critical method. Make very sure that you are only doing this on the server!

    With this method, you save the settings as SQF code in a userconfig file, load it dynamically on startup and read its values. If this does not happen only on the server, the user can simply append any code he wants and it will get executed by your addon, even using signature files won't help with this!

    +easy to use

    +settings can be stored in a file & can be used on servers

    -very dangerous if not used only on the server

    -allows execution of any code the user puts into the file

    Example: 

    //Safe:
if (isServer) then {[] call compile preprocessFile "\userconfig\MyAddon\settings.sqf";};
//Unsafe:
[] call compile preprocessFile "\userconfig\MyAddon\settings.sqf";

    Malicious example:

    settings.sqf:

    MyAddon_settingA = false;
player allowDamage false;

    Including SQF files

    This method can be exploited, no matter what you do. Do not use it!

    By including a file into your code, you allow that code to run within your (signed) addon. It cannot be detected and can do whatever it would like to do. This means that your addon can be the hole that lets malicious code run on a server.

    -allows execution of any code the user puts into the file

    Example: 

    if (isServer) then {
#include "userconfig\MyAddon\settings.sqf"
};

    Malicious example:

    settings.sqf:

    MyAddon_settingA = false;};
//here we closed the if bracket and can now write code that will be executed clientside
player allowDamage false;
//By doing something completly useless, we can avoid an SQF error that would detect the bracket that is one too much now (because we closed the if one already)
waitUntil {true

    Including config files

    This method can be exploited, no matter what you do. Do not use it!

    By including a userconfig file into your config.cpp you allow that any custom config from the userconfig will be loaded. This could be changes to CfgVehicles (init event handlers!), CfgAmmo, or even worse, Extended Event Handlers. Those can only be used with CBA running, but so many addons require CBA anyways, so don't rely on that.

    -allows injection of any config changes the user puts into the file

    Example: 

    MyAddon_settings {
#include "userconfig\MyAddon\settings.hpp"
};

    Malicious example:

    settings.sqf:

    MyAddon_settingA = false;};
//here we closed the MyAddon_settings bracket and can now include any config changes that we want
class Extended_PostInit_EventHandlers
{
asdfghjklasdfhjkl_init = "call compile preProcessFileLineNumbers '\userconfig\hacks\hacks.sqf'";
//No need to close this since we already have a closing bracket in the config.cpp

    Why you should be concerned

    Barely any addon that uses a userconfig files is safe. That means: a ton of addons are unsafe! I know of a few VERY popular addons that can be abused this way!

    This is a major issue, and you should as a server owner double check what kind of addons you have whitelisted.

    Rather take one off the whitelist than leave it on there.

    Thank you for reading!

    • Like 2

  18. Posted

    Did you do the mission root thing I talked about? Because if you didn't, it's simply not finding the textures because you want to use it in a mission and not as an addon.

    For the mission root, make sure you define it in the fn_initHud.sqf for example with one of the methods I linked from KKs blog, then open up fn_buildEH and everywhere where it says something like

    (uiNamespace getVariable 'BlueHudMap') drawIcon [('BlueHud\UI\' + ...

    replace it with

    (uiNamespace getVariable 'BlueHudMap') drawIcon [(MISSION_ROOT + 'BlueHud\UI\' + ...

    The texHeaders.bin file should not be needed.

  19. Posted

    Does this show all of same faction or is it just STHUD without the squad list?

    It can show everyone from your faction, not just your squad. There's also a few more differences to the STHUD, the major ones being that it's restricted to 20m distance instead of 60m and that it can be restricted to only showing what's in front of you instead of what's behind you as well. In general, it's less of a "cheat" you could say.

    Either my vision sucks or that thing is damn near invisible

    Youtube's compression is a big factor, but I can't really do anything about that. I'd suggest you just download it and try it for yourself.

    Can you do script version of that to add into missions directly? Is this possible?

    In theory, this could be put into a mission file, yes. You can just unpack the PBO (or check the source on GitHub when it's up) and tweak it a bit. Parts of the config will have to be put in the description.ext and the icons will have to be referencing the mission root. It's a bit of work but definitely doable.

    I will not make an official mission based version of this, but feel free to that yourself. I don't mind people tweaking it at all.

  20. Posted · Edited by BaerMitUmlaut

    57xdvDY.png
    BlueHud is a new HUD enhancement for Arma 3. Its aim is to provide a better perception of teammates in
    your vicinity without giving you an infantry radar that provides a super human awareness of your surroundings.




    Features:
    • Provides realistic periphal vision of teammates
    • Completly customizable (see screenshots below)
    • Subtle, immersive and well integrated into Arma's UI
    • 11 different infantry roles can be displayed
    • Features can be restricted by the server if so desired
    Screenshots:


    5l97vbG.jpg

    LaoRddj.jpg

    8A997FG.jpg

    gmtO5Up.jpg



    Installation:

    Unpack the ZIP file and move all folders into your Arma 3 directory, usually located at
    C:\Program Files (x86)\Steam\steamapps\common\Arma 3
    Some messages will pop up, click ok to merge the folders into your Arma 3 directory.
    The userconfig is only needed if you are running a server, further instructions how to restrict
    the features are inside the serverDifficultySettings.hpp file.


    Keybinds:

    Shift + Ctrl + B - Show HUD settings
    Shift + Alt + B - Hide HUD
    Both can be changed in the "Configure addons" menu in your controls settings.


    Credits:

    Credit where credit's due: This addon was heavily inspired by ShackTac's Fireteam HUD, my original intention was to create a more subtle and
    limited replacement for it - I don't think somebody has any perception of what is going on 60m behind himself. I did not use any code from ShackTac's mod, it's an entirely new creation.

    Also thanks to Gruppe W for accepting my mod early in their modpack and for their constant feedback. It has helped and motivated me a lot.


    Download
    This mod requires CBA.
    Source available on GitHub.

    • Like 2

  21. Posted

    Also, has anyone else noticed a decrease in server performance since the last update? Our server feels a lot more laggy with less people in the server... and I feel like the ambient animals have also been reproducing a lot more. Use to see like 1-3 every few km's, but now there is like 10-20 while just standing still (i know these are client side, but it seems to have gotten ridiculous).

    Now that you say it, I have noticed more animals too. I saw 5 rabbits within a 2m radius recently. However, animals aren't synched in MP.

×