VictorFarbau

Hello, recently I received a message from nikita320106 requesting permission to modify and re-release VFAI.Equipment with some of his ideas. I initially refused that since I planned to maintain and extend the addon myself in the near future. However, I have done an honest assessment regarding probability of that to happen and found myself saying: no time for this. Also, I lost a bit of interest in doing the same addon over and over again for almost 3 years now. So, instead of jealously guarding that lousy piece of scripting I thought I'd rather post the material I have :) If anybody feels like reworking / enhancing and re-releasing it: please do so! I give explicit permission to everybody to do this. I believe some fresh ideas are welcome here. Only this advice: keep the Equipment and Smokeshell addons separate (that little Smokeshell code is not even included, it is contained in the smokeshell addon and this is the only version I worked with). Also, observe unit behaviour in massive multiplayer when you modify the equipment code; you may find units getting stuck if you overload their command queue and the game might even crash. Be easy on the timings (no "delay 0.05" or similar). The more generous you are on the timings the better all this usually works - depending on how busy the engine is. Can be painful to debug this if there the error is not in the code but merely in the way you apply it. Anyway, the little time I can spend on Arma II OA at present is required for me to maintain our massive MP mission we rarely get to play. The little tricks and tweaks possible in Arma II still intrigue me so I will rather continue with small things such as VFFPSS, VFTCAS and the like. DevHeaven is ot reachable for me at this moment, so I am uploading this to the following location: http://www.mediafire.com/?d7hru9pgwnne4lz Regards, VictorFarbau

Avoiding treetops seems to work fine now but indeed dive manoevres are kind of suicidal at the moment and often result in crashes. I will review this and see in how far I can adapt the code to intercept this specific behaviour. Regards, VictorFarbau

I believe soon this project can be retired - see 1st post. Good to see the improvement in flying skills :)

The good news is - it can be done (I believe). But you'd have to dive into some more scripting. 1. Why not use the Fuel Can object for fuel? Editor -> Empty -> Objects -> Fuel Can. Create that object class out of your hemp booze :) 2. Employ drag&drop scripts (like used in my VFladder addon) using sin&cos (_obj setposASL sinx, cosx, 1 or the like) to simulate carrying objects. 3. Try the command cursorTarget to link the can to the car. Make cans appear and disappear as required and set up a score system of global vars or object variables (example: setVariable to manage inventory. It's a challenge for sure; but that's the deal with this hobby :) My 2 cents, VictorFarbau

The trick is to a) determine a suitable position on the vehicle and b) set the animationstate of a unit accordingly. BIS provides some animations for units sitting on vehicles. Example (_unit = soldier, _vehicle = HMMWV): -------------------------------------------- _unit attachTo [_vehicle,[-0.8,-1.5,-0.7]]; _unit switchMove "aav_cargo01"; _unit setDir _0; Voila, the unit sits on the HMMWV. The exact positions are relative to the defined vehicle center - you need some trial and error to find the one you want. Then you need to try which animation fits each position. I usually only use 2 animations: "aav_cargo01" and "miles_c0briefing_odpovedel_loop". Hope that gets you going, VictorFarbau

First of all: fantastic soundmod and I really enjoy it a lot. Since my RPT file is being filled with thousands of errors after each mission (Cannot load sound xyz from your mod...) I'd appreciate any update as well of course. When you talk about a new version you're working on could you be specific about the new revision as well? Right now I used 0.9beta, no clue if this is the one being discussed here or whether you have a new rev in the making already. Thanks, VictorFarbau

The absence of the getposATL (Arma 2) is a showstopper in my mind; it's just no fun and would require a huge amount of workaround code again. Secondly, whenever you find errors using addons from A2 in A1 - check the command reference whether commands are available in A1: http://community.bistudio.com/wiki/Category:Scripting_Commands In the WHILE loop e.g. I used the "currentWeapon player" function. Checked in the reference - introduced in Arma2. You could use a workaround and use "primaryWeapon player" for Arma1. But if the player currently holds the secondary weapon and carries his primary weapon on his back then you end up with faulty positioning again. Also, try to replace getposASL by a simple getpos. Not that it solves it but ASL has no benefit here. I did this in Arma 2 because finally it was possible to grab and handle objects easily w/o 50 lines of workaround code. Maybe you can get it to work somehow in A1 however... VictorFarbau

Hello, well, the problem is that getposATL is a function introduced in A2 only. It enables the correct positioning of ladders when the player is above terrain level (e.g. on a roof). Arma 1 only knows about getposASL instead - I don't think this will work correctly. All would work fine while on the ground; but as soon as you'd enter a roof and spawn another ladder it would spawn somewhere way above or below you since the correct height of the player would be incorrectly computed. Nonetheless, I will compile a version using this command and upload it. And here it is: http://www.mediafire.com/download.php?x2glgwykp6lo872 Don't blame me if it doesn't work well; I was relying on getposATL for this. VictorFarbau

@SpectrumWarrior, the class names of the ladders have not changed from Arma1 to Arma2; the error might be caused by something else. Could you PM me the rpt log messages related to VFladder? I'll have a look then. Maybe we can get this working in Arma1, too. VictorFarbau

Hello erazor, can't say I am really working on this at present, see here: http://forums.bistudio.com/showthread.php?t=106528 I have never experienced any ammo disappearing through VFAI but the issues you describe are usually very hard to determine in the plain code. In the testing environment all that usually worked fine. But I have seen weird behavior in MP games; possibly due to delays in code execution and distribution of global variables. So I hope that someone at some point will pick up the challenge; I fought this battle for years :) VictorFarbau

Spangg, 1. There is a big set of conditions that determine whether VFAI will be run or paused. I can say that the current code should be reasonably easy on the CPU. 2. Ammo crates - unless we get an engine command to read the contents of ammo crates (respectively "weapon holders") from a script -which is not possible at present- that will be tough. It was / is one of the biggest engine restrictions for VFAI. 3. Automatic reactivation after turning it off - that was resolved in the latest version (see the original addon post thread with its change notes). Regards, VictorFarbau

Took some time off recently due to increased workload and some vacation. Those new commands look interesting indeed. I planned an overhaul when OA came out anyway and this will definitely be on the list to test now. VictorFarbau

Lol - that would be a funny bug :) Is this reproducible in the editor, callihn? If not then it is indeed related to some script or code not apparent to you. VictorFarbau

I have a demanding job next to being a father and it would have never occurred to me to waste my time on public servers with all that kiddy shit going on there. You just need 1 or 2 friends playing Arma; then you host a game on your own PC and off you go. Many hours of fun guaranteed. And yeah, you can't have 8 hours of sleep each day :) That you signed when you got a job + family + Arma II. So nighttime is playtime. VictorFarbau

Same here on our dedicated server and it would only load correctly when using "-exThreads=1". All other values would make the machine hang. VictorFarbau

You're looking for "6Rnd_GBU12_AV8B". Trigger condition: ((magazines name_of_your_plane) find "6Rnd_GBU12_AV8B") > -1 As long as the result is bigger than "-1" there are still bombs available. If "-1" all bombs are gone. Regards, VictorFarbau

Hi there, it's probably easiest to use object variables for this. You attach a variable called "build_lock" (choose your own name if you like) to the player. You set it to 0 during mission start (notin the creation script, then it would be set to 0 each time called). When the creation script is called it checks if the timeout period of 300 seconds is over already. After creating the item the build_lock is increased to time + 300. So the build script can never create another mortar if the time between 1st and 2nd creation is < 300 sec. // e.g. put this into the init line of the player // Init variable (run only once during mission start) player setVariable ["build_lock", 0,false]; In the creation script: // Check if player is allowed to build static item IF (time > (player getVariable "build_lock")) THEN { // create the static item here // Now set the timer to time + 300 sec player setVariable ["build_lock", (time + 300),false]; }; Regards, VictorFarbau

Chapeau, this is top notch work Madbull. Real fun to play with. VictorFarbau

For me exthread=3 is definitely an improvement. Playing a heavy mission on my local PC (up to 700 soldiers, 30 trucks, 10 Tanks, 5 Planes, 5 choppers and each unit running several scripts) results in smooth gameplay if I use setting "3". If I use "1" it feels a lot more sluggish somehow. Odd: whatever parameter I start Arma II with, the effects won't show in the Windows Task Manager or in FPS displays - they always report about the same values (25-30 FPS, up to 48% CPU on a quadcore, ARMA II using 15-16 threads). Nonetheless, I experience the best performance when using "3". When I host this mission on a dedicated server (which is the purpose) then my local PC runs at 55-65fps consistently, no matter if I use -exthreads or not. Seems to me that the effects become more visible the lower the PC performs to begin with. Regards, VictorFarbau

Thanks for this update and please allow a few days to come back with feedback. I won't have the time to play Arma for hours each day but I am very willing to test all options in extensive, heavy-loaded SP and MP missions. The changes seem very important to me so due diligence is required. VictorFarbau

@Imutep, Foxhound: thanks guys, appreciated :) VictorFarbau

Feel free to do some statistical research, place 100 choppers with repeating waypoints all over the map. After 10 min, count the survivors. If consistently > 95 I'll retire the project :) VictorFarbau

Updated this addon - changelog to be found in the 1st post. VictorFarbau

The addon needs to be present on the machine spawing the choppers. MP game - server. Local game - client. Not mentioning special situations here. CBA is required as stated in post #1 for the extended eventhandler functions. Regards, VictorFarbau

Some monitors display that behaviour after sudden color changes of bigger parts of the screen because certain electrical patterns (consumption mainly based on brightness) would cause some coils to vibrate. Or, the changing electrical fields have an effect on some insufficient shielding of the internal audio wires. My 2 cents. VictorFarbau