Scripting

[Deadfast 43]

That kinda misses the point of what g-c was asking for.

[Lou Montana 101]

Ah yes, now you say it... I completely misunderstood him (but hey, you did the same ! :p)

Now I see... and what we need is the ability to create our own functions, this could solve almost everything !

[Deadfast 43]

What are you talking about?

You indeed can create your own functions.

[Lou Montana 101]

Wow, yeah, I was tired, I forgot about sqf calling... maybe I was thinking about something like "isRunning player", nevermind.

[MulleDK19 21]

I want Lua!!!

[NeoArmageddon 957]

I would like to see some more VBS2 commands (yes i know... some are already in ArmA2).

respawn and revive command would be great!

Also i need more commands for multiplayercontrol: starting and closing scripts on all clients from server for example.

P.S. Lua is good for counterstrike not for arma! In arma this language would suck!

Sqf for the win!

[Issetea 0]

Although i think that this could be useful I didn't find a suggestion for it yet:

A command for sending something to a single client only. PublicVariable is a useful command but i guess it produces a lot of lag if a single client wants to communicate with the server and everyone else receives the same (for them useless) data. Something like "Variable" sendTo PlayerObj would be nice.

[phunkmaz 3]

Whats about attachTo including the option to bound 2 objs with robe physics ? :bounce3:

Edited June 7, 2009 by PhunkMaZ

[CarlGustaffa 4]

Some missions use a library of functions to do stuff the original command doesn't cover. How about BIS take a look at these and implement those that have generalized function value into ArmA2 as new commands?

Quoting myself, but, yeah, great collection of functions there guys :D

@d3nn16:

markerShape is there.

isAdmin is still missing...

@MulleDK19:

Get OFP DR if you want lua :) I would hate having to learn a new language now :)

[Ravice 10]

I think that scripting in arma 2 should be simplified like Microsoft Windows simplifies DOS. "POINT AND CLICK INTERFACE." There should be a point and click interface that covers all the scripting in the game without the player having to memorize anything. A 5 year old should be able to script an entire cutscene, a helicopter landing and pickup sequence, enemies dropping their weapons when you arrive, music played in an object, all without having to manipulate files or download tutorials, and all compliments of an easy to use point and click interface. I'm talking paradropping extra equipment, calling in bombings, calling in evacs, calling in mortar support, kinda like that one addon. I'm talking everything that can be done in the game should require no typing whatsoever. It should all be simple point and click. Focus on "point and click interface" and everything should work out fine.

Also this work make the game sell more, as more players like my self who have got some good idears, and no nothing about scripting bye the game.

I have had all the games, and have just been put of by the fact that i cant make good missions.

Ravice

[Maximus2015 10]

I would suggest, that in the future patch for ArmA 2 they update function setFriend, that it can be used as side1 setFriend [side2, value], and faction1 setFriend [faction2, value] to set one faction enemy for other, or one to friend other. Just this game does not suffice. (Sorry for my bad english iam living in Russia)

[sig 10]

If this hasnt been reported before; can the dev team sort out the script where a vehicle explodes and then two mins later it expplodes again.

[Zipper5 74]

If this hasnt been reported before; can the dev team sort out the script where a vehicle explodes and then two mins later it expplodes again.

You do know that those are supposed to be secondary explosions? As in the ammunition being ignited and exploding? It's exactly how it happens in real life.

[sig 10]

You do know that those are supposed to be secondary explosions? As in the ammunition being ignited and exploding? It's exactly how it happens in real life.

Its a bug! Ammunition doesn't blowup 3 & 4 times after a wagon or BMP's been hit.

[Big Dawg KS 6]

BIS definately mentioned it as a feature.

I want Lua!!!

Ew...

I think that scripting in arma 2 should be simplified like Microsoft Windows simplifies DOS. "POINT AND CLICK INTERFACE." There should be a point and click interface that covers all the scripting in the game without the player having to memorize anything. A 5 year old should be able to script an entire cutscene, a helicopter landing and pickup sequence, enemies dropping their weapons when you arrive, music played in an object, all without having to manipulate files or download tutorials, and all compliments of an easy to use point and click interface. I'm talking paradropping extra equipment, calling in bombings, calling in evacs, calling in mortar support, kinda like that one addon. I'm talking everything that can be done in the game should require no typing whatsoever. It should all be simple point and click. Focus on "point and click interface" and everything should work out fine.

I really hope that you're being sarcastic. You can't expect a 5 year old to do shit, why should he be able to make good missions? I can't see what your problem is, using waypoints and triggers (which are very point and click) are more than enough to do basic stuff. What you're asking for is an easy way to do advanced editing? Why don't you stop being so lazy and actually learn how to do it. You can't expect good results if you're not willing to put any effort in. Do you think BIS developed ArmA2 with a handy point and click "game creator" tool? I'm sure they spent many, many hours slaving over code to make the best damn game they could. What kind of future do you expect the world will have if everything becomes so dumbed down that we don't have to learn anything for ourselves anymore?

[rübe 127]

isFlatEmpty is nice and all except it lacks one important argument: it can check whether a position is on water, even if its on the shore, but what it can not tell you is whether your position is on an island or not! And this is a highly important information for a random position or you could end up spawning troops there with waypoints back to the mainland, and thus your poor troops have to swimm there, haha :D

Ok, with Chernarus, this maybe not that critical. But with all the maps/islands to come, I'm pretty sure this would come in very handy. Especially maps with lots of islands and one big mainland could also profit from such a scriptable distinction in a `positive` way. Though I'm not sure if there is already a distinction between mainland and islands, somewhere down the config-files... hm, thinking of it, it maybe even better to also take an additional position/object argument, to identify which island/mainland we speek of. Indeed.

In conclusion we need one additional argument for this function: onIsland of type array with a position/object and a number:

• island-identifier (position or object)
  
• island mode (number)
  
  • 0 = cannot be on this island
    
  • 1 = can or not be on this island
    
  • 2 = has to be on this very island
    

Deal? ;)

Edit: Here you can see cleary, why we need this:

Edited July 9, 2009 by ruebe
adding illustration

[Cato Larsen 10]

To be honest I would like a script that removes the need of having tons of scripts :p

System hugging and dedicated server killer.

Best ways to have a good mission is to use as little scripts as possible.

Oh just go ahead and rant me :p

Its friday and the sun shines, I am bored at work and just needed to type something :)

[rübe 127]

Please pimp getPosASL to also accept positions (that is any 2d-position, taking the ground-level there) instead of only objects.

IMHO this is pretty important. Have you ever tried to find a good position eg. for a MG/Grenadier-Nest? Dynamically? Of course you'd like to place this thing pointing at a main position (dirTo, voila) but also elevated/higher than this main position (to higher the chances that this thing actually can see/shoot something). Thus you wanna compare the absolute height (above sealevel) of two positions.

Now since getPosASL only works with objects, you're likely doomed to spawn an object there and do some science like in newton's days, hehe. This situation is unacceptable.

The best I came up with is this (I hadn't much luck with nearestObject because its radius is too tiny):

getPosHeight = { 
  _obj = (nearestObjects [_this, ["All"], 500]) select 0;
  ((getPosASL _obj) select 2)
};

Which actually works pretty convincing. Though I see many problems with this approach.

Backward compatibility is guaranteed with such an improvement in a future patch. And it shouldn't be too much work either to make getPosASL accept positions. Actually I'm pretty surprised that nothing like this is in the BIS function library already.

hm, and while still in *gimme-gimme-gimme*-mode, hehe, what about a new function, which could determine if obj1/vehicle1/pos1 can directly see obj2/vehicle2/pos2? Perhaps with an optional argument in case you pass positions for the assumed height (default could be the height of a standing units head). As a result from such a function I'd like to get a value from 0 to 1, where 0 means I cant see shit, and 1 means I can see obj2/vehicle2 very cleary/fully. That would be sweet.

Just think of the possibilities such a tool would open to us immediately:

_groupAttackGroup = {
  _attackerGroup = _this select 0;
  _targetGroup = _this select 1;

  _attackerPool = units _attackerGroup;

  {
     _target = _x;
     _assignedTo = [objNull, 0, 0];  // unit, feasibility-value, array-index
     _i = 0;
     {
        _feasibility = _x canSee _target; // which should return a value betwen 0 and 1
        if (_feasibility > (_assignedTo select 1)) then
        {
           _assignedTo = [_x, _feasibility, _i];
        };
        _i = _i + 1;
     } forEach _attackerPool;

     // order the unit with the best chances for a shot
     if ((_assignedTo select 1) != 0) then
     {
        (_assignedTo select 0) doTarget _target;
        (_assignedTo select 0) doFire _target;
        // remove this unit from the attackerPool
        [_attackerPool, (_assignedTo select 2)] call BIS_fnc_removeIndex;
     };

     // if our attackerPool is empty, there is nothing left to do
     // we could also return the targets that couldn't be addressed or/and the unused attackers, etc..
     if ((count _attackerPool) == 0) exitWith {};

  } forEach (units _targetGroup); 
};

Now is this sweet or not? Let a group attack another group, and that the unit with the best chances of a good shot gets at each target.

Now think of this canSee-function in combination with positions. Let there be a group at distance from a target-area. Now we toss the dice to get several positions between our group and the target-area (taking in account the relative position, etc..) and then we compare these positions like in the above example and choose the position with the best `view` on the target area... for our dynamic attack-waypoint, or what ever. We could first look if we can find an elevated position in relation to the target-area and then do the canSee check...

Or the above example could be enhacend to first toss the dice to get positions reasonable to attack the target in question, then do the canSee-check, send him with combatMode BLUE to the best position and then order him to attack etc...

As for canSee with positions, a height-position above ground would be essential. Eg. to determine if a unit at this position would be still usefull if prone or kneeling! Thus an alternative syntax would be handy, like:

  _valueStandUp = canSee [[pos1, 1.7], [pos2, 0]];
  _valueKneel = canSee [[pos1, 1.1], [pos2, 0]];
  _valueProne = canSee [[pos1, 0.2], [pos2, 0]];

   // hm, or even better like this:
   _value = [pos1, 1.7] canSee tank2;

where the ray to test for _value 1 would be shot from [pos1_x, pos1_y, 1.7] to [pos2_x, pos2_y, 0]. Beautiful ain't it? :D

I could go on, how usefull these both informations would be (absolute height and the canSee-value). And I will close my request with: Please? ;)

Edited July 11, 2009 by ruebe
Elaborating, ...

[code34 248]

i need just a debug console (..)

press the key "²" and see the content of log rpt inside game (..)

Don't understand why errors of p3d official files flood logs.

I don't know how to debug with arma 2 for the moment as there is not anymore log available in game.

Edited July 15, 2009 by code34

[rübe 127]

A command like boundingBox is a requisite for a lot of scripting ideas. But the moment objects start to have a hole hill attached to their bottom, this command certainly loses any validity, rendering boundingBox pretty much useless, or unreliable at best.

There were problems with this command before this (antennas, etc..), so indeed, ideally there would be a new command, returning the boundingBox that actually matters and mostly everyone is interested in.

I guess that ain't gonna happen any time soon. So I suggest the following as a compromise: Please don't attach those hill's to any buildings, resp. remove them from the warefare buildings (have you ever noticed? they are like 5 meters deep/high(!) which renders the boundingBoxes HUGE! really).

Yes, it's actually a pretty good idea to have those (things turn ugly without them when it gets too steep, we all know), but this actual solution is IMHO pretty poor, imprudent to say at least.

So we have a world, that generates new random land at its borders. Thats groovie and all. It would have been even more usefull, to apply this idea to places more in need: if those hills (under the warefare buildings) I speak of were generated randomly too, that would have been great. That is, any building should have such an artificial hill beneath it, if terrain/slope requires it! Or make it an option. And those hills could make a call to the boundingBox of the building and thus generate a hill wich would match - any building. Problem solved. Once and for all.

It's so silly to create those hills for each object in the first place, if you could have done the hill once (that is, the recepie/algorithm for a hill) and end up with a solution which every building would benefit from.

^^ also, this wouldn't have rendered boundingBox even more useless :/

Edited July 16, 2009 by ruebe

[d3nn16 3]

I would like to have 2 scripting functions that allow to add magazines/weapons to all turrets in a vehicle not just the main turret as it is the case at the moment with addMagazine and addWeapon commands.

For example :

[vehicle, <turret path>] addWeaponTurret "weapon"

[vehicle, <turret path>] addMagazineTurret "magazine"

Other commands I'd like to have is setAmmo (complementary to ammo) which will set the number of rounds in the current magazine and maxAmmo which will return the max number of rounds of the current magazine.

I also want to say the rearming system is bugged and needs some attention :

addMagazine, addWeapon, clearMagazineCargo, clearWeaponCargo effects are not visible to JIP players;

setVehicleAmmo 1 doesn't rearm vehicle if executed after setVehicleAmmo 0;

ammo trucks only rearm current magazines in vehicles without adding the initial number of magazines;

addMagazine can add an infinite amount of magazines to vehicle or soldier;

Another solution would be to make vehicle weapon magazines as infantry weapon magazines : objects that can be put in a vehicle ammo cargo and taken from cargo to reload vehicle weapon.

Edited July 17, 2009 by d3nn16

[rübe 127]

setSpeedMode should work too for single units. Also a unit in "LIMITED" speedMode should never run if you doMove/commandMove it.

[charon productions 10]

I would like to suggest a way to solve your problem with another addition, currentTarget and targetOf functions.

_unit currentTarget would return the current target of the unit if possible.

_unit targetOf would return the array of units which are known to be targetting the _unit at the time.

It would require the storing of this information, but together with the hit or fired EHs it can be used to determine under fire for anyone.

This would be really great! Very hard to determine the target

a unit is actually firing upon especially when the target is dead and there is no reference anymore.

Or an additional -target parameter maybe in the "fired" Eventhandler.

That would be very much appreciated by a lot of people.

[CarlGustaffa 4]

disableAI "MOVE" also disables rotation (only tested with unit being forced prone), making it a rather disturbing command. A sniper you want "hidden" will not be able to target targets that is outside of his "aiming arc".

So, I suggest the following for disableAI and enableAI:

"ROTATE" - determines the units ability to turn or not.

Problem is "MOVE". Should new behavior be put in, possibly breaking backward compatibility? Or should it stay the same and have a new "TRANSLATE" which only works with moving but doesn't touch rotating?

If new behavior is put in for "MOVE", it could possibly fix some missions where the behavior of the command was not known. On the other hand, it might be used effectively in order to achieve a proper scan. Dunno.

[Jonescrusher 10]

Would love to see getMarkerDir and setMarkerAttached in Arma 2.