Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Posts posted by VictorFarbau

  1. Merry Christmas. I would try the "unassignVehicle xyz" command in your loop before deleting the unit members.

    Secondly, I am not sure in how far the exitWith{} statements are always executed properly. I seem to remember I had problems with that. Anyway, in your code you won't even need it. Just replace it with an "IF THEN" control structure and after that the script ends anyway...



  2. Andy,

    you can query the mine's status by vectorUp indeed. Example code:

    mymine = "MineE" createVehicle (getPos player);
    test = vectorUp mymine;

    test is now [0,0,1]

    Next thing is that you disable the mine. Then test again:

    test = vectorUp mymine;

    test is now -[-0.5,0,0.866025]

    Hence, if you create checksums out of (vectorUp myMine select 0 + vectorUp myMine select 1 + vectorUp myMine select 2) before and after disabling it you'll know whether somebody disabled it. Main point is that vectorUp should provide different results before and after an engineer messed with it.



    PS: Bad style of course with global vars - better use local vars in the final script. Just did this for a test.

  3. It does work indeed. Instead of a real config file I will use regular sqf script syntax in my 'test.hpp' file to define the desired variables. The calling script will use 'call compile loadfile "\userconfig\test.hpp"' to access the file.

    In case the file does not exist there will be an error message in game; however the script will continue to run (correction to my above message). Then this error can be handled (check for missing var definition = file wasn't loaded) and default values can be used.

    I think that's a fair tradeoff compared to the CTD scenario caused by missing / misplaced config files otherwise.

    Add1: When creating a file to be included and compiled by 'loadfile' command then you can't comment using "//". You have to use 'comment("example");' syntax instead.



  4. Dear me, I just had a typo in the loadfile test. I can confirm this still works! Excellent, this should solve my problem.

    I wanted to include certain parameters on script execution based on the existence of a config (hpp) file. Hence I am including it from within a script context and not in the addon config / description.ext. The latter would be critical admittedly, the script solution should be easy to handle in my mind.

    However, if I get the loadfile exception (Try, Catch) to work then the whole thing should be doable. I'll get back with the details after success / failure.

    EDIT: "Try" does not catch a loadfile failure :rolleyes: The script aborts with an error. At least it doesn't CTD rightaway. Back to square 1.



  5. @UNN - I'd rather leave it up to a user whether he/she chooses to create a hpp config file for an addon. If not then the addon should use its defaults. For many users the concept of creating directory trees and moving files to specific subdirs is an obstacle (plus, it would require to read the readme :D ).

    @Sickboy, apart from the / \ mix (same result btw :) ). To terminate the whole app because of a potentially undefined state is a rather cheap way to deal with it, isn't it. The preprocessor could simply do this - if include file found, all nice and dandy, carry on. If include file not found, scan for "OnException" statement in the same code. If statement not present throw an error message and abort the mission / code execution (and not the application context). If statement present leave it up to the user to react accordingly. It's not that the script engine can't deal with undefined variables of functions.

    Small change, big impact for addon makers in my mind. Not sure how open BIS currently is to conceptual changes of that kind.

    Anyways, looks like it'll be the two versions solution for now.



  6. Kju, I take that as a no ;) The best I could come up with so far was the 2-version solution as well... kind of annoying though.

    'Loadfile' on something like "/userconfig/test.hpp" also doesn't work:

    Invalid path (only relative paths supported)

    Well, quite obvious for a sandbox concept. However, I would wish the preprocessor would allow exception handling in a script instead of crashing the whole application.

    That 2 file solution - I am not yet ready to settle for it :) No idea however what options would be left.


  7. The script command you look for is "player setcaptive true".


    // after player gets into car
    player setcaptive true;
    WHILE {vehicle player != player} DO {sleep 1};
    player setcaptive false;

    Player is set to "neutral" - nobody will mind you. As long as you're mounted in any vehicle the loop will run and check anew each second. After you leave the vehicle your status resumes to default (enemy to west/east/whoever).

    Just an idea to get started...



  8. Hi there,

    well, we all know that statement:

    #include "\unserconfig\test.hpp"

    If that file does not exist Arma will inevitably crash (<- btw, is this really necessary :confused:). But is there any smart way to catch the "File not found" exception?

    Generally speaking I want to leave it up to the user whether to use an hpp file or to go with default values of the addon.



  9. Himmelsfeuer, please don't hijack this thread for a different problem. This is about the crash condition bug (heli upside down crash).

    Let's not make it harder for Devs to follow up as it already is. Thanks.

    ---------- Post added at 04:24 PM ---------- Previous post was at 03:59 PM ----------

    [61032] - Same behaviour indeed. Chopper went upside down, model changed to wreck, both Pilots alive, no explosion.

    Tested it 3 times. The resulting damage values of my chopper after the crash:

    1. 0.0534749

    2. 0.0577221

    3. 0.118688


  10. Managing dialogs is still a nightmare IMO. So much potential goes to waste for many people because you're forced into such level of formal detail. Manually positioning the dialog controls, then find out you forgot one and start modifying everthing again. Attach scripts with relative paths in the description.ext file - then convert it to an addon and change all paths to addon absolute paths again.

    I would pay 10 bucks extra to have a simple dialog editor in the mission editor. Then you choose to invoke it via action menu or ESC screen button, done. Well, you can always dream :)


  11. Indeed I haven't posted it there - it was just a reaction to Myke's post about a new 60902 feature. But I will do so now...

    EDIT: Developer BXBX confirmed the mentioned feature resolved a different issue (choppers not exploding when crashing into ground) and was not meant to address crash-into-tree issues. Hence, leave VFTCAS installed for the time being.



  12. My tests with beta 60902:

    Using the demo mission I uploaded here:


    In this mission I just placed to Mi-8 with "Full Speed" waypoints just across the hill.

    Result East with 60902:

    • Mi 8 - always crashes into these treetops
    • Mi 24 - crashes with 50% probablity
    • Ka 52 - never crashes

    Result West with 60902:

    • MH60 - always crashes into these treetops
    • UH1Y - never crashes
    • AH-1Z - never crashes

    My conclusion: the AI pilots behaviour has been improved but the heavier choppers will still crash (MH60, Mi-8, sometimes Mi24).

    Looks like the values for pilot behaviour based on vehicle type still need to be fine-tuned. Alternatively, reducing the virtual weight of these choppers could also work. Dirty trick but who would notice and it would work with the current pilots flight skills :)



    Take note of the latest beta patch:

    You might have to check if those improvements does affect your addon or even made it obsolete (which i doubt a little).

  13. Considered consulting Mr Murray's Editing guide (free lunch)? The link was posted here some time ago:


    Then there's a BIS portal for all sorts of editing in Arma 2: http://community.bistudio.com/wiki/ArmA_2:_Editing

    Last but not least - the command reference. Ok, it leaves too much room for guessing and interpreting in my mind. But after registering you can also leave comments to help other users use the functions:


    Have a look and say again there's no useful information whatsoever out there :)



  14. I think it's quite obvious that this addon was not meant to reinvent flight physics. It uses tricks to avoid immanent heli crashes to improve gameplay. The core problem (engine pilot behaviour) needs to be resolved by BIS, I can't do that through an addon.

    I remember back in a lil ol game called OFP we had to use some imagination as far as graphics and animations went, but nobody cared because it was the gameplay that mattered

    Amen to that - I am concerned this got a bit lost on the way. The success of the COD series shows that people don't care too much about bugs as long as they get out of the game what they like. It's really great BIS is so comitted to developing this further and that they provide betas regularly.

    If I would be CEO I would print this office banner: We developed the best game ever. Now we must supply game contents (= dynamic missions) that knock people/reviewers off their chairs rightaway. Because you never get a 2nd chance to make a 1st impression :)

    My 2 cents,


  15. Another more generic way to do this would be to check whether the player is in any vehicle. In some scenarios that would do the trick without having to check each single vehicle name or type.

    IF (vehicle player == player) THEN {};

    Meaning, if the player is in the vehicle called "player" then he's not in any vehicle other than his own body. Almost philosophical actually :)


  16. Another but; I've always assumed that anyone who has accesses and uses an addons action menu will always trigger the resulting action on the "local" version of the addon, and not on all client versions. Anyone confirm?

    The way you phrase it is a bit mindboggling. Well, here's my understanding of addon locality:

    1. All addon code (called by action menu or eventhandlers or whatever) will be started on each machine. It is up to YOU to either allow or deny further execution on each machine by using "isServer" (see *1 below).
    2. A good example of a server only addon would be a time server. You only want one instance of that of course. In that case your first line of code would be checking "isServer" and quit if false.
    3. A good example of a client only addon would be particle effects - you can't use particles as MP objects anyway, so quit if "isServer" is true - then it will run only on clients.
    4. If a player on a server machine calls the timeserver script it will be run and do what is supposed to do; if a player on a local machine manages to call the script it will also be started but it will quit rightaway.
    5. You can add menu actions to each player. If the related action starts a script from an addon - back to statement #1. It will be started locally but you need to determine where it can run.
    6. If you want a server only addon only to be controlled by player action menus then I would see two options.
      1: You will always be the player on the server machine - in that case you can start your addon script and it will run fine. In any case you always need someone playing on the server to call the script successfully.
      2: You use a dedicated server. In that case the architecture of the addon needs to be a loop checking for global variables. The player action menu would need to call script that sets a global var. Basically the "remote control" principle. In that case you might even only install the addon on your dedicated server - no need for client side installation.

    My 2 cents - hope there's no twist in there. Seems to work fine for me at least :)


    *1 = You could of course do an "isServer" check in the action menu code already - that way you might also control who is allowed to call the code in the 1st place.