VictorFarbau
-
Content Count
557 -
Joined
-
Last visited
-
Medals
Posts posted by 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.
-
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
-
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
-
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
-
[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
-
Let me hotlink a message from the VFTCAS thread here:
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
-
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
@VictorFarbauTake 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).
- Mi 8 - always crashes into these treetops
-
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.
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 matteredAmen 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
-
Not that this belongs here, Maturin, but you might be looking at an old log entry of your rpt file. Just empty the contents, save it and have a look after the next game start.
VictorFarbau
-
I really like it - it just does what it is supposed to do and it improves gameplay. Thumbs up :)
VictorFarbau
-
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:
- 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).
- 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.
- 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.
- 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.
- 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.
- 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 :)
VictorFarbau
*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.
- 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).
Counting Missing guys...
in ARMA 2 & OA : MISSIONS - Editing & Scripting
Posted
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