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

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.

Phew, that approach can be problematic, specially when you also want to start using MOD weapons. Anyway, maybe there's a good way to incorporate the principle still - will you contact me by PM? Thanks, VictorFarbau

Choppers only... I have done some tests and it turned out to not work very well for planes. Those typically rush into obstacles with such speed that the corrective measures are way too exaggerated. VictorFarbau

Hi Robalo_AS, cool addition to the concept indeed. Does Arma 2 now allow to check the contents of weaponholders? That would round the whole thing up somehow. Yes, please contact me by PM. Let's see if we can integrate it or whether it's better as a standalone, who knows... :) Cheers, VictorFarbau

== Current development has ceased. VFAI will be continued in Arma II. See you in Chernarus. == Current version is 2.6 - release date 24.May.2009 Revision 2.6 adds ACE compatibility and improves the control panel and code. I don't use ACE a lot but since so many people do I wanted VFAI to be as compatible as possible. I'd be interested to hear whether anybody finds weird bugs due to VFAI. Please post them in this thread and I'll have a look at it. Needless to say that this VFAI release runs with or without ACE alike. The addons require "Extended_EventHandlers" © by Solus (included in the archive). VFAI consists of 3 independent addons 1. VFAI_Equipment enables units to independently equip themselves with weapons and ammo from dead bodys. Further information and details included in the readme file. I advise you to read the readme file - it might explain some behaviour you wonder about. Installation: read the readme file (it is easy). 2. VFAI_Smokeshell will cause units to throw smokeshells whenever they're hit. They will try to throw smoke into the direction of the gunner to block his view. More details in the included readme file. *Installation: read the readme file (it is easy). All units will then be equipped with 1 smokeshell and will know when to use it. Attention ACE Mod users: ACE uses additional "Hit" event handlers to simulate gunshot wounds. It might interfere when both addons try to process the hit event at the same time. I got stuck only once in a seemingly endless animation loop due to that; but it can happen. If you experience this too often, simply turn off Smokeshell.AI through the control panel or don't install SmokeshellAI.pbo at all. 3. VFAI Control Panel Using this control panel addon you will be able to switch VFAI addons on and off in the middle of the game. The control panel is moveable (finally) and will indicate which relevant addons are being found (Equipment, Smoke, ACE Mod), hence some options will or will not be selectable. DOWNLOAD LINKS VFAI current version download link (Megaupload) OLDER YOUTUBE VIDEO SHOWING VFAI VFAI history Revisions VFAI Control Panel v2.6 - More decent design + moveable interface - Autoconfiguration of options based on addon presence Equipment.AI v2.6 - Bug resolved (Grenades not taken) - ACE classes dynamically added if ACE is deteced Smokeshell.AI v2.6 - ACE smokeshells used (if found) 2.5 Major change: New control panel, Equipment.AI can now be turned on/off for each group (by group leaders) 2.41 numerous fixes in all addons (see included readmes) 2.4 Major release, ControlPanel included, reworked Equipment.AI to kill bugs, signed all addons with key VICFA (see OFPEC) 2.3 Corrected dedicated server bug 2.2 Added compatibility to XEH (Solus' Extended Event Handlers) 2.2 Split Equipment.AI and Smoke.AI into 2 independent addons 2.2 New options included, bugs corrected 2.1 Not released 2.0 Code completely revised and optimized, improvements made © 2008 Victor Farbau

Perfectionist :) Nothing wrong with precompiling but honestly here I didn't spend a second thinking about it. Hypothetical calculation based on my usage statistics: Speed gain using a precompiled miniscript like VFTCAS = assumed 0.1 seconds delta per event Max choppers during a mission = 30 Mission duration = 30 min Win with precompiling = 30 choppers * 0.1 delta = 3 seconds Efficiency gain = (3 seconds of 30 min) = 0.16% Investment = browsing scripting reference, building a new config, pbo'ing the addon and starting the game at least 3 times before last syntax error is gone = 20 min = 1200 seconds 1200 seconds / 3 seconds = 400:1 Hence I can play 400 times my 30 min mission (200 hours, /8.3 days) before starting to even think about this investment. That amortization period is too long for me to start my brains :D Just to put it into perspective. VictorFarbau

I like the mod the way it is - sure these might look more like cinematic effects but that's the whole fun for me. The visual model (and color scheme) in Arma II makes a lot of things hard to see. The more I appreciate some exaggerated effects - and this was the whole purpose of the mod, wasn't it? So don't tone it down - that was the status quo before. More action, please. :bounce3: Cheers, VictorFarbau

Update to build 20. This should be the last stable build; entering bugfix-only phase now. Regards, VictorFarbau

I will need make two more modifications to this addon (likely today). Then I'll sign it, push it to DevHeaven and consider it done :) Hope that BIS will be able to fix the behaviour in a later patch. VictorFarbau

Updated to build 18. Should be the final one unless more debugging is required. VictorFarbau

NoRailgunner - thanks, I missed that scenario completely. High time for an update indeed! VictorFarbau ---------- Post added at 12:48 AM ---------- Previous post was Yesterday at 11:50 PM ---------- New build 14 released - I fixed that bug rightaway.

Personally I second anfiach's statement. You don't want to imagine a bunch of rookies abusing this to go havoc in MP games - knowing they won't crash anyway. I wanted AI choppers to survive flying over treetops - mission accomplished. I will create one more version that also supports planes (optional). After that I consider the addon finished. Unless somebody discovers another bug :D Regards, VictorFarbau

I was about to guess that it's the startup order of your addons. So apparently you put VFTCAS in your regular "addons" folder and the eventhandler addon is in the "CBA" modfolder. Which makes me wonder even more - why is it not failing each time? Is the dependency check only done once all mod addons are loaded? This would be interesting - I think this was not the case in Arma 1 yet. Anyway, it works :) VictorFarbau

Bug resolved in build 12 (see 1st page). Not the final state I guess but it runs stable and does what it is supposed to do. Regards, VictorFarbau

Bug confirmed - choppers with "Transport unload" waypoint stay still in mid-air. That's gonna be a interesting one to resolve. Will look into this later today. VictorFarbau

That drop behaviour is odd considering that the script won't do anything while the speed is below 30 (which it is when hovering). With that specific scenario that you had there - could you confirm it always works fine without VFTCAS installed? I'll do my own test as well. Cheers, VictorFarbau

For the time being I hosted the file in another project section until I figure out why the file space is restricted. Link updated. VictorFarbau

New build released, all details in Post #1. Regards, VictorFarbau

I knew it could happen but still released version 1. In the next release I will introduce a live pilot check. Seems easy but during tests this added a few cycles too many to the radar check loop which caused problems with response time in some scenarios. And something else I need to get off my chest: This addon is only designed to improve gameplay - not to improve realism in any way. I want choppers to survive a bit longer and not crash into trees here and there. I didn't mean to create a real TFR or flight assistance system of any kind. Gameplay! Before you freak out just because BIS doesn't have something like this built in consider this: compared to an Airborne-AI system this addon is just a stupid tiny hack. It forces Helis to fly higher with obstacles ahead, fullstop. It doesn't mean BIS did a bad job on their Air AI in general - VFTCAS only works around a small shortcoming there if at all. So better don't compare 150.000 lines of code with my 5 lines :) Cheers, VictorFarbau

@norrin - hm but this needs XEH because of the class init eventhandlers; only other option would be to start this manually on each single chopper. That would really suck. Edit: however, I will make a CBA-free version available, too. It would require manual start of the script, but if you don't mind init lines like that... up to you. @nikita320106 - I have to leave config tweaks to the config gurus. I don't think this would address the root cause anyway. No matter how careful but the pilots would probably still not "see" certain objects (yellow trees being amongst them). I am awaiting my project space on DevHeaven for this addon. Then I will host the files there. The addon requires 1 or 2 more updates before I would consider it final. Regards, VictorFarbau

Debug mode - not visible during regular gameplay. VictorFarbau

Reasonable suggestions indeed, will put them on the list for the next update. Cheers, VictorFarbau

Syncing continuous object movement from server to clients would result in the same jumping objects that we see today whenever a vehicle is object on a foreign machine. I could imagine this: the server would have to predict a path the object/torso would follow - then leave the rest to the local machine. The position of arms and legs in final state on each machine is not really critical anyway. But the movement has to be local - nothing would look worse than a badly sync'ed ragdoll jumping up/down/left/right during its fall. Cheers, VictorFarbau