VictorFarbau

Updated to build 60. All in 1st post as usual. VictorFarbau

VFTCAS - can't find a way to reproduce the crashes when VFTCAS is active. All choppers crossing hills and treetops just fine. If anyone finds a way to crash them reliably then I can work on it. Maybe the new crashes are not height related... VFAI - I will post a maintenance version soon (including ACE compatibility). I will check for the self-enabling bug there! Regards, VictorFarbau

Interesting - I will check after xmas and do some testing. If flight physics were changed in 1.05 it might well be VFTCAS needs adjustments as well. I too had the feeling that in the beta versions closer to 1.05 I started seeing choppers crashing in treetops again. Regards, VictorFarbau

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... Cheers, VictorFarbau

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. Cheers, VictorFarbau PS: Bad style of course with global vars - better use local vars in the final script. Just did this for a test.

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. Thanks, VictorFarbau

Congrats to your optimistic view on things UNN but I don't share it :) Foolproof today - less impact tomorrow. Specially when it comes to CTD then a bit more care is due I believe. VictorFarbau

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. Cheers, VictorFarbau

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. Thanks, VictorFarbau

@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. Thanks, VictorFarbau

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. VictorFarbau

The script command you look for is "player setcaptive true". Idea: // 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... Cheers, VictorFarbau

Happens to me randomly (Window or Full Screen mode); usually after a longer game (>= 1h). ATI4850 in use on Windows 7 Pro 32bit. Noticed this ever since release I think. I usually shut it down via the task manager and it doesn't bother me too much. But the problem is there, no question. VictorFarbau

Let me hotlink a message from the VFTCAS thread here: Quick Test of build 60902 I don't know whether the 60902 Helicopter changes were supposed to address this issue in the 1st place - but I guess this would need further improvement. Cheers, VictorFarbau

[61062] Identical behaviour. But since this is a cosmetical bug I don't even mind so I won't follow this anymore. Got more important things to do :) VictorFarbau

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 VictorFarbau

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

Confirmed as well in 61012. I just had an AH-1Z hovering (4m height) over Utes airport. Pressed A so it started tilting to the left - eventually it tipped over completely changing to the "destoyed" model. No explosion no harm done to the pilots. Not critical in my view but certainly awkward behaviour. VictorFarbau

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 :) VictorFarbau

All right, in that case I'll leave VFTCAS installed :) Good that this was fixed though - I was really wondering about some choppers remaining intact after some 200m freefall... Cheers, VictorFarbau

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. Thanks, VictorFarbau

My tests with beta 60902: Using the demo mission I uploaded here: http://dev-heaven.net/projects/list_files/vftcas 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 :) VictorFarbau

Considered consulting Mr Murray's Editing guide (free lunch)? The link was posted here some time ago: http://hx3.de/tutorials-157/armed-assault-editing-guide-deluxe-edition-mr-murray-15209/ 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: http://community.bistudio.com/wiki/Category:ArmA_2:_New_Scripting_Commands_List Have a look and say again there's no useful information whatsoever out there :) Cheers, VictorFarbau

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. 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, VictorFarbau

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 :) VictorFarbau