Jump to content
Sign in to follow this  
fer

VBS1-style Special Variables?

Recommended Posts

In VBS1 there used to be a selection of special reserved variables. For example, VBS_units could be used to return an array populated by all units present in a mission. Are there equivalents in ArmA? I ask because I would like to port some of the resources developed for the CoopA project from VBS1 (see: http://www.ballisticaddonstudios.com/coopa/ for the various components).

- Fer <TZW> smile_o.gif

Share this post


Link to post
Share on other sites

As far as I know there isn't...

I had the same issue - not wanting to totally re-write my VBS stuff. So I figured it was easier just to recreate those VBS functions and variables.

Check your PM for details...

Share this post


Link to post
Share on other sites

If you want to get the array of all units in the mission, try the vehicles command.

It will return array of ALL vehicles (units too) except the units which are INSIDE any vehicle.

To make things short, here is a script which will give you ALL units and vehicles (if you want to get soldiers only, you can filter them out with the help of isKindOf command, or some other thing like that).

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_units = []

_vehicles = []

{ If( _x isKindOf "Man" ) Then { _units = _units + [_x] } Else { _vehicles = _vehicles + [_x]; _units = _units + (crew _x) } } ForEach Vehicles

...not tested, there may be bugs.

Share this post


Link to post
Share on other sites

Nope, those variables have been scripted in the VBS core, but with scripted triggers it should not be a problem to add some self-made variables to ArmA. smile_o.gif

Share this post


Link to post
Share on other sites

The beauty of the config approach was that it worked more reliable. Now with triggers or the vehicles command, you never know whether you really got all units because one might just have gone out of a vehicle right after you collected the vehicles.

Share this post


Link to post
Share on other sites
The beauty of the config approach was that it worked more reliable. Now with triggers or the vehicles command, you never know whether you really got all units because one might just have gone out of a vehicle right after you collected the vehicles.

you can easily get rid of that potential situation by making it to be an SQF function

Share this post


Link to post
Share on other sites
Quote[/b] ]you can easily get rid of that potential situation by making it to be an SQF function

The vehicles command only returns vehicles and not units, as far as I can tell. There is a post about it somewhere. But if it did, then a function launched from an objects init field should be just as fast as a config init event.

Quote[/b] ]The beauty of the config approach was that it worked more reliable. Now with triggers or the vehicles command, you never know whether you really got all units because one might just have gone out of a vehicle right after you collected the vehicles.

With the vehicles command not returning infantry. The config approach is better in some respects, certainly for the likes of big Mods e.t.c But for everyone else you have the problem of how to add the functions to the default Arma unit configs. Without creating new class names.

I think the vehicles command could be the best solution, assuming it's going to be fixed? It would be even better if it returned the same array, in the correct order, on all the clients and the server. Although how you would handle this with JIP, I'm not sure.

Share this post


Link to post
Share on other sites
Quote[/b] ]you can easily get rid of that potential situation by making it to be an SQF function

The vehicles command only returns vehicles and not units, as far as I can tell. There is a post about it somewhere. But if it did, then a function launched from an objects init field should be just as fast as a config init event.

Oooops! You are right, i did a test, and it really returns only vehicles.

I have added it to the notes in the Wiki.

Share this post


Link to post
Share on other sites

So, hang on, does vehicles return only vehicles (of thw wheeled / winged / tracked) variety, and not infantry? The biki would appear to suggest otherwise (still) ...

If so, can anyone suggest an expression that can give us all the infantry in a mission (don't worry about JIP for now)?

- Fer <TZW> smile_o.gif

Share this post


Link to post
Share on other sites
So, hang on, does vehicles return only vehicles (of thw wheeled / winged / tracked) variety, and not infantry? The biki would appear to suggest otherwise (still) ...

If so, can anyone suggest an expression that can give us all the infantry in a mission (don't worry about JIP for now)?

- Fer <TZW> smile_o.gif

I can write you a little function for that... wink_o.gif

Share this post


Link to post
Share on other sites

hey fer,

you could experiment with this, might not be efficient in end product ,depends what you want to do with the array.

_mim = Nearestobjects [_watcher,["SoldierWB"],1000]

returns allwest men within 1000 of start co -ords (or _watcher in this case )

replacing soldierwb with CAManBase, should return any men or at least Man will.

SoldierEB will return east soldiers

SoldierGB for guer

ans civilian blah blah

obviously increasing 1000 will increase search area

Share this post


Link to post
Share on other sites

Played around a bit with it:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_trigg = createTrigger ["EmptyDetector", [5000, 5000, 0]];

_trigg setTriggerActivation ["ANY", "PRESENT", true];

_trigg setTriggerArea [20000, 20000, 0, false];

_trigg setTriggerStatements ["this", "", ""];

sleep 2;

_men = [];

{if (_x isKindOf "CAManBase") then {_men = _men + [_x]}} forEach list _trigg;

hint str _men; smile_o.gif

/edit: fixed a bug in the if line (a r too much at the end of the line)... whistle.gif

Share this post


Link to post
Share on other sites

Thanks, Raedor - you're a star! smile_o.gif

Share this post


Link to post
Share on other sites

Will this cat get a coopA template for Arma? i really loved using it before, its was just so nicelly put together, organised and well thought, nothing beats a well though, fully functional coop map notworthy.gif .

Share this post


Link to post
Share on other sites
Will this cat get a coopA template for Arma? i really loved using it before, its was just so nicelly put together, organised and well thought, nothing beats a well though, fully functional coop map notworthy.gif .

LOL - you read my mind wink_o.gif Yes, I am indeed working on an ArmA version of the CoopA template (although there is going to a new name, and a slightly different focus). BTW, if you would like to help me with the project, please drop me a PM for more information.

- Fer <TZW> smile_o.gif

Share this post


Link to post
Share on other sites
Will this cat get a coopA template for Arma? i really loved using it before, its was just so nicelly put together, organised and well thought, nothing beats a well though, fully functional coop map notworthy.gif .

LOL - you read my mind wink_o.gif Yes, I am indeed working on an ArmA version of the CoopA template (although there is going to a new name, and a slightly different focus). BTW, if you would like to help me with the project, please drop me a PM for more information.

- Fer <TZW> smile_o.gif

Im way too ignorant to be of much help im afraid biggrin_o.gif . But i'll definetly make some compliant scenarios (im never out of mission ideas), if i were to continue editing for the other game i would definetly keep using the cA, its a great compilation/concept and its even newbie friendly.

This is something i look forward to more than addons smile_o.gif .

Share this post


Link to post
Share on other sites

TBH, the new framework (to be called f), is much less closely married to the CoopA dogma. What I found with CoopA was that some - perhaps many - people found the dogma a little too restrictive, and that put them off using the original kit.

For ArmA, and specifically for f, I want to create a framework that makes it easy for mission-makers to concentrate on their own ideas by taking care of issues like having a clean briefing file, or automatic removal of dead bodies etc. That means de-coupling the template from any specific dogma, but keeping all the little things that make it easy to start assembling a mission with good features - like selectable time, weather and AI skill levels, and the end-trigger system we developed.

The other really important aspect - which will be kept - is the that of writing nicely commented code and backing that up with documentation that explains how to configure / use each component in the framework. Personally, I am no scripting genius - I learnt what little I know because other scripters wrote notes, tutorials, or answered questions in forums. For f, like the original CoopA Foundation Template, I want the accompanying documentation to help even relative newcomers to understand the mechanics of what they are building.

And what of CoopA? It's still there if anyone wants to try and build missions for it. There might just be a CoopA1 in the works too ... wink_o.gif

- Fer <TZW> smile_o.gif

Share this post


Link to post
Share on other sites
TBH, the new framework (to be called f), is much less closely married to the CoopA dogma. What I found with CoopA was that some - perhaps many - people found the dogma a little too restrictive, and that put them off using the original kit.

For ArmA, and specifically for f, I want to create a framework that makes it easy for mission-makers to concentrate on their own ideas by taking care of issues like having a clean briefing file, or automatic removal of dead bodies etc. That means de-coupling the template from any specific dogma, but keeping all the little things that make it easy to start assembling a mission with good features - like selectable time, weather and AI skill levels, and the end-trigger system we developed.

The other really important aspect - which will be kept - is the that of writing nicely commented code and backing that up with documentation that explains how to configure / use each component in the framework. Personally, I am no scripting genius - I learnt what little I know because other scripters wrote notes, tutorials, or answered questions in forums. For f, like the original CoopA Foundation Template, I want the accompanying documentation to help even relative newcomers to understand the mechanics of what they are building.

And what of CoopA? It's still there if anyone wants to try and build missions for it. There might just be a CoopA1 in the works too ... wink_o.gif

- Fer <TZW> smile_o.gif

The coopA wasnt/isnt all that restrictive m8, it was perhaps demanding but in a positive way, it required a bit of extra effort that would pay off in the final result (imo), if it didnt kick it was more likely due to:

[*] Very few editors.

[*] Editors used to do things their own way.

[*] People not taking ME all that seriously*.

This shows by the amount of broken missions out there..

With Arma and a much larger coop editing comunity it should kick smile_o.gif .

* Start here, ammo crates and vehicles here, kill enemies here, here and there and maybe it will end...

Share this post


Link to post
Share on other sites

Well, let me get the first cut of f released (at least in beta), and then I shalll see about updating CoopA for ArmA - I think we can make one or two small modifcations to the dogma to create CoopA1 (there is at least one tweak I want to make). Watch this space ...

- Fer <TZW> smile_o.gif

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×