Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Posts posted by VictorFarbau

  1. Next version uploaded. Split Equipment and Smoke into 2 separate addons finally. Made it compatible to XEH from Solus. Improved behaviour. Corrected bugs. Probably introduced new ones smile_o.gif

    Make sure to read the included readme file. It might really answer a lot of questions you sometimes have when wondering about behaviour. It also explains methods how to turn the feature on/off when needed.

    Bug reports welcome as usual in this thread. I cannot test all possible situations and 3rd party weapon addons upfront of course. So the more precise you are in reporting bugs the quicker I can look into it.

    Thanks and have fun!


  2. @william1 - I guess you should not keep the old versions. XEH also defines the required classes so "old" addons should work. At least it worked in a quick test for me (VFAI requiring "Extended_Init_Eventhandlers" still worked fine). It's apparently more a cosmetic matter in the examples of XEH.



  3. @Solus, a quick note. The examples include config.cpp files that still state

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> requiredAddons[] = {"Extended_Init_EventHandlers","Extended_Fired_EventHandlers"};

    I changed that to just "Extended_EventHandlers" in my config.cpp which works fine.



  4. Funny that I was just reading this forum when the VFAI stuff popped up again now. I am still revising the code for the next version to better balance the behaviour. Also found some bugs that would indeed lead to looting actions while not really taking anything.

    I will also split out the smokeshell usage and make this a separate addon because that one is simple and stable. The Equipment.AI part is keeping me busy still and I want the next release to be a milestone in reliability. More context related behaviour and "group thinking" are interesting ideas which I will pursue this thing runs stable. But first it's christmas xmas_o.gif


  5. This patch saved my marriage. I am running this on a C2D 2.13Ghz with 4GB RAM and Vista 32. I was sure I would need to replace my good old Geforce 7800GTX (256MB RAM) with an expensive new card very soon. As of 1.09 the game is smooth as butter. Money saved and re-invested in family = better Xmas. Thanks BIS xmas_o.gif


  6. Quote[/b] ]BUT I follow this thread because VF is on to something

    Very true smile_o.gif I am also closely following the feedback here. I will release V2.1 soon which will address the annoyance with dropping weapons as well as some other bugs. Also global parameters will be used to turn some features on/off - that will be interesting for mission makers. To tune the behaviour (sometimes suicidal) and improve weapon/ammo recognition (still occasional errors with config files) will be on for V2.2. Goal is to be in final stage and perfect in V3.0.

    EDIT: I saw that this function will be added as of patch 1.09:


    I need this function to correct the config class name bug I struggle with. I will work on a new release as soon as v1.09 is published by BIS.


  7. I use DMSmokeEffects 4.3a on our dedicated server and for me the viewblock smokegrenades seem to work fine. I used them regularly against infantry since a while already.

    The other day we were playing an MP mission (dedicated server running DM's addon) and got pinned down by a BMP guarding a road. I threw a smokeshell onto the road and we could easily cross and disappear into the woods opposite of the road. The BMP started circling around our position (as he lost us I guess) but never found us.

    That can't all be just wishful thinking or is it?  biggrin_o.gif


  8. @Kroky,

    1. I also saw units firing with a weapon still on their back. This should be an engine problem as the "ready to fire" state is apparently reached before the "change weapons" animation completes.

    2. In general this is by design. I only allow them to take 1 item at a time to avoid a single unit robbing all resources while others are also in need. And they want everything; ammo, RPGs, smokeshells, grenades. I will observe this however to check for flaws.


  9. Hi DMarkwick,

    here's the scoop, this should not happen anymore as of V2.0. Yet I was fighting with implementation problems using values from config files. Here's the story:

    Editing Thread

    Weapon and ammo types are being recognized and used at runtime. And in most cases this works so far. Can you tell me with which units/weapons you observe this behaviour?



  10. [WWS]WarWolf,

    Quote[/b] ]sometimes I see snipers running around with no weapons now

    I am always interested in hearing this. Can you provide the following details next time you see one of these snipers?

    1. What is the unit type of the sniper? West/East/Guerilla/custom addon type? If custom, which addon pack is being used?

    2. What weapons would this unit carry originally? (not needed if standard unit types are used)

    3. Are these snipers carrying launcher weapons when you observe them?

    Situation 3 could be due to this: sniper runs out of ammo, finds a machine gun, finds and takes a launcher, hence looses the machine gun and now only has a launcher (+ maybe a handgun). Need to optimize this behaviour still.



  11. Quote[/b] ]VictorFarbau is it definitive yours or is it the same source (sound/vid etc) from which all can find+take this sound?

    Good point. Nonetheless I merged a custom echo into my sound back then - and this is the very one. Somebody from the FFUR team(?) took my AKS74U, AK74 and also the PK sound and put it into the SLX_GL3 sounds folder. I had a quick look and found the identical sounds on my HDD. Quiet sad, can't remember anybody asking me. Ah well, at least they shouldn't advertize new & improved sounds whistle.gif


  12. @gL33k: VFAI does currently not use any voices.

    @Mr_Centipede: if you need units to hold their positions then you need to stop them through the action menu. VFAI will respect a stop command and will be paused for the time being.

    EDIT: a new version will be posted tonight btw.



  13. Sorry, lengthy post. I'll try to be concise in describing what I want and what I did.

    Here's the one line description of my problem:

    I can get the ammo class name linked to a unit's weapon through the addon config file but cannot find the same names back in the unit magazines names so I won't know whether a unit has sufficient magazines left. And this behaviour occurs if class names are defined in an upper/lower case mix.

    More details:

    I am currently completely rewriting my Equipment.AI (VFAI) addon that allows units to independently take weapons and ammo as needed. One of the limitations so far was that I used fixed weapon and corresponding ammo class names. This caused 3rd party addon weapons to be not properly recognized and used.

    Now I use the "weapons <unit>" command to query for the weapon class names, then I query the config file for the corresponding magazines using the "getArray (configFile >> ... >> magazines)" command. I have tested this with the built-in weapons as well as Skaven RACS and HD units and it reports back the required ammo class names fine in all cases.

    So what's the problem? I have scripted this in a way that units would drop weapons for which they can't determine any magazine class or when they are out of magazines. So during test runs I noticed that it works with built-in weapons and also Skaven's RACS units. But the HD units from the same addon would drop their weapons rightaway.

    A quick check in the config files showed that the HD units use a mix of upper/lower case weapon and magazine class names (sth like "Ska_HD_Ak74Mag" e.g.). So the script expects to find magazines with this exact name in the unit's inventory (using "magazines <unit>"). However the comparison between config name and magazines command result seem to differ. If I debug the values through "unit sidechat" then everything is being put into upper case letters; if I use hintC then upper/lower case is being shown correctly - and it even displays config and magazine command class names to be identical  confused_o.gif  Nonetheless a comparison such as (a == b) results in FALSE so the weapons get dropped still. The same comparison works fine if all class names are defined upper case.

    I looked at Skaven RACS class weapons and they're all defined in upper case letters - lo and behold that all works brilliant. The same goes for the built-in weapons.

    I begin to believe this is the root cause for these issues - any ideas anybody?



  14. Quote[/b] ]missionmakers can simply disable the vfai for not-to-be-armed civilians or prisoners

    A concept to en/disable VFAI per unit is on my agenda as well. Haven't worked with the config commands yet. Guess this will be fun and games again given the sparse documentation in the Wiki.


  15. Btw - I believe you still need to "stop" a unit if you want them to stay where they are. In case any order such as this is issued they will not move away.

    This limitation is inherent to the whole addon logic; units will need to use time when no commands are issued to get equipment. After that they will "return to formation". This is a kind of tradeoff - if I wouldn't do so you would "lose" your units when moving. They would pick stuff here and there but stay there until you manually ask them to return to formation. This can get really ugly when you don't pay attention.

    So the current behaviour is the best compromise I could find. If any orders are given they will be followed. But once locations are reached, equipment is needed and bodys are lying around you won't be able to stop'em, like little kids tounge2.gif

    Next on the agenda is an improvement to detect foreign weapons and ammo (3rd party addons) and handle them correctly,