VictorFarbau

Well, both behaviours are intentional. About ammo levels: units will not snitch supplies until they're fully loaded. Only if they hit the bottom threshhold (4 or 5 mags) they will take action. I implemented this to avoid one unit robbing all available mags whereas others don't get any (and that will happen otherwise). It is a balance descision which in general works out and does not disrupt gameplay too much. Dropping mags: this is a routine within VFAI.Equipment. In earlier versions I observed that RPG/AT soldiers couldn't take rockets as too many magazine slots were occupied. Hence I have them drop mags until they have room for at least 2 rockets. I will see whether this can be optmized. Cheers, VictorFarbau

Torni, is this a LAW or RPG soldier? VictorFarbau

Updated VFAI to V2.5. Major changes are a reworked control panel and an option to en/disable VFAI for groups (by group leader). I am open to bug reports as usual. In the context of more and more addons that enhance AI I have sometimes seen some weird behaviour. So if you find a bug it would be most helpful if you could limit your addons galore to the VFAI addons and tell me how to reproduce it. Anyway, I hope it will all run smooth for the time being Download links ( thanks to the community sites guys again! ) and updates are on the 1st page as usual. Regards, VictorFarbau

I think this is really well done for cutscene creators. Keep it up VictorFarbau

Some of this code looks spooky to me - and not because it's about zombies  As you work with a fixed set of units you could take the easy route and assign their global names within the "createUnit" command: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _z6="veryslow_Ryan_Zombie7" createUnit [getMarkerPos "spawn3", groupA1,"z6 = this"]; [z6,player] exec "farmland_zombies\rising.sqs"; Would this work for you? Cheers, VictorFarbau

So far I wasn't able to find out if there's a way to do it. Maybe I am blind again, maybe it is impossible. Problem is easy to describe: Script A calls Dialog D. Dialog D calls script B. But script B needs information known to Script A. Any way to pass params from A to D to B w/o using global variables? Or can D maybe directly access information of A? Seems to me that dialogs run in a completely separate codespace. Maybe A can constantly query D for button actions and handle button events directly calling B until D is closed? Hm, that doesn't sound very pleasant. Just thinking... Thanks for any hints, VictorFarbau

Ehrm, yes, access to objects is required now that I can't translate unit/group names back into code (parser hates the space char). I was also thinking to keep a public array of group references for that purpose as my last option. It doesn't feel comfy but since 1.09 arrays supposedly work as public vars in MP. So I will need to give this a go. I guess your (btw - masterpiece! ) Merlin proves this is workable. Thanks again, VictorFarbau

First, a definition of terms used by me: - private var; only known within a script - local var; only known to the local machine (local space) - public var; published to all clients in MP by "publicVariable" I am doing some concept work for the next version of VFAI and the control panel. The control panel can be invoked by every group leader simultaneously so I need to be careful with using public variables in the process. I tested the listbox which worked well, technically. But once translated into text (like "WEST 1-1-A") the unit name becomes useless - I didn't manage to get this back into code using "compile" or "format" in any fashion. Apart from that obstacle, thanks to Dr_Eyeball I am thinking about locality again. I guess this could work since the machine running the CP is also running the related action scripts. Local vars could be used in the process and later translated into public vars to be used by all other MP clients. I need to try this. Thanks for the input! Cheers, VictorFarbau

@Namikaze - awesome idea. I am busy with it right now. @Kronzky - no doubt, but in my case this is not feasible. My dialog can potentially be used by several parties at the same time which would result in variable conflicts. I need context specific parameters here. Thanks, VictorFarbau

As soon as anybody finds a way - I'll integrate it into VFAI. It's been one of the shortcomings that people most complained about in VFAI. Cheers, VictorFarbau

You know what - that just doesn't work. I used this code instead and that did work in a basic way. Same procedure as above to call it. But the jumper remains in a stand position while dropping down. This would have to be changed probably by "playMove". Anyway, that's all I have time for now - need to finish some other stuff first <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_jumper = _this; _jumper setPos [getpos _jumper select 0, getpos _jumper select 1,300]; _jumper exec "camera.sqs"; #loop BIS_Camera setpos [getpos _jumper select 0, getpos _jumper select 1, (getpos _jumper select 2)+4]; ~0.01 goto "loop";

You can paste this into an SQS or SQF file. Well, use SQS for now. Name it like "spawnhigh.sqs" or whatever you like. Then Enter the editor, place a west unit somewhere (otherwise the createGroup West won't work) and put this into the init line: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this exec "spawnhigh.sqs" Mind you: you replace the x,y coordinates with useful values before running the script, obviously. This should work. Maybe I should test it myself Cheers, VictorFarbau

So you want to just spawn a unit in mid-air and w/o a parachute? Since you're still vague  I would think you could just create a unit up in the air. Just throwing in some script code from the top of my brains... <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _testgroup = createGroup West; "SoldierW" createUnit [[x,y,z], _testgroup]; (_testgroup select 0) setPos [x,y,200]; (_testgroup select 0) exec "camera.sqs"; No idea if this is what you're looking for. But you get a (unsuspecting  ) skydiver with an attached camera... Cheers, VictorFarbau

@raedor, yes, it was pure speculation that the vehicle might pop up as "assignedVehicle" and it didn't work out. So this function is really only useful if you leave the rest to the AI system. VictorFarbau

@Master85, I too did a test as it sounded useful and I queried the "assignedVehicle" of the group members. It was "<NULL-object> before but also after adding a vehicle using addVehicle. So maybe it works but not from a script perspective. Cheers, VictorFarbau

Well, it would help to know what you want to achieve exactly...

As the title says... I wonder if anybody found a neat trick to have trucks only take regular roads. In my current mission framework I got supply trucks crossing the whole (Sara) island. It seems that the path finding algorithm is willing to trade speed for trip length; resulting in trucks leaving roads and crossing the wilderness now and then. Which is a problem in my mission - once trucks start taking shortcuts through the bushes they often get stuck completely (at trees, bushes or steep slopes) or the mission is long finished before they're even close to their target. Cheers, VictorFarbau

Yes, "careless" didn't work for me for some reason. And even better, I had applied SNKMAN's suggestion before (setting Waypointbehaviour) and that also didn't work even though this was the obvious coding choice. So what I am doing now is to issue a <setBehaviour "safe"> command on each vehicle instead. I agree it should have worked using "careless" and using waypoint behaviours but it just didn't. EDIT: BTW, I cannot find the quoted Biki entries anywhere under "Behaviour" or "SetBehaviour". At least I am not totally blind now Cheers, VictorFarbau

Wow, "SAFE" is indeed helping a lot. Now, how did you know that and why of all 5 modes "SAFE"? Thanks, VictorFarbau

Hi Namikaze, actually, I thought along the same lines So I should have mentioned that I set the combatModes to green and the waypointbehaviour to careless already. But it didn't work out so far. I have a hunch that the only way to do it would be to edit the vehicle config and flip the magical "offrad capable" bit - if there is one, I don't know yet. But I wanted to avoid changing addons if possible. Thanks, VictorFarbau

SNKMAN, if I remember correctly it always (even in OFP) took up to 30 seconds before a unit and its properties was really known by the game engine. You can still observe this behaviour if you spawn an empty vehicle right in front of you. It takes anything from 1 to 30 seconds before you can enter it. It could be that your script falls victim to this. To work around this I'd do this. If your script knows who's friend and foe (if west then east, if east then everybody ) you could use the "countside" command instead. Does your script know at runtime? Cheers, VictorFarbau

I think most weak spots of ArmA have been pointed here very well. AI "ubervisuals" seeing right through all clutter and killing players with deadly precision. Incredible path finding bugs, AI getting stuck everywhere, sometimes for minutes. AI and players stuck in robotic and repetitive animations which feels very unnatural (gimme the ragdoll engine of Max Payne I and I'll shut up forever). And one thing that annoys me time and again - houses with fake doors and windows. How often did I bump into painted doors and die when under fire? Especially annoying if that is the only house around in about 2 squaremiles. And then the whole shebang runs at 10fps until you own an almost insane hardware configuration. Special Ed is right - it just doesn't feel right. For some odd reason it did feel right in OFP. But turning back was never an option either. Nonetheless - it is the only game that offers such a variety of modding capabilities and I do enjoy the creativity it sparks in many people. BIS has created a unique game design with freedom in design and modification so far unheard of. I sometimes tend to think: they gave us so much freedom and such a powerful concept - how can we make good use of it? All efforts seem so small and lost in such a vast environment. My conclusion: I am delaying all major programming work and mission design until A2 comes out; I don't feel like spending many hours to work around the oddities of A1 only to find out I am back to square 1 when A2 finally comes out. Then I will focus more on environmental addons; something that really brings more life to the game and creates a hostile environment to the player independent from any mission. So I am reducing my efforts to maintenance right now. VictorFarbau

Kroky, yes, the final version will only have chat messages, no OSD. This is just a WIP version you tried there. About a group-focussed switch of VFAI: it requires a new code concept but I was thinking about it as well. Don't like to always turn it on/off globally either. Vehicle.AI: no, this is still dormant. Lack of time. Testing requires many hours usually. Time I don't have after work these days. Cheers, VictorFarbau

For VFAI? Because the eventhandler is registered for the class "Man" vehicle only. As soon as you enter some different vehicle its handlers will take precendence of yours. Hm no, technically impossible. Soldiers can only take weapons from other dead soldiers at this point in time. But they do drop weapons on the ground. However, once dropped on the ground that weapon / magazine is lost and invisible for them (due to some script engine limitation). Cheers, VictorFarbau

@andersson, try this link on rapidshare. I had updated the control panel a while ago for myself; never came around to really update the complete addon. Kroky, I am far from dropping VFAI. Yet I couldn't see why it wouldn't work with that FPFX console, I assume both addons are mutually overwriting their "addaction" entries. Hence I was looking into different invocation methods; turns out that the escape menu entires wouldn't work in MP. Right now I am out of ideas - I could write a version that is called by special keys (like Break eg). I can already imagine the complaints about that Cheers, VictorFarbau