Scripting

Use this thread to add suggestions for new script commands and new functionallity.

----------------------------------------------------------
My top wishes:
1) setNormal and getNormal functions that set and return the normal (vector) to an object ***(i.e to get and set pitch, bank and roll)
2) saveString and saveObject functions to save strings and objects to files.
3) Basic string functions such as charAt(pos) strcat, strcmp etc etc
4) Explicit commands that bypass the behavioral AI such as target,fire, move etc

[Schoeler]

We should be able to parse strings too.

[Junker]

Just a thought but couldnt you implement most of the best scripts about into the game ??
Then make a list of what and how to activate them and what there for ?

[Kegetys]

I would very much like it if the whole scriptin thing would be changed into a object based thing, for example instead of doing

someUnit setDammage 1

I would do something like

someUnit.damage = 1

or, instead of

? (getpos someUnit) select 2 > 2 : hint "we are airborne!"

I would do

? someUnit.pos.Z > 2 : player.showMessage "we are airborne!"


Each object could have different parameters and functions in it, this way I think it would be much more clearer to use as there wouldnt be hundreds of commands of which only some are useable on a certain type of object.

[bn880]

Ability to pass any arrays by value, to allow for use of arrays in recursive functions.


More overall access to gamestate for scripters ie:
getDamage that returns damage of all components on vehicle
getEnvironment (date,rain,overcast,etc.)
bindKey function (bind scripts to a key or combination on keyboard)
Network sharing of all data types if possible (coming to OFP1 anyway but complicated)
More information on human players in some accessible data array, to eliminate the need for scripted network handshaking.
Full access to AI functions/sensing, to allow for scripted learning AI. (longshot I guess) As it is AI has so much of it's own brain it's nearly impossible to control it manually.
object (#) function that returns objNull instead of crash on non existing objects
All terrain objects such as trees and bushes to be in some vehicle heriarchy like tanks and units to be analysed in script
bleedingRate function to set the rate at witch the soldier bleeds unless 1st aid is applied http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/wink.gif

[mads bahrt]

Make it possible to make the mission time of day follow the server time of day (or just a designated timezone - maybe also latitude affecting sunrise/dawn). This would be harder, but it would also be nice to make the mission weather follow real world weather - this would require looking in a weather database (if such one exists) for the weather at a selected position.

The great effect in this is that it makes the missions vary greatly depending on the current weather, and thereby changing the user experience. It shouldn't be enforced, but should be a option for mission makers.

[bn880]

Make it possible to make the mission time of day follow the server time of day...
This is already possible through the use of missionStart command in the mission. I have already implemented this in some missions of mine.

There rest is not. http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/smile.gif

A re-introduction of allowDamage would be nice http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/smile.gif

[granQ]

"allowradio"

or something. This would make it impossible to use the radio, or see sidechannel chatting if "false". Could be very nice for missions and make (distant radio) < 200 : allowradio myguy false

or something like that. Maybe not the ofp team wants, or the public but since i will soon do my conscript service and probaly doing something with radio/communications, i been thinking about it alot http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/wink.gif

EDIT: Not sure if this is the right place. But would be great if you could set the "respawn weapon" of the soldier. Working on a swedish forces addon and boring that i have to choose ak74, m16 or ak47 for respawn weapon and can&#39;t put the AK5 (FN FNC)..

[bn880]

Almost forgot about this completely,
ability to getMarker text and setMarker text. Why not? And createVehicle marker... lol you know what I mean

Also full control of triggers from scripts. (Ability to create a trigger, resize it, set all attributes, main enable/disable)

On a side note, how about drawing of markers like with paint etc, so that you can make all shaped outlines of areas etc, fill them in or not. http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/confused.gif http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/smile.gif

[MintyBoy]

Dynamic Waypoint scripting. eg. CreateWP, setWPType, SetWP#, SetWPRadius, etc

[uiox]

CaseOf CtrlInUse 100

{

*** *** ***(TypeOf (CharToReal (CtrlText 100))) &#33;= "Float": ctrlSetText [100,""] ; hint "Bad number"
*** *** ***CtrlText 100 == "uiox sucks" : endcase; closedialog 0
*** *** ***endcase*** *** ***

}

[hoz]

I like to see:

The ability to set specialized WP&#39;s like the in editor such as S&D.
I&#39;d like a better debug interface maybe a popup box to watch in the editor. Sometimes big command errors are lost or fly by. Better yet an error.log would be great.

I&#39;d also like the createmarker on the fly idea along with setmarkertext.

Hoz

[Schoeler]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (bn880 @ 28 April 2003,18:27)</td></tr><tr><td id="QUOTE">Almost forgot about this completely,
ability to getMarker text and setMarker text. ***Why not? ***And createVehicle marker... lol ***you know what I mean

Also full control of triggers from scripts. ***(Ability to create a trigger, resize it, set all attributes, main enable/disable)

On a side note, how about drawing of markers like with paint etc, so that you can make all shaped outlines of areas etc, fill them in or not. ***http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/confused.gif ***http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/smile.gif[/QUOTE]<span id='postcolor'>
Absolutely, that&#39;s why I want to be able to parse strings.

We should be able to dynamically reset waypoints and trigger functions through scripting. Its just way more efficient.

[jacobaby]

A means to get the current environment status would be good.

Also wind factors affecting vehicles/trajectories......

And vehicles that dont make dust in the rain or after rain, maybe replace it with spray.

Init eventhandlers from CPP&#39;s to run correctly on all clients (make that ALL the eventhandlers)

Ability to identify unit who has you as target.

But more importantly as far as addon making goes....even if the game is set in history, to make the ability available for us to simulate modern weapons better, with their capabilities.

In built script editor into the editor itself.

More than anything GetPitch/roll/bank etc of an object.

Command "switchside" to enable units to change sides.

Ability to change player camera to another unit mid game, to make possible multirole missions.

Error.log text dump for those messages which fill the screen and cant be read.

deployable light sources eg torches, TACs and better management of projected lighting.

A range of built in fire/ explosion/ damage /smoke/ lighting features mission makers can use, similar to what BAS have done with the recent addons.

Ability to command more than 12, or to command other groups.

Netcode that plays like BHD............. http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/confused.gif

and so on.....

TJ

[Schoeler]

There should be some simple way of seeing if an enemy knows about the player&#39;s location. This would be of tremendous help in writing scripts that enable enemy AI units to call in artillery and airstrikes on the player and player&#39;s units.

[jacobaby]

Hmm, Schoeler,

Have you tried using KNOWSABOUT?

Here is a line you can use to see how the "knowledge" of the enemy increases the more they know about you.

It would now be very easy to use this variable to determine if enemy should be able to call arty strike etc.


hint format ["q1 knows %1", q1 knowsAbout player]

You will need an enemy unit called Q1 and yourself.

TJ

[The_Captain]

I want forcemap, shownmap and showmap commands that

1) Control the map with a boolean, set to on or off

2) Force the map to be displayed independant of pressing the m key (not the normal forcemap overlay)

3) Detect if the map is displayed or not.


These commands would be INCREDIBLY useful for sripting functions that require the map to be turned on or off. For example, dialogs that come up when you go into the map screen, close the map when you exit them, or scripts that keep the map on screen until the player takes some action, like clicking.

This would streamline custom insterfaces considerably...

[uiox]

These commands would be INCREDIBLY useful for sripting functions that require the map to be turned on or off. For example, dialogs that come up when you go into the map screen, close the map when you exit them, or scripts that keep the map on screen until the player takes some action, like clicking.

This would streamline custom insterfaces considerably...
And during a dialog can move the map or zoom in it, if we don't have during game dialogs, have during map dialogs, very usefull for design a C&H the island missions...


About strings:
Scripters have to debate about this.

My point of view:
Create a limitation of 256 characters, so we have string, not text.
Don't care about minusc and majusc, (not case sensitive in English?)
No idea for the moment for ascii characters...

Commands:

PosString
_Pos = PosString ["ca","abcabc"]
_pos == 3, return always first find

Length
_Length = length "OFP2 2004"
_Lenght == 9

Substring
_Result = SubString ["abcde",2,3]
_result == "bcd"

[Romolus]

Simplify MP scripting.

It shouldn&#39;t depend where you use commands if they are working or not. The need for some commands to be executed where an object is local is making MP scripting verry complicated, especially with the actual system how and where actions and eventhandlers can be used.

[peanuckle_00]

I think that scripting in ofp 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&#39;m talking paradropping extra equipment, calling in bombings, calling in evacs, calling in mortar support, kinda like that one addon. I&#39;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.

[uiox]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Romolus @ 06 May 2003,00:37)</td></tr><tr><td id="QUOTE">Simplify MP scripting.

It shouldn&#39;t depend where you use commands if they are working or not. The need for some commands to be executed where an object is local is making MP scripting verry complicated, especially with the actual system how and where actions and eventhandlers can be used.[/QUOTE]<span id='postcolor'>
Simplify? In OFP1 you can&#39;t really script MP.

Why? Cause with triggers and WP you can solve and script VERY GOOD MP MISSIONS.

A lot of awesome MP missions are done without script.

We want more, and BI ear, and understand what we want.

BUT if you want more, ***you are in the scripter domain, so learn yourself.

Ask to our masters how many hours for understanding a little part of OFP.
It&#39;s a choice of BI, don&#39;t forget OFP is a game, not an operating system.

First we buy, play with it, after we script (for a very little part of us).

I&#39;m a gamer, for me OFP is a very good game, if in OFP2 I will have pleasure of playing : win for BI.

PS: MP scripting does not exist in OFP1, it&#39;s an invention of our scripting gurus.

PS2; I agree with you if you say : create mp scripting

[Romolus]

It&#39;s not the MP mission scripting I&#39;m concerned about it&#39;s the scripts that are included in addons for advanced features.

In addon scripting you can&#39;t use triggers and such editor depending things, you only can use the scripting language. There are many advanced features possible in the game that work perfect in SP but are in the easiest case a real pain to get them working properly in MP and in some cases simply impossible to do.

The whole addon install issue is made even worse when the mission designer has to place gamelogics or fill in some scripting code in the init field of some units just to make the advanced features work.
So simplifying the MP scripting should also be part of the enhancements for addon handling, not just easy installing.

Allmost every higher quality addon that&#39;s been released in the past had some sort of advanced scripted features and the tendency to include more scripted features is still growing.
Nothing is won when the addons install really easy and the mission designer has quite a hard time to get the addon to work in the mission just because of the way scripts in addons have to be done for multiplayer.

[bn880]

One thing most of us at the CoC also would like to suggest is that the init EH in addons actually fires on all machines.

If not all the EH&#39;s, since it is easier to say : ?(not local (_this select 0)): exit;
than have to create a network communication solution.

Please support the same comment syntax /* */ and // in loadFile as in preProcessFile. Sorry to say I lost a bit of time wondering what the heck was going wrong when converting some NS code to an addon. http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/crazy.gif http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/smile.gif

Please add that access to system time/date both in SP and MP mission. Perhaps setDateTime function is possible? http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/tounge.gif

[Rune]

I&#39;d like a simple command to save a variable used in multiplayer for the next game with same mission(and maybe same server).

If there was a command to save a boolean value to indicate if the mission was played before, difficulty could be higher the second time around. Or it would be possible to make one mission into a sort of a campaign by saving the numbers of units left for the next time. It could even be extended to singleplayer and/or campaigns to allow some sort of replaying a mission without &#39;starting over&#39; for improving realism. - &#39;take out the tanks&#39; ...play mission... &#39;go back and finish the job&#39;... play mission again.

The possibilities are endless, and it would be possible to make missions with even higher replayability than now.

[raedor]

it would be great if in ofp2 are new scripting commands like
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">unitName getStatus == standing/lying
e.g.&#58;
if &#40;getStatus player == standing&#41; then {player playMove &#34;CombatToPutDown&#34;} else {player playMove &#34;PutDownLyingToLying&#34;}[/QUOTE]<span id='postcolor'>
or if it would be possible to set trigger options like
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">triggerName setAxis &#91;axis, number&#93;
e.g.&#58;
trigger1 setAxis &#91;a,50&#93;
or
triggerName setActivation &#91;side, class&#93;
e.g.&#58;
trigger1 setActivation &#91;&#34;west&#34;,&#34;tank&#34;&#93;[/QUOTE]<span id='postcolor'>

[Rune]

It would be a great improvement in scripting freedom if a command like setAccTime would work in multiplayer. I realize that there are problems, but the benefits would be great both in making big/long missions and in enabling group &#39;Max Payne&#39; shootouts.

For everyone to change at the same time, the machine calling setAccTime could negotiate the correct timing with the highest ping machine in the game and then broadcast it to everyone, so nothing gets out of sync - or will it anyway?

Don&#39;t leave it out just because you don&#39;t think anyone would want it or because it is very easy to make crap missions with it.

[uiox]

Have the possibilty to create a variable with the ID of object.

Call format ["upDateList%1 = [] ",self(object)]

You can&#39;t build a global variable for each of object of a same addon.

Or global variable relates to an object.

[Cannon Fodder]

A cut and paste &#39;Script Board&#39; that you could simply take a piece of code out of a reference book and paste it into your mission might be a good idea. Therefore you wouldn&#39;t require an encyclopedic knowledge of scripting commands, encourage inexperienced mission authors into using more complex mission structures and also improve the general quality of missions aailable to download&#33;

Even better was an idea suggested by Peaknuckle a little earlier about a &#39;Point and Click&#39; interface, although perhaps a brief explanation of what each piece of code does and the order in which it should appear (syntax) would be needed (perhaps in a tool-tip style when you hover the mouse over it?)?

[raedor]

no, i dont think that a "point and click" interface is a good idea... only if it would be possible to make scripts like now.

u wont have so much possibilities to script with a "point and click" interface, but it may be easier for beginners...

[as-33]

I don&#39;t think that point-and-click-"scripting" would be useful. More important: get rid of that horrible scripting syntax. An object oriented language similar to Ruby would be perfect.

Example
If you want to heal everybody in a group you could simply write:

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">
defenders.each { &#124;unit&#124;
unit.damage = 0
unit.sayRadio&#40;&#34;I feel great&#33;&#34;&#41;
}
[/QUOTE]<span id='postcolor'>

defenders.each makes that the following block is executed for every unit in group defenders. The &#124;unit&#124; tells the parser by which name the object can be accessed in the block.

Great?

[tracy_t]

An UnderFire() routine, returning a boolean value indicating whether the unit is taking fire, would be appreciated. That way, we could script some of the more complex AI ourselves.

I know there is a "IncomingMissile" event handler but it&#39;s not the same.


ex:
? myAISoldier UnderFire() == true: myAISolder TakeCover(NEAREST_BUILDING)

where NEAREST_BUILDING is a predefined BIS constant. And yes, TakeCover is a predefined function http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/smile.gif

Obviously, UnderFire() would return false later, if the unit had not taken fire for a predetermined length of time, or the unit was sufficiently far away from the area of fire.

Maybe a FireDirection() function could return a rough angle from where the AI unit believes the fire to be coming from.

Regards,
T.

BTW: Why not have Visual Basic style script with an AutoComplete&#39;ing IDE? That way even the idiots can script.

[raedor]

if u add to every enemy unit an eventHandler "Fired" and u write in the first line of the script which is opened by eventHandler
? (_this select 0) distance player < 100: underFire = true
u have what u need.
or u can do it with knowsabout. or u add an eventhandler "hit" to the player.

p.s.: there already IS a command nearestBuilding:
nearestBuilding obj
Operand types:
*** ***obj: Object
Type of returned value:
*** ***Object
Description:
*** ***Nearest building to given object.

Example:
*** ***nearestBuilding player

[tracy_t]

Yes. But in the Fired event handler, how do you know they are firing *at* you? What if you have a team and you want them to sneak up on a group, that are shooting in the opposite direction. You would have to determine the angle the shooter is facing (with GetDir I suppose.) to see if he is pointing in roughly your direction. This script becomes more complex when you have multiple shooters, I suppose.

I forgot about the NearestObject function though http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/biggrin.gif

[bn880]

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. http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/confused.gif

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.

[tracy_t]

Hi Bn880, nice suggestion.

But, I think the UnderFire() function should be implemented in addition to your suggestions.

I want my soldiers to take cover *only* when they are under fire, not when they are targetted by enemy troops.

What if the enemy troops lying in a state of ambush, and are targetting my soldiers, but they are in a "hold fire" state, meaning they haven&#39;t fired a shot? ***Why should my soldiers run for cover? They might not know they&#39;re being targetted yet&#33; http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/biggrin.gif

PS: I don&#39;t like the fired event handler - it doesn&#39;t tell you where the bullet is aimed at according to the Flashpoint command reference. I suppose you&#39;d have to use NearestObject to get a reference to the bullet and manually work out its trajectory&#33;&#33; Yuk http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/crazy.gif

Cheers,
Tracy.

[bn880]

Yes I was thinking more about it and you are right, underfire could be triggered as soon as any bullet or other seems to be a danger, whether you are an intended target or not.

[uiox]

I have build a draft of radar, for the moment i use a trigger, it&#39;s for my script suite of uv addons, and I&#39;m waiting for the possibility of creating triggers or something with an update list of objects in area in addon scripts.

About targets : a command visible

object1 visible object2 ---&#62; boolean (of course it&#39;s not relate to distance but the possibility relates to terrain (add buildings? great&#33http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/wink.gif )

More relate this to anatomy (eye distance) ,forecast, and daytime.

Cost object ---&#62; Integer of the object cost

GetTheta (with getDir and GetDistance)

And a hook to the Random internal engine for fire (for not having a 100 % good fire), for not rebuild one

Or the nec plus ultra

An event TargetPossible : an array with the right list of ennemies visible

[Rastavovich]

As bn880 said:

- target: returning the currently targeted unit

Other good things would be:

- sidelist: returning all units of a given side, maybe in addition with filters, ie: sidelist ["West", "Air"] returning all western air units

- elseif construct, if, elseif, else...

- aslheight: height above sealevel, but this is not so important

- Possibility to include descriptions.ext in pbo, without need of a #include call in mission description.ext.
In that case a "freeid" command would be handy, returning a number that is free for using as ID.

[toadlife]

Simplify? In OFP1 you can&#39;t really script MP.Why? Cause with triggers and WP you can solve and script VERY GOOD MP MISSIONS.




LMAO. UNPBO my coop version of Operation LoJack and tell me you can&#39;t script in MP. http://forums.bistudio.com/oldsmileys/smile_o.gif

But saying that, yes scripting in MP is a huge pain in the ass. I would love better overall support for the passing of information between the client and server


A lot of awesome MP missions are done without script.

Definitly...unfortuantely many desired effects in a mission can not be acheived using standard waypoints and triggers.


One thing that ohers have mentioned before that I totally agree with is string handling. Currently there is none in OFP. http://forums.bistudio.com/oldsmileys/sad_o.gif We need to be able to work with strings, and also send them as public variables.

It would also be nice to be able to share arrays as public variables too.

The diableradio command should be able to disable the radio for vertain units, as well as everyone...ie

[unit1,unit2,unit3] disabaleradio true

Along with this a "radioenabled" command for querying weather or not the radio is disaabled would be nice accesory to the new and improved disableradio command.

[der bastler]

My scripting suggestion: It should be possible to change the player object ingame. Think of disguising, changing sides, better character class respawn, ...



@Kegetys:
Good idea&#33; Just one thing: According to OOP, it should be
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
if &#40;someunit.damage&#40;&#41; &#62; 0.5&#41;
{
*** someunit.damage&#40;0&#41;;
}
[/QUOTE]
You can get access to the unit&#39;s damage value by using an overloaded method (no parameter: GetDamage behaviour; parameter: SetDamage behaviour). Ensures object encapsulation... http://forums.bistudio.com/oldsmileys/wink_o.gif

[Dirt]

What I would like to see in scripting is a drop down menu in all units, triggers and waypoints to select a script. ***Have the menu direct to a folder in the game so you only have to place the script in the folder once and then just select it in the drop down menu. ***May be even 2 drop downs. One for action and the other the menu.

Example: *** *** ***Action: Death *** ***Script: Scream

Just a thought. http://forums.bistudio.com/oldsmileys/biggrin_o.gif

Extension of the typeOf function to include all super-classes of a unit:
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
type = typeOf&#40;myA10&#41;
[/QUOTE]

That returns:
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
&#91;&#34;All&#34;,&#34;AllVehicles&#34;,&#34;Air&#34;, &#34;Plane&#34;, &#34;A10&#34;&#93;
[/QUOTE]

[toadlife]

It would eb great have scripting commands that return the armour/threat level settings from units.


This would have made my grouplink script much easier to write.

[friendlyfire]

How about allowing the script to make external SQL calls. This would generate a lot of possibilities....

1) modify a running game.
2) easy to store data from one game to influence the next.
3) simultaneous conflicts that have repercussions for each other.
4) would make a persistent battlefield feasable.
5) db could run on another machine reducing server load.
6) you would effectively have the entire status of the island whenever you wanted it - even for the rest of the campaign.
7) easy to write tools to maintain islands/battlefields
8) automated external tools

Limitless possibilities...

[toadlife]

Interesting. MySQL or PostgreSQL would fit the bill. That might be a bit over most mission/campaign editors heads though. :P

[friendlyfire]

OK, but I would suggest that learning a bit of SQL was fairly mild compared to some of the ofp scripting I&#39;ve seen here&#33;

How&#39;s this for another plus... User Missions could query a central db of addons (php site) and update their local addon database with the required info so that you don&#39;t go through the fiasco of trying to make sure all players know what to get from where, and how to install it.

And rather than load all of the addons at startup they are included from your local addon database when you select the mission.

Admittedly all of the above could be done internally without implementing SQL scripting, but by using an external std db it gives you far more options further down the line.

[cideway]

What i would like to see is a system that can create complex scripts for in-experienced people but also allow for all you experts out there to do your stuff, a debug would also be good instead of having an error come half way through a test run and losing every thing.

[Baron Hurlothrumbo IIX]

Resistance doesn&#39;t crash on errors like CWC did, are you using resistance cideway?

[bn880]

I agree with cideway, some sort of better debug log would be nice. (like a little screen from which we can CTRL-C?)

[uiox]

Client server will be inrprove sure...

Some commands for synchro...
GetPosServer etc...

Some events
OnserverRefresh

Or for clients for scripters : let it be, we are not apples&#33;

If you want VERY good addons, one client MAY be the master, not server....

[raedor]

yes, a debug is a very good idea&#33;
not only for scripts, but also for description.ext&#33; cos its a waste of time: to change description.ext then to load the mission cos of a mistake flashpoint crashes after that restart flashpoint and so on and so...

[Bullz_eye_on_my_back]

I&#39;m not sure if this would help.

But how about being able to assign a keyboard function or key for dialogs and user made interfaces.

I know some people have found ways to use keys...but how about just letting us define it in the description...or resource file.

Say you want key "r" to move a specific slider in the positive direction.....and key "e" to move the same slider to the neg. direction. Same thing on buttons too and everything else.

Oh and maybe give us the ability to create circular sliders. http://forums.bistudio.com/oldsmileys/biggrin_o.gif

Other note: I&#39;m not sure if its already possible...but to be able to control your character while having a dialog up (provided you aren&#39;t using a camera affect with it) http://forums.bistudio.com/oldsmileys/smile_o.gif

[OneStiffRod]

AllowDamage() should be brought back but maybe enhanced so we can set the scalar value on how damage will occur by a particular weapon on that vehicle - set weapon and scalar value of weapon effect on vehicle.

I would love it if the HIT event handler returned the weapon it was hit by and not just the dude who did it... :weaponCausedBy

[Bullz_eye_on_my_back]

well i&#39;m not sure if its been mentioned yet... i did a search on nearest object but couldn&#39;t find anything.....

I know now you can do the nearest object of a specific class..

i would like a nearest object return any "man" or "tank" or something like this....as far as i know you have to be specific in name.

Also, I would like to see where if you found the nearest object of that class and it wasn&#39;t the one you wanted....
it would be great to be able to subtract or remove that object from the list when running the nearest object command again. something like....second nearestobject....or nearest object [getpos player, "man", select 1] ....where the select _index could go on up to like say 5 or so.... so you could get the 6xth nearestobject to the position...or higher http://forums.bistudio.com/oldsmileys/smile_o.gif

oh well....just a thought...and would come in handy http://forums.bistudio.com/oldsmileys/biggrin_o.gif

Also, have the nearest object command for greater distances than 50 m....possibly have a selection for the radius size to check

[Bullz_eye_on_my_back]

One thing i would like to see is for the dotarget and dofire to work on anything...whether it be a friendly/enemy/building

I&#39;ve heard that you can have the computer aim or shoot at game logic points (might be me but i can&#39;t seem to get it to work for me)

Also, be able to target or fire on the name given of the unit but also coordinates in the x.y.z

I think most of this is already included in the game but i would really like to see more flexibility in targeting and firing upon anything....friendly or not

[Harkonin]

How about actually being able to script truly dynamic units, theres a slew of ways to spawn units now but nothing thats actually dynamic.

[Tactician]

I object to any change of syntax personally. OFP1 script works great for me, I can&#39;t think of an easier syntax (maybe because I&#39;ve never used anything else?) All your examples of object-based.stuff just confuse me.

I think going too far in "simplifying" client/server functions is unnecessary. The only thing I ask for is game-implemented publicArray (and publicString). Aside from that there&#39;s really nothing you can&#39;t do now. If all functions were public netcode would suffer. All we need is a good tutorial for client/server scripting.

Another request for multiplayer is a isHuman function to return whether a unit is a human or AI (the need for this will become very apparent when we start making persistent join-in-progress missions).

Also I&#39;m all about the ability to change a unit&#39;s vehicle type midgame. Would open up a world of possibilities.

[SilverB1rd]

I have not done any scripting in OFP but I have a general suggestion.

Dont leave to the scripters what the game should have been able to do by it self.

[Naruto]

Edited couse i posted at the wrong place.......... http://forums.bistudio.com/oldsmileys/sad_o.gif

[johnnylump]

Group Switch WP -- Scripting command that functions like a switch trigger. But unlike a switch trigger, variables can be used for Group and WP.

Simplified ways to associate multiple strings with a unit and group, such as "name", "callsign", "unit", etc.

Onmap: boolean. Whether the player is looking at the map.

Airviewdistance: integer. Separate from viewdistance, it allows players to see airborne objects from a much greater distance.

[Harnu]

unit getAmmo
unit setAmmo


That way we don&#39;t have to fumble with all the names of various weapons and magazine names.

I.E.

unit setAmmo 1 Gives full ammo
unit setAmmo .5 Gives 50% of ammo
... and so on and so forth

[bn880]

Please make triggers and event handlers a little more reliable in multiplayer. For example the Fuel EH is dependent on local player position and view distance, while a scripter may think it is reliable at all times.

As for triggers, ideally they should contain the same information on all clients, and they should trigger globally not depending on player position again.

And how about larger float variables? http://forums.bistudio.com/oldsmileys/smile_o.gif

[Skumball]

All units should be group-independent. No ties to groups, but the option to group players should be available. In other words, a unit can be spawned from a script without specifying a group for it to join.

[Killswitch]

Lots of good suggestions here... a couple more:

<ul> Distributed global/side/group/vehicleChats (e.g a sideChat in a server script will be shown on all client machines)
Scripting support for complex datatypes ("structures"). Lists, hash tables, graphs and whatnot.
Access to world/island data through scripts. Town names, their respective neighbours, distance between them and so on.
getRank/setRank (In-game career?), get/setSide (changing sides and "affiliation")
[/list]
Above all, though: OFP is a distributed, real-time simulation. Make the scripting language work with that. Unambigously and *very* clearly documented.

[Superskunk]

another important thing:

MAKE ALL OBJECTS POSSIBLE TO USE IN EDITOR, SO NO ADDON IS NEEDED&#33;

maybe could add some groups so searching one is easier. would be even greater, when you have a picture of the object when searching&#33;

Ss

[Gollum1]

another important thing:

MAKE ALL OBJECTS POSSIBLE TO USE IN EDITOR, SO NO ADDON IS NEEDED&#33;

maybe could add some groups so searching one is easier. would be even greater, when you have a picture of the object when searching&#33;

Ss
Yep, I agree.

[Harnu]

getTarget "guy1"

Able to name a persons target in a script. And getting it&#39;s position, distance, height. Etc.

[Kegetys]

I object to any change of syntax personally. ***OFP1 script works great for me, I can&#39;t think of an easier syntax (maybe because I&#39;ve never used anything else?) ***All your examples of object-based.stuff just confuse me.
Object oriented approach would make it alot easier to handle all the loads of parameters and things in different kinds of objects. Imo. A best solution would be, that any parameter and any function the game engine has to any object would be useable also in the scripting language. Doing this the way its done now would result in thousands of different GetSomething and SetSomething commands to remember, which is not a very good thing.

For example, lets say you want to play a sound, with the pitch of the sound coming from a plane&#39;s engine RPM. With OFP1 style scripting it would be something like:

somePlane playsound[engineSound, getrpm engine somePlane, 1]

As you see, theres two "new" commands there, getRpm and Engine. These have very little use, yet you need to remember all of them, or keep taking a look at the command reference all the time.

In an object oriented approach you really dont need to remember anything, as long as something like all C(++) IDE&#39;s have would be implemented, that is, when I type "somePlane." into a script field a listbox would pop up showing all the parameters that are useable in the object "somePlane". From that I could click a property, or just keep typing it like this:


I type "SomePlane.":

http://koti.mbnet.fi/kegetys/flashpoint/oo1.gif

and as I select or type "engine":

http://koti.mbnet.fi/kegetys/flashpoint/oo2.gif

There would be only a very few functions to remember, like createVehicle or deleteVehicle, most things would be found from this "word completion" when you need them.

[bn880]

That&#39;s obviously a huge benefit to scripters, mission makers, and addon makers but: it would require a scripting editor, plus it would require some harder definition of variables to specific data types. A whole can of worms would be opening up with OFP, as it let&#39;s you assign any type of value to any variable on the fly, this would probably have to be stopped. http://forums.bistudio.com/oldsmileys/rock.gif

[Kegetys]

A whole can of worms would be opening up with OFP, as it let&#39;s you assign any type of value to any variable on the fly, this would probably have to be stopped. ***http://forums.bistudio.com/oldsmileys/rock.gif
huh?

[bn880]

Well
myVar can be a number, an array, a group, a vehicle, an object, a soldier, a boolean value.

In the middle of all the scripts there is at the moment no way for an OFP Script editor to determine which nice object the variable is.

EDIT: In terms of visual basic it&#39;s like allowing you to assign a control object to an Integer variable, and then expecting the editor to pick up it&#39;s the object not an Integer.

[Kegetys]

myVar can be a number, an array, a group, a vehicle, an object, a soldier, a boolean value.
Hmm.. yes, it already can, and propably can in ofp2 too... If you try to use a wrong type then you get an error in top of the screen. http://forums.bistudio.com/oldsmileys/rock.gif

[bn880]

No you don&#39;t, not for what I&#39;m talking about. When a function requires a specific type it gives an error yes, but how is an editor suppost to tell what your variable is when you don&#39;t define it, and better yet later change it&#39;s type several times?

I can use _x as a float value, then later in the script as an object. How&#39;s the editor going to know the difference. That&#39;s what I&#39;m referring to. We would have to have variable declerations. Or a full interpreter for things like createVehicle, createUnit and all other function that return a type of variable, so that an editor knows what it&#39;s dealing with.

[[AIA] silentwolf]

Maybe it would be usefull to include a wizard to make a script,simply just answer some quisten what type of script you want,what it has to do,and that the wizard creates it then.Would be handy for noob scripters like me.

[bn880]

silentwolf@ @ ,)]Maybe it would be usefull to include a wizard to make a script,simply just answer some quisten what type of script you want,what it has to do,and that the wizard creates it then.Would be handy for noob scripters like me.
http://forums.bistudio.com/oldsmileys/biggrin_o.gif Umm yeah, that&#39;s like a programmers (or scripters) dream come true.

Don&#39;t bet any money on the first one of these coming in a war sim. http://forums.bistudio.com/oldsmileys/smile_o.gif

[Kegetys]

I can use _x as a float value, then later in the script as an object. ***How&#39;s the editor going to know the difference. ***That&#39;s what I&#39;m referring to. ***We would have to have variable declerations. Or a full interpreter for things like createVehicle, createUnit and all other function that return a type of variable, so that an editor knows what it&#39;s dealing with.
The only type I can think of that would need this autocompletion would be vehicles, and most of those tend to be placed with the mission editor, and you can easily use the names assigned to them there... With createvehicle it is indeed troublematic, but maybe the whole createVehicle/deleteVehicle thing could be changed into something easier to use. For example, maybe there could be a group editor, where you can place invisible groups in the mission editor like regular units, but they wouldnt be placed anywhere until you place the group somewhere with a scripting command...

[bn880]

Well ok, if auto-completion is not necessary I don&#39;t see why it can&#39;t be made more object oriented. As for getting rid of createVeh etc. I don&#39;t think it&#39;s really a good idea as people like to create and get rid of a lot of stuff on the fly, to save memory. I&#39;m talking about scripts that do that so...

But yes I agree OFP needs to have some larger force management, like I attempted with EnemyStack, currently OFP just freezes up with lots of AI, but maybe it could be managed better using suggestions like yours.

[Terox]

i would like all units and vehicles to allow a "setexture" in their init field or similar way. and possibly even the map itself

These setextures would include Winter, sand, temperate cammo, have BIS pre installed textures and easily adapted jpeg files that could be incorporated into the pbo file, in much the same way as you can do for flags

This would then mean you could have the same landscape with different season coverings.
Any addon vehicles that were made would simply have a setexture command in their init field


So one new addon vehicle could instantly be incorporated into any climate type without the need for multiple addons for that one vehicle



wouldnt it be nice to have pre game options like
Winter
Summer
Desert
Jungle

and all could be activated by something like

?(param1 == 1):setglobaltexture "DESERT"
?(param1 == 2):setglobaltexture "ARCTIC"
?(param1 == 3):setglobaltexture "JUNGLE"

setunitexture
setgrouptexture
setobjectexture ***for the likes of buildings etc



It would also be nice to enable some form of rating value, which for any vehicle could be set in the init field. something like

pilotrating=>5

and any player who had a lower rating which was given somehow by some form of award system (Multiplayer) simply couldnt fly it

This could be used for any vehicle, weapon etc

So in other words, a veteran player could fly the transport choppers, whereas a noob would have to be a passnger

[Baron Hurlothrumbo IIX]

It would also be nice to enable some ***form of rating value, which for any vehicle could be set in the init field. ***something like

pilotrating=>5

and any player who had a lower rating which was given somehow by some form of award system (Multiplayer) simply couldnt fly it

This could be used for any vehicle, weapon etc

So in other words, a veteran player could fly the transport choppers, whereas a noob would have to be a passnger
Yes, as long as that person could drive/ fly if they were the only one left/ all on same ranking

[Terox]

yes perhaps.

It would basically be a mapper edited item though, so not necessarily incorporated into coops etc

I was thinking more on a ladder map or public PVP game

[bn880]

Ookay, a few more requests from me, but these I know all of CoC would enjoy:

Dialogs
Perhaps a VB style editor for dialogs and actions/properties associated with them. If not, at least a graphical dialog editor and save/load option.

Ability to load an active map with onMapSingleClick capabilites as another dialog resource. (an area in dialog)

Ability to create brand new dialog components during runtime, and to change all properties of the new dialog objects.

Ability to bind(/define) keys to different dialog resources and options. EX: assign 4 directional buttons to the arrow keys when dialog is active.

That&#39;s it for now, I&#39;ll see if we can&#39;t get more suggestions on this from other CoC members.

[Superskunk]

Maybe this option is already in OFP, i don&#39;t know it&#33;

- Add the abbility for editor to direct configure a units team-tag. ***I mean a way to put in script what the "Join" waypoint does in OFP1.
Using it with a script text, you&#39;re absolutly sure a unit is gettin&#39; in a team where you want it. "Deleting" it from his old team. You also have to be able to select his position in the team, depending on its rank. IF the editor makes an mistake choosing a team which is full, there must be an error message, and editor must correct fault.

[Terox]

1) Some additional options boxes in server pre game start up

we have the param 1 and param 2 boxes now, but it would be nice if we could have a couple more simply for potential use

2) And a totally modifiable scoring system, so that we could (If the mapper wanted) get away from players trying to score kill points instead of objective points without having to script our own scoring system into the map

(Eg tyhe score sheet that comes up at the very end of the mission, that folks look at to see who scored the highest

Default mode is ok for a DM, TDM, but there are other map types where this is not the be all and end all of the game

[Harnu]

I want a new function or something that makes turning off lights very very easy.

[Johan_D]

I want a new function or something that makes turning off lights very very easy.
An M16 shooting on it&#33;

[Blanco]

What about enableIA? There&#39;s disableAI but where is enableAI?

The ability to change the model of the player during SP missions (disguise, spionage)

something like...

Civ setmodel "WBsoldier"

getmodel, typeofmodel...lol

[Acidcrash]

so maybe this idea isnt exactly scripting, but its editor related:
custom shapes
"what the hell do you mean fool&#33;?"
well for example: triggers, right now its either square or circle right? well I personally would like to see custom shapes... same with markers
to explain further what i mean, say you have a radar on the side of a hill and you want to mark its field of view on the map, sure you could put a nice big circle around it... but it cant actually see that full circle can it? so instead you would have the shape lob-sided, ie one side flat to show that the hill blocks the radar, yet facing outward would be its full range... those of you who have played Falcon 4 will know what i mean (on map: Threats>low alt radar/airdefence)
screenshot of what i mean (http://www.jakbat.plus.com/radar.jpg)

[bn880]

how about unit reveal [unit2, amount, seconds]

[Acidcrash]

so the first unit would know about the second unit for X amount of time before "forgetting" about them?

[uiox]

IA triggers. Basic feelings, stress, quiet...

When you ear an explosion when you are secure == stress.

Simply way for the player : in stress trigger fire is harder...

But IA triggers with a life, initial state but a life. All of this relates to in sand it&#39;s harder to walk, when it&#39;s raining I&#39;m not happy, etc....

This is NOT relates to OFP AI, only with player.

With AI triggers introduce maintenance problem and so on. After explosion near your vehicle you can have random problems (just like in real life...)

[bn880]

so the first unit would know about the second unit for X amount of time before "forgetting" about them?
Well have you used the existing reveal command? It basically makes it a little more useful, allowing you to specify the amount of time the reveal is to be active and the amount of info the reveal should share. http://forums.bistudio.com/oldsmileys/smile_o.gif

[uiox]

For solve the debate anti-cheating /scripting a command (?). Anti-cheating kills scripting, for this you don&#39;t want wide open some possible commands, I think it&#39;s not the good debate.

Script for scripters
Cheat for cheaters

I know MP is your main market target... But....

[Snypa UK]

there should be an internal scripting program within the game to make things really simple for normal IQ&#39;d people like me

[Pathy]

I&#39;d prefer it if they didnt change the way its done around too much, as i&#39;d have to relearn it all again :P




Quote[/b] ]IA triggers. Basic feelings, stress, quiet...

When you ear an explosion when you are secure == stress.

Simply way for the player : in stress trigger fire is harder...

But IA triggers with a life, initial state but a life. All of this relates to in sand it&#39;s harder to walk, when it&#39;s raining I&#39;m not happy, etc....

This is NOT relates to OFP AI, only with player.

With AI triggers introduce maintenance problem and so on. After explosion near your vehicle you can have random problems (just like in real life...)

I agree, this would make things like supressing fire alot more realistic as well....i mean, bullets are whizzing round you, your gonna be under cover most of the time (instead of dropping flat like OFP units), popping up occasionally to fire off a few rounds in the enemies general direction.

[vMatt]

Well, maybe I&#39;m the only one not satisfied with the current unpredictability concerning scripting of vehicle movement ... but I would really appreciate being able to "record" my own control input so I could e.g. do a low-level flight in a helicopter and let the AI "playback" my maneuvers during a mission.

Another point would be accessability of files:
I think that it should be possible to access remote files (via http) and that FS-links (on Windows and Unix) should be supported so I don&#39;t have to store all my audio-files on my ofp-partition (at least not during mission-editing).

... that was my two cents ;)

[SpecOp9]

The scripting in OFP, as of now, is by far awsome. Just about anything can be possible with much work put into it.

One thing however I would like to see added:

The ability to compile your addons with the mission or campaign files, so there is no need to constantly search the fansites for addons, when half the time they dont even work
(like ofp.info) unless you click the download button about 10 times or more.

[Phleep]

The scripting in OFP, as of now, is by far awsome. ***Just about anything can be possible with much work put into it.

One thing however I would like to see added:

The ability to compile your addons with the mission or campaign files, so there is no need to constantly search the fansites for addons, when half the time they dont even work
(like ofp.info) unless you click the download button about 10 times or more.
I think it is a better idea to have an auto downloader. This means you click to download a mission and it will scan your OFP folder to see if you have all the correct addons and then ask if you want to download the missing ones. The OGN server already uses this as an executable file on your harddrive but maybe a web based version which runs when clicked would be appropriate.

I just don&#39;t want to be doubling up on addons by having them integrated in the mission.

[-style-]

I haven&#39;t read through this in depth, but I think it might be a good idea, if there won&#39;t be any source code release...

http://www.codeproject.com/cpp/gecko1.asp

[m21man]

We really need a getpitch/setpitch command.

[cornhelium]

I agree with vMatt on the need for finer control of vehicles in the mission Editor, and the input-recording method sounds good.

I&#39;m always trying to get really flash, aggressive flying from AI choppers in the mission editor, but as they&#39;re fairly loose about the waypoints/positions you assign them it&#39;s very erratic.

For instance I have a mission on Tonal where 3 Littlebirds in a tight line formation, with Deltas in cargo, swoop down Lorenghau pass at full tilt and fly under that high wooden bridge, while TRF machine gunners wake up and start blazing away. It works about 70% of the time, but on some sessions they&#39;ll crash into the bridge, scatter when the guns start firing, or just bypass the valley completely, no matter how much tweaking and changing combat modes I do.

With really tight path-setting for AI vehicles, you could have some really good stuff going on - not only to look cool, but also to look realistic with jets blowing through valleys on terrain-masking flights etc.

I guess this would be pretty CPU-intensive, so it would need to be an optional setting in the waypoint box (loose/tight positioning), or as vMatt suggests, you would set one waypoint as class "pre-piloted", specify the starting speed, height, heading, bank, power and pitch then hit a "record input" button in the waypoint box. This would take you into the mission editor where you would fly the course you wanted, with the next waypoint automatically generating at the point where you stop recording.

Cheers,
Cornhelium

[FragMASTER]

^^^ that would be one very cool feature

[SpecOp9]

I want pre-made scripts for people who don&#39;t know how to make them. Vehicle respawn for example,

Instead of going through all that sqs crap, don&#39;t you think a little drop box in the editor would be more easy?
----------------

UAZ

Respawn?
-Yes
-No

Time to spawn at game start
-1 minute
-2 minutes
-3 minutes
-ETC

Time to respawn after destroyed
-1 minute
-2 minutes
-3 minutes
-ETC


Or have a little box area where you can type in a number for seconds.

You get my picture I&#39;m sure..

[SpecOp9]

How about allowing the script to make external SQL calls. This would generate a lot of possibilities....

1) modify a running game.
2) easy to store data from one game to influence the next.
3) simultaneous conflicts that have repercussions for each other.
4) would make a persistent battlefield feasable.
5) db could run on another machine reducing server load.
6) you would effectively have the entire status of the island whenever you wanted it - even for the rest of the campaign.
7) easy to write tools to maintain islands/battlefields
8) automated external tools

Limitless possibilities...
About # 1, bad idea.

Already there is a console cheat out that allows you to modify Multiplayer maps, while you are in them.

[Bullz_eye_on_my_back]

I had some ideas as I&#39;ve been scripting along. I&#39;ve forgotten most of them, but a few that I&#39;ve recently encountered is trying to find who trips a "useraction" that is defined within the config file. Several explinations have been provided for the "addaction" triggering, but not a way for useraction. Also with the addaction, provide a way to pass variables if needed.
I&#39;m sure this has been mentioned before but the "nearestobject" I would love to see it work in the way it does right now and maybe a different way where you can just search for a specific class. example: "tank, plane, car, soldier,etc." Also, maybe a user specified radius of search.

[Bullz_eye_on_my_back]

I forgot to add one thing..... previously the "getpos" was mentioned for getting the height above sea level, above land, and absolute hieght (this one not 100% accuracy to get in ofp) ....I would like to add this one request to the land height-to be able to choose a coordinate and find the land height at that exact coordinate.
This could open up some more possibilities in scripting- for smarter weapons, better gunsites scripted into airplanes..on and on http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[[STO]Badblood]

I would like to see the AddAction command be more exlusive to a player rather than a seperate object which can be invaded by a nearby player ---&#62; ie: A player standing 1m away from me aquires my action commands as long as he stays within my action object radius.

[Harnu]

name SetSpeed x

x is the desired speed. Instead of Limited, Normal, and Full, this would give you a bit more control over exactly how fast you want someone to go.

[HappyG]

Separated server and client side scripting, with easy to use channels inbetween to sync it http://forums.bistudio.com/oldsmileys/smile_o.gif

[Cosmic Evolution]

One thing I&#39;d like to see if you are going ahead with the addition of join in progress would be to have scripting functions that would make it only possible for the person that disconnected to rejoin the game in that spot. ***It would be REALLY cool if this only effected the playable spots that HAD players at the start of a game (in CTI for example, it would be great to only have people that dropped out be able to rejoin their spot, but still have new players be able to join in at any point as long as the slot they joined was an AI from the start of the game.) ***Something along the lines of the respawn command, with multiple variations of a single line giving you as much flexibility as possible.

I think this would GREATLY enhance the usefullness of JOIN IN PROGRESS...

[ArchangelSKT]

I don`t know if this would be the correct post or if it have been mentioned before but in the mission editor I would like to see a respawn scripts that are set .

Meaning you can just pick " respawn in group " etc from a list .

[Balschoiw]

Little thingie but maybe useful. Right now you can set trigger size with radius only. Especailly when big radius is chosen the performance goes down.
I often thought about a trigger with two circles, means that you create some outline only that is checked. For example you want to detect if someone is crossing a line and you want something to happen. Right now you have to :
a. Setup a big trigger with big radius
b. Setup multiple rectangular triggers with great length and small width and combine them.
c. use scripting like distance command and such

Wouldn´t it be good to have a second radius option for circular triggers that would enable you to have a wide radius but only a thin trigger line defined by second radius only a little smaller than first radius ?

Hope someone understands what I mean. http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[Harnu]

Basically like a Compact Disc, the inner hollow part is void of the trigger, as well as away from edges of the CD. But the inner, shiny, part is where the trigger will be activated.

[Balschoiw]

Yes. This would save performance even if large triggers are used as the area that has to be checked is in fact very small.

Edit :
So easy... like a ring ***http://forums.bistudio.com/oldsmileys/biggrin_o.gif with variable radius for inner and outer line. This would really save us from making oversized rectangular triggers in 4 parts.
Besides that it would offer the opportunity to have units inside the trigger of the same side that activate the trigger without actually activating it. ***http://forums.bistudio.com/oldsmileys/wink_o.gif
Haha I messed it again http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[Fragsta]

I don`t know if this would be the correct post or if it have been mentioned before but in the mission editor I would like to see a respawn scripts that are set .

Meaning you can just pick " respawn in group " etc from a list .
This is a good idea, yet something that makes OFP so popular is the fact that people make their own scripts that are almost personalized. Maybe a basic template or something would be good


Quote[/b] ]Basically like a Compact Disc, the inner hollow part is void of the trigger, as well as away from edges of the CD. But the inner, shiny, part is where the trigger will be activated.

How about using a regular big trigger circle of radius 100, 100.
Then a new feature, an un-trigger circle (working title) of radius 50, 50?

[Drakkhen]

The major problem with scripting seems to be when saving game and reloading:

running scripts state and past inits are not replayed on reload.

The result is this:

- if you were running a script when saving, after the reload it won&#39;t be restarted.

- if you ran an "init field one frame script" or set variables in an initfield of a PBO at the beginning of the game, it won&#39;t be replayed as you reload (some variables and other features of the addon can be missing or mis-set).

A simple thing would be some "save" and "reload" EventHandlers... with the ability to save unit script variables states too.

[Bullz_eye_on_my_back]

Hmmm..I don&#39;t think I&#39;ve seen this anywhere... but I&#39;d like to put in a request for...
Being able to get and set the rotational velocity of an object/vehicle,etc.

The animations in one plane and setdir, only goes so far..

Maybe have it set for 2 planes in relation to the object


oh and also have the ability to remove/change gravity effects on objects, or set their gravity..... that way we would not have to have a continous loop for holding something particular at one height...whether it was hovering or not..

just opening up any type of flexibility for all possibilities http://forums.bistudio.com/oldsmileys/smile_o.gif

[SEAL84]

How about a getviewdistance command that would return the player&#39;s exact settings rather than relying on benchmark?

I can think of at least one case where this would be useful.

[xenom]

(&#33;)

setXdir - getXdir --&#62; set and get the X axis direction of an object
setYdir - getYdir --&#62; set and get the Y axis direction of an object
setZdir - setZdir --&#62; set and get the Z axis direction of an object

sorry for bad english, i hope that you have been understood.. http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[Korax]

setXdir? I think I get it, being able to tilt a unit on an angle and such, I would also like to see something like that... But moreso i would like to be able to exclude items in the NearestObject command.. so Nearestobject [player,"ALL",player] would get anything close to the player, excluding the player itself.. I would also like to see some commands to create/get/change the properties of triggers and markers in scripts, and im hoping there will be a way to make actions global when activated, and being able to carry on defineable parameters with actions.

[bedlam]

EH "killed" should be global?

[xenom]

i want call a drop particle with a name (ie: "dropone"), and then i can move the particle by setpos, setvelocituy ecc.

(sorry for bad english)

[Bullz_eye_on_my_back]

i&#39;m sure this has been asked for... but just making sure it wasn&#39;t over looked....

1. being able to pass arguments from action commands.... also what player/ai used the action command...
2. A command to determine which units are AI or not... might be a command already in the scripts that i have over looked...if so sorry http://forums.bistudio.com/oldsmileys/sad_o.gif

[MrZig]

Yeah, or even say

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this addaction &#91;&#34;Commit Suicide&#34;,&#34;player setdammage 1&#34;&#93;[/QUOTE]

OR have the stuff predefined like onmapsingleclick, like
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this addaction &#91;&#34;Request arty&#34;,&#34;&#91;_actionholder,_actionuser,_action,&#34;request &#34;&#93; exec &#34;Artillery.sqs&#34;&#93;[/QUOTE]

that would be slick, so instead of a zillion scripts you would only have a few if you wanted to make something big.

[Bullz_eye_on_my_back]

Well this is the best place that I can find for this request.... it kind of intails a needed function for islands.....

I&#39;ve created object addons that would use an initialization script from the config file,
the only kicker is.... if an island maker uses these objects the scripts will not run when the island is used, instead a mission maker would have to come up with a way run this script....

Simple solution if you have a couple objects on the map, but what if it was a fence or plant object that is used hundreds of times through out the map... then its almost impossible to select all of the addons and run the script...

so I guess what I&#39;m requesting is that anything that is used within an island, that has an initialized script configured ...please make it where it will run this script without the need of external scripts added to the mission http://forums.bistudio.com/oldsmileys/biggrin_o.gif

even if anything give the option to the island maker to run the initialized scripts

thanks&#33;
oh and umm...if anyone knows of a way to do this... please let me know ... i could be over looking something again http://forums.bistudio.com/oldsmileys/crazy_o.gif

[uiox]

getpos [TheUnit,{TheMemoryLodPoint}]

[raedor]

getpos [TheUnit,{TheMemoryLodPoint}]
yes&#33; http://forums.bistudio.com/oldsmileys/smile_o.gif

and a short form for<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">position obj select 0/1/2[/QUOTE]like<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">postionx/y/z obj[/QUOTE] http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[Jinef]

Killing the local issue in MP would be ..... ooooohhhh so nice.

I am sick and tired of all the problems it causes, even something as simple as reloading a Heat round in a tank crewed by 2 humans is not easily done, it requires a process of peole jumping out, switching positions and that bollocks. Please fix it.

[raedor]

that something is local is not an issue, they tried to have a little netcode.

but there should be i.e. a global alternative of every command (setObjTex&#33;). that would save much scripting work.

[m21man]

I&#39;d like it if we could choose the interval between each time a trigger checks if its conditions are true. So if I have a large trigger over a battlefield, I could set the trigger to have a 10-second interval, which would reduce lag when using high amounts of triggers in large-scale missions.

[wolfbane]

Dunno if this has been suggested before (i´m to lazy to read the whole thread right now) so i apologize if i´m inventing the wheel all over again or something.. http://forums.bistudio.com/oldsmileys/tounge_o.gif

Would be nice to have a crouch option for the setunitpos command.

unitname setunitpos "crouch"

Could be useful for setting up defensive positions for units in houses and behind cover and such when doing missions.

[Baron Hurlothrumbo IIX]

Dunno if this has been suggested before (i´m to lazy to read the whole thread right now) so i apologize if i´m inventing the wheel all over again or something.. http://forums.bistudio.com/oldsmileys/tounge_o.gif
So why should anyone take the time to read what you say?

Read the thread.

[bn880]

RETURN VALUES

I would suggest that most scripting commands be revised to make sure they return something like &#39;null&#39; instead of an on screen error. (in addition they could set an errno or errString so we could check that variable to verify what the syntax/function error is).

The worst thing we have to deal with now are functions which report on screen (#type object expected number). If we could have this silent scripted error (when not in Debug mode) we could avoid nasty looking surprizes on screen. Other functions like object actually crash OFP if you do not pass in a valid ObjID.

Return values from functions can open or close a lot of doors for teams like CoC and other advanced scripters.

Thanks for listening

[m21man]

Also, it would be very helpful to add a command to check whether the player has a certain addon. This would allow a mission-maker to make a script that would tailor the units in a mission to what units the mission-player has.

[Unnamed_]

Quote[/b] ]Also, it would be very helpful to add a command to check whether the player has a certain addon

I think you already can? at least in SP AFAIK. If you call CreateVehicle with a classname OFP does not recognise (i.e. Missing Addon), it just returns a Null object. Kind of reinforces BN880&#39;s point.

While I&#39;m here, apart for bringing OFP&#39;s scripting language closer to commercial development languages, I would be happier with:

An additional parameter for the DisableAI command, _unit DisableAI "AutoPilot"

Equal priority for scripted commands verses, in game commands.

SetDir2 that changes only specified axis.

GetPos2 and SetPos2 that work in absolute coordinates rather than ones relative to terrain height.

[shinRaiden]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
#include values myfunction tag_function.sqf/s
[/QUOTE]

(enumerates functions available and their sourcefile location, with values such as global or local in scope.)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
myfunction&#40;_blah.class.property, values, misc&#41;
[/QUOTE]

could create:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
get&#40;player.position.x&#41;
set&#40;player.position.x&#41;
[/QUOTE]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
Cargo.index.contents
&#40;or driver, gunner, commander, crew, pilot, etc; each of those would be indexable as well, for multi-gunner, -pilot, etc crews...&#41;
[/QUOTE]

As for the debugger logging to a file, as file writing has been added to VBS, it should be easy to implement into OFP2 as well. I&#39;m looking for some of the following:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
called-from file
called file
line numbers&#40;?&#41;
code line
error
values given
values expected
[/QUOTE]

When a unit boards a vehicle, ofp knows that they are now in a proxy slot. I want

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
get&#40;unit.position.relational&#41;
[/QUOTE]

to return

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

where objectid 0 would be out in the world, otherwise inside a vehicle; and the index position, again 0 for the world, or the respective proxy location.

[MCPXXL]

DISABLE Information Key "I" in pur coop games ... think this will be make the teams more to act like teams an not like a group of rambos.
An info about kill or not is simply enough i think.
The Rest is in debriefing

Some missions have not BMPs or Tanks / Helis for all Players and then the last ones got the rest.
Look how often there is a fight for the slots because a lot of people look first for kills in missions and then for the goal of the mission.

This is my personal meaning ;-)

[ofpchaos]

For "disableAI" commands we need "EnableAI" commands &#33;
For every Body Part (Hand, Head, Mouth, Eyes, Legs etc.) we need separate commands. This is very important for Cutscenes or special AI actions.

All tools (Visistor, Script/description & Stringtable editor, Animations Editor, Briefing editor etc.) must be intergrated in the OFP2 Editor. This must have a 3D Preview and works not in Fullscreen Mode but in Window Mode (like a 3DStudio). We need, a protocoll window for bug/other messages output.

We need Artillery working with Forwart Arillery Controllers, animated Doors in Vehicles and we will shoot with our handweapons and drop the grenades from ground vehicles, boats or Helos. We will cargo cars, armor and others with helos and aircrafts.

&#33;&#33;&#33;
Greetz
Chaos http://forums.bistudio.com/oldsmileys/crazy_o.gif

[Baddo]

OK I&#39;ll give my ideas to the correct thread too... so here goes:

1. EVENT HANDLERS IN GENERAL

Mission designers should be able to select the visibility of each event handler. In other words one should be able to choose if the event handler should be executed globally, locally or only in the server. This should of course concern every event handler type. This would make event handlers much much better for use in multiplayer.

2. &#39;DISCONNECTED&#39; EVENT HANDLER

Maybe there is already coming a good system for OFP2 to handle disconnecting from middle of game session, but anyway:

An event handler which detects if a player has disconnected from a multiplayer game session would be a really handy one. It could be used to delete the disconnected player&#39;s unit or anything else the mission designer wants.

Deleting units left behind by disconnected players could also be done with a setting in the description.ext file or equivalent. Like a boolean variable deleteDisconnected = true/false. This method should not exclude the &#39;disconnected&#39; event handler.

I think that it should be up to the mission designer how to treat a unit left behind by a disconnected player. Delete it or leave it as AI, both just fine for me but let me choose it, please.

http://forums.bistudio.com/oldsmileys/smile_o.gif

[Scrub]

How about some in-engine bitmap commands?

-Define object or space relative to object as the surface to display on. (CIC radar screens or holograms anyone?)

-Ability relatively scale bitmap area (for fitting), and define action spots (definable graphic triggers)for: Buttons on panels, handles on vehicles or the doors themselves, quering contacts on a command screen, dynamic cockpit overlays. allows an &#39;action&#39; key to grap, poke, push, or just triggger with alterable graphics (possibly using a mask bitmap as an invisible, color based command channel.) ***This was used in older 2D game&#39;s precision collision dection.

-The bitmap controls would have to have an array containing pointers to the actual image(s), the mask image(s), the &#39;color&#39; value that would return upon &#39;pointing&#39; at them, allowing it to pass to the triggered event.
(not sure of the simplest way to handle updating ingame animations and video from other in-game cameras, but defining the surface is at least a start ***http://forums.bistudio.com/oldsmileys/whistle.gif )


-object.facenum.normalpos type command to define the surface it is upon.

Besides all the real guts of the code that would actually allow this to function, this should be about all that is necessary to allow interface. ***All else would be external functions and scripts. ***This would make it so the &#39;RPG&#39; elements of the game could have some alternate interactions besides the object-based.

Whaddya think? *** http://forums.bistudio.com/oldsmileys/band.gif

[UNN]

Quote[/b] ]I would like to see the AddAction command be more exlusive to a player rather than a seperate object which can be invaded by a nearby player ---&#62; ie

Yeah, I&#39;d like to see this. Just give AddAction the same parameters you have for user actions in config.cpp.


Object oriented would be the ideal solution, but if not. Just adding a simple pointer function for objects, would go a long way. So you can associate data with any object?

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Car01 AddPointer &#60;Pointer&#62;
GetPointer Car01[/QUOTE]
<Pointer> could be anything from another object, an array or another pointer.


Line of sight function for combinations of objects, and&#92;or XYZ positions?

Cheers

[General Barron]

Quote[/b] ]Just adding a simple pointer function for objects, would go a long way. So you can associate data with any object?
This was added to VBS1, so I assume it will be in the next OFP. http://forums.bistudio.com/oldsmileys/smile_o.gif However, in the meantime, you can use this function to do the exact same thing now:
http://www.ofpec.com/editors/funcref.php?filter_func=63

--------

What I&#39;d like to see changed is the way labels are handled in scripts. It seems that the way they are currently handled is that when a &#39;goto&#39; command is hit, OFP will then search thru the entire script line by line, trying to find that label. This makes fast loops extremely CPU inefficient, as evidenced by the fact that an @condition runs much better than a simple loop like this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#blah
~0.01
? &#33;condition &#58; goto &#34;blah&#34;[/QUOTE]

I would suggest that when OFP loads a script, it should first parse the whole script to find all the labels. Then it should make a table of labels and their associated line numbers, so that whenever a &#39;goto&#39; statement is run into, the game can jump directly to the proper line of script, instead of searching thru the whole darn thing.

---------

One more thing I&#39;d like to see, if it hasn&#39;t been suggested already, is short-circuit evaluation on booleans. Meaning, when reading a condition, as soon as it is determined that the condition must be true or false, then it stops evaluating and returns a value.

This might not seem like a huge deal (and it isn&#39;t), but it should make scripts run just a tad faster. There are also some situations where it is handy. For example, if you wanted to divide by a number, but wasn&#39;t sure if it was currently 0 or not. With SC, you could just do this:

_num = [0,2] select random 1
? _num &#33;= 0 && 30 / _num <= 15 : ....

Okay, bad example, but you get the drift.

[UNN]

Quote[/b] ]This was added to VBS1, so I assume it will be in the next OFP.

Must have missed that one, when sniffing around the VBS pages http://forums.bistudio.com/oldsmileys/thumbs-up.gif


Quote[/b] ]However, in the meantime, you can use this function to do the exact same thing now:

Thats just global arrays? Although anything that makes arrays more accesible, has to be a good thing. The VBS object pointer would just open up all the other types to be refferenced efficently, rather than just the handfull you get with OFP, at the moment.

Edit:

Would also be handy if you can expand on the #IfDef functionality of the config:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#IfDef V1.91

Class OFPV191SPECIFCADDON
{
DisplayName=&#34;My OFP Addon&#34;;
..............
};
#EndIf

#IfDef V2

Class AAV2SPECIFCADDON
{
DisplayName=&#34;My Armed Assualt Addon&#34;;
..............
};
#EndIf[/QUOTE]

Also checking to see if other addons are installed, a bit like RequiredAddons section of the config but without the error messages:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#IfDef Class OFPV191SPECIFCADDON

class OFPV191SPECIFCADDON_EXTRA
{
DisplayName=&#34;External addons for OFPV191SPECIFCADDON&#34;;
........
};
#EndIf[/QUOTE]

Cheers

[Big Dawg KS]

getTarget "guy1"

Able to name a persons target in a script. ***And getting it&#39;s position, distance, height. ***Etc.
That is ALL that I ask, oh god PLEAAAAASE include a getTarget command. Pleeeeaaase&#33;

[fatcroc5]

i wouldnt mind a command that on activation gets the attention of all enemy units in a specified area...

[Crassus]

Well, unless it was suggested using a word other than weapon...., a command to determine which weapon the Player or AI has in hand, and not just in his inventory, would be great for calling those scripts that are specific to that "weapon."

Also, perhaps just repeating these:
-not being locked into having new pieces of equipment which need the fired EH to use it called "weapon", e.g. the laser designator.
-I guess one might call it "free key mapping": allowing equipment to be used with whatever keyboard input the modder desires.

Something like useKey: "J";
*** *** *** *** *** *** *** *** *** *** *** ***keyHold: 0 or 1//to set if the key should be held down or not

[Balschoiw]

Dont know if this has been suggested before but it might be a good idea to embedd a scripting shell within the editor that gives us the chance to write/load/save and alter scripts while working in the editor. I´m thinking about something like Chris OFP script editor that could be run in an additional window when called and would give us the possibility to create scripts from the editor directly into the mission folder. Having an eye on the functions Chris OFP script editor has it would be a good thing to have as we additionally would be able to create loadouts for crates, units, vehicles with a view mouseclicks and also would be able to create briefing.html and overview.html from one platform. An embedded pic converter for .pac or .jpg files would be nice also.

[hardrock]

Well, unless it was suggested using a word other than weapon, a command to determine which weapon the Player or AI has in hand, and not just in his inventory, would be great for calling those scripts that are specific to that "weapon."
Yes, something like selectedWeapon in opposition to selectWeapon

[bn880]

I am really not entirely sure if I mentioned this before, but if we have Join in Progress, which I assume we will:

eventHandleRama

Need events for connect/disconnect of players for the least. With well thought out data being passed. That&#39;s all for now... http://forums.bistudio.com/oldsmileys/whistle.gif

[UNN]

Just a couple more things, that would come in handy.

A script command to return texture&#92;terrain type of any XYZ position on an island.

A command to determine if there is an unobstructed Line of Sight between two XYZ positions. Preferable, regardless of the current view distance.

Some commands or modified fire commands, to force a missile lock for either an active vehicle or cam created missile. Again, not influenced by what the AI knows about the target.

Oh and the ability to associate a player e.t.c with a cam created round.

And an option to allow infantry to destroy objects on contact, the same way vehicles can with bushes and trees e.t.c Perhaps using the objects mass?

ATM you can use this to create event driven land mines for all vehicle classes. If infantry can destroy certain objects on collision, then it opens it up to all classes.

Cheers

[Scrub]

Quote[/b] ]UNN Posted on Oct. 30 2005,06:14
--------------------------------------------------------------------------------
A command to determine if there is an unobstructed Line of Sight between two XYZ positions. Preferable, regardless of the current view distance.

Good one. If it could be used with a call to find absolute ground &#39;Z&#39; of an XY position, it would allow AI to find a good difilade position facing the commanders called FZ (or to defend aganst a threat vector.)

Do you think it would be good to return the type of object (building, ground, vehicle) that is obstructing?

[UNN]

Quote[/b] ]Do you think it would be good to return the type of object (building, ground, vehicle) that is obstructing?

Good idea, perhaps a class type and position? If it hits terrain, there would be no object to return. If it&#39;s not terrain you could use nearest object to get the obstruction.

It would be good to have some options, you could make all kinds of kit.

[chupchup]

I would like something along the lines of:

ClassList object

Operand types:
Object: Any Object or Vehicle or Unit.
Type of returned value:
Array
Description:
Returns an array of the class hierarchy of an object or vehicle from lowest to highest where each selection within the array is a string.

I would also like to see a particle generator section of the engine that allows for simple particle scripting. It currently takes too long with OFP to script and test a particle script and an in-editor function for doing this is a must.

[CrashDome]

Didn&#39;t see this mentioned yet:

XML and lots of it.

I just got done looking at Civ4&#39;s moddability and I must say it is the most fantastic thing I have seen yet as far as being able to modify a game.

Additionally, OFP was never really good at holding data externally very nicely. Error logs, positional data, ugh... the list could go on forever.

[djura]

More overall access to gamestate for scripters ie:
---
bindKey function (bind scripts to a key or combination on keyboard)
...
And bindMouse.

[djura]

ex:
? myAISoldier UnderFire() == true: myAISolder TakeCover(NEAREST_BUILDING)

where NEAREST_BUILDING is a predefined BIS constant. And yes, TakeCover is a predefined function http://forums.bistudio.com/oldsmileys/smile_o.gif

Obviously, UnderFire() would return false later, if the unit had not taken fire for a predetermined length of time, or the unit was sufficiently far away from the area of fire.

Maybe a FireDirection() function could return a rough angle from where the AI unit believes the fire to be coming from.

Regards,
T.

BTW: Why not have Visual Basic style script with an AutoComplete&#39;ing IDE? That way even the idiots can script.
And way for running deamon scripts, witch will be started (by engine) if any condition is accomplish and after its run will be stopped. Its better than horible loops with waiting command in the end.

Syntax OFP scripting language is terible. Using Ruby, Python (if wont be any different way Objective C) etc. as inspiration during creating new version is realy good idea.

[hardrock]

I can confirm there are no plans on string functions to current OFP and OFPR products. As for future products, it is very likely it will be added, but I cannot tell it for sure yet.
Sooo ... what happened to those plans? String functions or a different string handling are one thing that is really needed in OFP&#39;s scripting language . . . http://forums.bistudio.com/oldsmileys/icon_rolleyes.gif

Something like
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">string = &#34;string&#34;

string&#91;0&#93; == &#34;s&#34;
; or
string select 0 == &#34;s&#34;
; or
array = str2array string
array select 0 == &#34;s&#34;[/QUOTE]


Also, what about different array handling in further games with the possibility of associated arrays?

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">array = &#91;entry1, entry2, entry3&#93;
array&#91;0&#93; == entry1

; associated arrays
array&#91;&#39;my_key&#39;&#93; = &#34;my_value&#34;[/QUOTE]

I hope this hasn&#39;t already been mentioned.

[ruebe]

Don&#39;t know if something like this has already been mentioned... Anyway: I&#39;d like to see a built-in debug-"window" in the editor (preview mission). Basically a list with all variables that has been defined, either in global scope or in scripts running at this moment.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
Global Scope&#58;
- obj1Failed = false;
- obj2Failed = true;
- ...

Script &#34;myScript.sqs&#34;&#58; &#40;runtime...&#41;
- _v1 = &#91;0,1,0&#93;;
- _v2 = &#91;1,0,0&#93;;
- ...
[/QUOTE]

The point of such a debug-window is to 1) see all variables and their values, 2) be able to quickly change these values&#33;

I hate to always make my own little debug-scripts (only to get/see some values or change them..), if there could be a built-in generic one.. http://forums.bistudio.com/oldsmileys/inlove.gif


best regards,
rübe

[Hawk666]

Hi,

I like in general the &#39;open&#39; engine of Arma and OFP and have tried to start to create an highly dynamic cqb mission (incl. enhancing the AI due to the existing AI of ArmA is just not capable enough) but it&#39;s difficult to realize, so here my suggestions:

- Ok, the script language/FSM is quite capable but since the language does not really support reuse of code (only isolated functions, no OO etc.) it&#39;s very hard not to loose the overview, especially if you want to reuse script/code of the community. That the language does not provide a &#39;real&#39; debugger does not help either.

To be honest, I&#39;ve hoped, that you have more time to develop Arma2/Game2, so they you may consider to drop your property script language and switch to a SDK by supporting a standard language (python etc.) with a clean class library. I know the compatibility issues to former mods etc. but what&#39;s the benefit of a script language that gets more and more commands and results in &#39;spaghetti code&#39; ; probably you have more and more work with the maintenance of your &#39;own&#39; code too?

- You&#39;ve introduced FSM in ArmA which is an improvement to OFP. But if you want to (or have to) micromanage the AI, you just have not all the needed (sensor) informations available (LOS as an example).
So, please, even if you try to vastly improve the AI this time (thumps up :-)) , give us the needed support to micromanage the AI by the script language.

[WARFIGHTER989]

The game should have rag doll physics and many more animations instead of just teleporting in a tank, how about you have the soldiers hop in the correct way? That would be cool.

[LtCmdrBoon]

I would like a couple of functions added

1) a settime command, instead of skiptime (or as well as) eg
settime "1500"

2) a "killedby" function, eg
to get name of the player who killed the opfor general

theguy = opgen killedby playername


I know the 2nd function there is a round about way of doing using a EH, but its my &#036;0.02

[Baddo]

Didn&#39;t see this mentioned yet:

XML and lots of it.

I just got done looking at Civ4&#39;s moddability and I must say it is the most fantastic thing I have seen yet as far as being able to modify a game.

Additionally, OFP was never really good at holding data externally very nicely. Error logs, positional data, ugh... the list could go on forever.
Uh it&#39;s a bit old comment but I must say this:

XML is relatively slow to process&#33; While it would be fine to have it as development-phase format, I would say some other format for a released product would be better. I&#39;m not sure if the BIS config files are much better when in ASCII, but if they are pre-parsed and "compiled" then its performance easily outperforms XML I would say.

Also, XML is meant to be processed by programs, not by humans. Readability-wise it is far from a good choice.

Just wanted to point out some negatives in XML, as you said &#39;most fantastic thing&#39; which is... well... a slight exaggeration? ***http://forums.bistudio.com/oldsmileys/xmas_o.gif

[kju]

Well XML is unified, that makes it easier to connect to 3rd party tools / software.

The engine could still preprocess the XML to a format which is best
for the engine once the game loads up. Its a matter of time
needed here.


Of course its hard to say if thats feasible,yet it would open many
possibilities for better software to support modding.


The current config style is neat to work with to a certain degree.
However I am very positive that with a XML format one could
write converters easily to get that look again.

[Baddo]

Yes I agree, if you are about to write tools then XML is nice. I&#39;ve done that myself and reading/writing XML is very easy to program. Even in C++ if you use TinyXML.

But there are drawbacks also, ones I mentioned already are readability problem and performance penalty.

If XML is going to be used, I suggest BIS should have a converter program which converts between their internal "pre-parsed, compiled" binary format and XML. That tool of course would be given to community. This way we can have the files loaded into the engine in an optimal format, but also have the files in XML if wanted so.

The binary file format should be BIS&#39; "secret", other people would then not need to do anything with it but just use the XML. This way BIS could change their binary file format and not break other peoples&#39; tools from working. Because their binary<--&#62;XML converter would handle the changes.

[CarlGustaffa]

So, if I made a mission and published it, I would use binaries for optimization reasons? And since it is "secret", no others can view my code?

Sorry, but that does NOT benefit the open community that exists today. De&#39;pbo&#39;ing a mission is the first thing I do when downloading it, looking for ideas and solutions.

And then there would be "hacks" around to defeat this encryption or whatever method was used. Maybe only elite guys would be able to use. No, I&#39;d rather have on-the-fly compiling ONLY. Precompiled files should not be possible to use. XML<->Binary converting is also a bad idea since something is bound to get lost in the process. Gives the greatest openness.

Sorry, but I couldn&#39;t disagree more strongly when it comes to "secrecy".

I&#39;m all for XML, if the tools would be available on game purchase. But I really can&#39;t see it happening for Arma2. I used to use RPN based XML when I "coded addons" for Flight Simulator. Easy to learn, especially if you&#39;re used to RPN (reverse polish notation, think HP calculators here) and gets rid of all use of paranthesis based arithmetics. For newcomers, it does take a little bit of getting used to though.

That being said, sqf syntax works very good for me, why fix it if it ain&#39;t broke? My only complaint about sqf from a newbie point of view, is that it is very hard to grasp that if only a single parameter is needed it comes after the command. And in front when there are other parameters behind. Confusing stuff. Ex:
removeAllWeapons this
this removeWeapon "Binocular"

Agreed on the ray.intersect. Call with [3D position (from), width of cone, maxdistance or to 3D position (to)], and return [3D position, object id]. Maybe an accuracy number would be needed to tell how many random rays to test within the cone. Greater accuracy and distance would take longer to check though.

Someone wrote, "even idiots can script". I think "idiots" actually can script today if needed. The problem isn&#39;t always with the scripting itself, but also how the engine tends to overrule what you want. Ex, vehicle light discipline follows combatmode, and no matter what you do the command won&#39;t work ingame. Another one, there exist an allowGetIn command, but no allowGetOut command in case you as a scripter wants to create an attempted getaway instead of the default disembarking upon contact.

[Baddo]

So, if I made a mission and published it, I would use binaries for optimization reasons? And since it is "secret", no others can view my code?

Sorry, but that does NOT benefit the open community that exists today. De&#39;pbo&#39;ing a mission is the first thing I do when downloading it, looking for ideas and solutions.

And then there would be "hacks" around to defeat this encryption or whatever method was used. Maybe only elite guys would be able to use. No, I&#39;d rather have on-the-fly compiling ONLY. Precompiled files should not be possible to use. XML<->Binary converting is also a bad idea since something is bound to get lost in the process. Gives the greatest openness.

Sorry, but I couldn&#39;t disagree more strongly when it comes to "secrecy".
Did you skip certain parts of my post? Because you missed something very important, I think.

Didn&#39;t I speak about a tool to convert between binary and XML? I think I did, IF XML is going to be used THEN it would be better to optimize it into binary format for release. There is a significant performance penalty when reading XML instead of binary. My argumentation was an effort to combat that performance penalty, not to prevent you from looking at data files.

When I said "secret" I meant that it would not be necessary for other people than BIS to deal with the binary file formats. Because we would have a program to convert between XML and binary formats. It would still be possible to read the binary files too, just like many people have done this far with the many binary data file formats of OFP and ArmA.

Encryption? What are you talking about? To my knowledge there is no encryption of game data in the data files of OFP/ArmA, and I think there won&#39;t be in ArmA 2 either. Compression exists but that is certainly not comparable to encryption.

Also, I think you are totally wrong in the "something is bound to get lost in the process" part. Nothing would be lost because the XML converter tool would know the file formats. If it didn&#39;t know the file formats, then your argument would be valid. Think about this for a second time please.

I think the word "secret" might have fooled you a little bit, so I&#39;ll forgive you for misunderstanding my post.

Also, XML would not be used for scripts. That makes no sense. But for storing data. That is a significant difference.

Don&#39;t worry, nothing that has been suggested of XML or XML<--&#62;binary converter here is going to prevent you from looking at data or from learning.

[CyDoN]

i am not sure if this is in the right place to post this but it would be a good idea to be able to drop weapons and pick up easier without pressing the G button especially when droping for instance the AT. it ll be better to just drop it at once without stoping for a while.

[ArMoGaDoN]

One thing that would be very useful from a mission design perspective would be the ability for a server&#39;s script to send a message (publicVariable or similar) to a single specific client, or perhaps to one of a list of clients only (the server would, of course, need to allow the list of clients to be available, and an event function for new-joiners would also be required).

If this could be provided then some much more advanced map types could be developed without increasing lag or network traffic significantly.

[lwlooz]

Network Scripting
I second that of course. While I am grateful about BIS implementing addPublicVariableEventHandler (http://community.bistudio.com/wiki/addPublicVariableEventHandler), I hope they have the time to further enhance the network scripting in ways already mentioned in this thread , which consists of adding a sending function and resources about clients. One example of an implementation could be:

1.Sending Function

Data SendTo [Destination, "Function"]

-Data: All Types of ArmA Data
-Destination: Either an array of Destination-IDs(like in CoC_NS) or preset destinations like "All" , "Clients" , "Server" , "West" , "East" , "Group" , "Vehicle".
-Function: String of any defined variable storing a function on the destination PC . If there is none nothing happens.

2.Resources
To get ID's one could have resources like:
UserID (ID of the computer executed on)
getUserID object (ID of an object)
Users (Array filled with relevant data about all clients)

Also some more Bool-Status Checks would be nice along with IsServer:
IsClient, IsClientJIP, IsAdmin, IsServerDedicated
(I do know that there are indirect ways of telling some of this in ArmA , but that method might not work anymore in ArmA2)


Displays/Dialog
The second area where BIS could in my opinion continue the work (given time) they started in ArmA is to bring the ideas they probably had about createDisplay (http://community.bistudio.com/wiki/createDisplay) actually into the game.
As of ArmA 1 createDisplay used on user-defined description.ext entries works exactly like createDialog. Now the new dialog functions in ArmA are very neat indeed , but what the old dialog system lacks is interoperability between 2-n systems.You can only open one dialog at a time.

This is where I thought createDisplay would come in , as allowing the scripter to open Child-Displays/Dialogs on a parent display/dialog. Therefore a modified createDisplay function is my suggestion for ArmA2:
IDD = parent createDisplay "Resource".
This means that resources should in my opinion no longer define the IDD's they have in their definitions , but should get one assigned. Which also means that one can load the same resource more than once.
In addition to this one extra display "User Interface Eventhandler" onChildCreated would allow the scripter to handle the new child-display.
Also one could give the child display the ability to catch events of its parent with an display "User Interface Eventhandler" onParentEvents which would provide the handler function with the parameters [parent-display,"HandlerName",[Handler-specific Parameters]]

Another limitation of the ArmA 1 engine as I perceive it , is the fact that you only can run around the simulation in displays defined in the config and created with createDisplay and can only not have the focus on displays(I.e aim) with them defined via RscTitles and brought to screen with cutRsc,titleRsc(Which means you can only have two of them). It would be very nice if all of this different behaviour could be defined within the display definition:
-enableChildDisplay = 1/0 : Can have or not have child displays
-forceFocus = 1/0 : Either doesn't force focus(You can run and aim) or acts like old dialogs
-enableInteraction : 1/0 : One can interact with the dialog or it is just a info-window

If forceFocus is set to 0 and enableInteraction to 1 on a child of the Main-Display for example , this would mean that we can run around and aim , but there is still an dialog somewhere on the screen we could interact with. Because of that I propose a extra key "Interaction". If we press this one , our aim-cursor changes into a mouse-cursor and we can select all interactive dialogs on the screen , another key-press and we are back to running and aiming.

I hope that in ArmA 2 we like in ArmA 1(with "findDisplay 46") can use the MainScreen and hopefully the MainMap Screen too.
I apologize if something of this is already present in ArmA1 or I got something wrong.

[bn880]

Further to that I would encourage BIS developers to review some of UNIX&#39;s (SUN Solaris QNX) interprocess messaging schemes (IPC). Adopting something similar would kill any further frustration users may have with message/data passing in "OFP", it also is a good insight to concurrent processing.

[Aeon]

--
About "playMusic nameAndpos" command (source: scripting commands-wiki) :

Quote[/b] ]playMusic nameAndpos
Plays music defined in the description.ext file. The format of nameAndPos is [name,position]. Position is in seconds.
Example : playMusic ["Track13", 30]

A good improvement for this command would be to introduce a third parameter in the array, where "loop" enumerate how many time the music have to repeat :
playMusic [name,position,loop]


Examples :

playMusic ["Track13", 0, 1]
Track is played from the beginning and only once.

playMusic ["Track13", 10, 5]
Part of the track (from 10&#39;&#39; to the end) is played 5 times continuously (without blank between cycle).

playMusic ["Track13", 10, -1]
Part of the track (from 10&#39;&#39; to the end) is played to infinite. Untill another playMusic command, or fadeMusic 0.


So, mission-makers would not have to manage loop and waste ressource (fill/empty buffer) through *.sqf "sleep X;" wich could be unreliable.

[mr.g-c]

I would like to see a command to change a players skin/model during a multilayer game.

Example Situation: Player is Civilian and joins the Army (at a triggered house), then his modell should be able to change from civilian into a soldier.

Best Regards, Christian

[Chaos]

We need a command to ask about the viewdistance. In the case of ArmA 1 & OFP the appropriate command doesn´t exists.

For Example:
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_vDist = viewdistance[/QUOTE]

[Wolfrug]

Since it hasn&#39;t been suggested yet:

Add a "getTeam"-equivalent command to go with the assignTeam (http://community.bistudio.com/wiki/assignTeam) and unassignTeam (http://community.bistudio.com/wiki/unassignTeam) commands. Currently they&#39;re just there for flavour, whereas they could exist for actual use (i.e, if (getTeam aPDude == "GREEN") then {aPDude sidechat "I am now going to do something special&#33;"}; :P (also make the AI -not- randomly unassign the teams once they&#39;ve been assigned, eh?)

Regards,
Wolfrug

[dentist guba]

i think my wish has already been granted before i asked, the database thing sounds like it will teach people (including myself) how to script and put mission editing in the hands of anyone who wants to do it. i will probably buy the PC version just for this as i will be doing a game design course and this could help me a lot.

[Straubinger82]

Yes, I´ve seen that too and it´s really amazing.
The implemented Editing Guide (formaly known as the "holly bible") presented by Murray & Co. should really help me.
I will stay tuned for that...

In that way, BIS overworked the editor, we all wished that for ages^^. Thanx for that.

[[GLT] Legislator]

I&#39;ve got a suggestion too. Everytime I want to change to height of an unit or object I had to enter: this setpos [(getpos this select 0), (getpos this select 1), 10];

So far, so good. But this sucks if you&#39;ll have to do it a lot of times. http://forums.bistudio.com/oldsmileys/sad_o.gif How&#39;s about something like that: this setHeight 10; for example? It would make mission editing a little bit faster.

[Baddo]

We need a command to ask about the viewdistance. In the case of ArmA 1 & OFP the appropriate command doesn´t exists.

For Example:
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_vDist = viewdistance[/QUOTE]
Yes, yes.

I added this wish into the http://community.bistudio.com/wiki/ArmA:_Wish_List#Commands some time last year.

and I think it should be added to the ArmA II. It doesn&#39;t sound like a major change into anything, just a function which returns a value, nothing more.

The benefit, as I was thinking at the time when I added it to the Biki Wish List, was that it would be much easier to write scripts which take the current viewdistance into account without having to set the viewdistance (then it would be known). It may not be appropriate to set it, so we would need this function to just ask what the existing value is.

[SnR]

Im interested in the Logitech G15 keyboard gaining appropriate ArmaII Plugins http://forums.bistudio.com/oldsmileys/thumbs-up.gif

[Loki]

maybe a playMovie command.

it would be nice to make movies and play them in game as cut scenes.

and a dedicated servers ability to &#39;look&#39; through a potential players addons and see if they have an addon that is known to crash games. and deny them connection.

it is hard to have an open public server when one knows a new faulty addon has come out.. and it takes months before most people realize what is causing it.

[Deadfast]

variable++ and variable-- as an alternative to variable = variable + 1 and variable = variable - 1

It&#39;s pain in the ass doing loops without it http://forums.bistudio.com/oldsmileys/wink_o.gif

[Taurus]

If someone mentioned better support and explanations of the commands on the wiki about locality in MP I do agree.

i.e.
What can be done and can not be done executed from init lines etc, what can and can&#39;t be done with players.

In a utopia I&#39;d like to see the whole "client server" thing removed.

[wipman]

Hi, i&#39;ll like to see a kind of weaponry randomizer; as a game logic
placeable in the editor and affecting a given side (W,E or Res) that
affects the units by their class.
If you&#39;ve various weapons for the base soldier (i.e: soldier_wb) like
M16A4 Iron, ACOG, Aimpoint or Eotech sighted... then auto randomize
the weaponry of all the soldiers to swap their main weapons for different
ones, in that way... we&#39;ll get a less fixed shape on the units so they
look more real instead of clones; removing too the tedious job of
rearm squad after squad with the default available weapons. Let&#39;s C ya

[CarlGustaffa]

Randomizing is easy enough with scripting.

Not sure what has been covered yet, but here is a short list:
1. Set and Get commands for number of rounds in a magazine.
2. Get versions of support vehicle amount, i.e. setFuelCargo. I know no way of obtaining the amount using script.
3. Remove double listed commands, such as direction if getDir already exists. Reduce the confusion.
4. Every set command should have a get command and vice verca. Only commands that have one type should have it in "words", such as distance (since there cannot be a setDistance, there shouldn&#39;t be a getDistance, and distance is enough).
5. New command getMarkerGeom, which retrieves elliptic or rectangular shape (and maybe polygonal if implemented).
6. New command (marker) isInside "markername", (trigger) isInside trigger, and (boundary object) isInside object, to test if a point lies inside. The boundary version tests in all three dimensions (maybe also trigger?). I have made such a (2D only) function here (http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?act=ST;f=71;t=69639;hl=inside+and+ma rker), but I think maybe BIS have a better way of doing this.
7. New command rayIntersect [posa3d,posb3d] which returns the array [distance, object] from posa3d. I.e. rayIntersect[getPos player, getPos "house5"] returns [15, "terrain"] or [15, objectID]. This would enable us to test for line of sight.
8. Binary commands for maths (similar to arrays) and logical testing.

[dentist guba]

i will post this here as well as in the ui thread.

how about a more user friendly way of creating missions based around selecting conditions and actions (similar to timesplitters 3 or MMF2).

e.g., for hostage mission

Step 1: set condition "enemy soldier alerted"
Step 2: set action "kill these civilians (the hostages)"

this could allow newbies and console players to create scripted stuff for missions but also allow more experienced designers to quickly prototype.

continuing on the Multimedia Fusion example, these scripts and behaviour templates could be thougt of as plugins and new, fan made scripts for actions and behaviours could be added to the folder with the rest and selected in seconds.

hell, there could even be a way to export a collection on conditions and actions as a mod.

BIS could also get in on the whole microtransaction market by releasing new conditions e.t.c. in packs.

using this type of mission scripting could improve the fan creation aspect on xbox live as well as it is a controllable way of making new missions (microsoft would be less wary of fan creation when it is controlled a la far cry).

[twisted]

more ideas:

FSM override - ability to TOTALLY override inbuilt AI FSM with new modded AI at will and switch back at will while carrying AI info over if needed.

get/set number of bullets in magazine

get/set/limit the player/AI turning angle based on weapon selection and stance

ability to have a weapon in different states - Bayonet on, Bayonet off, bipod up, bipod down and have that change elements of weapon. make this moddable as to what influences weapon state.

extend FSM to influence a group as well as individuals.

[CarlGustaffa]

Some kind of debug tool or command, called debugChat (?), that allows a client to see what is going on on a dedicated server, ***easily. I.e.
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
if &#40;&#33;isServer&#41; exitWith {}; //clients will exit here.
_text = &#34;hello&#34;;
if&#40;debug&#41; then {
***_text = format &#91;&#34;text&#58; %1&#34;,_text&#93;;
***server debugChat format &#91;&#34;_text is now %1 on the server&#34;, _text&#93;;
};
[/QUOTE]

It could show up on the client in dedicated red color and look like:
SERVER - DEBUG: _text is now hello on the server

Forcing the DEBUG in the string might prevent designer to using this as a quick replacement for any PVEH&#39;s which would be the correct way. It should be displayed when in singleplayer, serving/hosting client, and when on a client using a dedicated server.

[Chaos]

I think that we need some new commands. But for my personly are <span style='color:red'>following both important:</span>

<span style='color:blue'>- possiblity to switch the gear (scripted reverse move for tanks)
- switchlight OFF for vehicles that are moving in "safe" or "careless" mode.</span>

[CarlGustaffa]

Possibly already covered, but a pos2grid function. AI will already report position as a grid reference using whatever format the map is in. Scripters should have this possibility too. It is a must. I consider myself a casual scripter, and looking at solutions like SPON_Map just frustrates the hell out of me trying to implement it in my own mission.

[Inkompetent]

I&#39;m quite sure this has been mentioned earlier, but I&#39;d like to see a possibility to alter values from the config on the fly in the game.

Per default an object would simply contain a pointer to its own class (as I assume it does now), but if this is modified it&#39;d get own instance of variables.

My main gripe is the workarounds needed to create air-burst munitions, since with the above possible I could catch the shell with a fired EH and alter its timeToLive variable to the desired value, but I&#39;m sure there are hundreds of other uses to this as well, be it equippable body armour altering armour values, wear&tear on weapons changing their built-in dispersion, etc.

[CarlGustaffa]

Probably not the correct place, but since you added it here, yes; builtin support for airburst ammunition such as icm&#39;s. Also Abrams canister rounds, M203 buckshot; ammunition that produces multiple submunitions.

Trying to script these doesn&#39;t work very well in multiplayer.

[mr.g-c]

Well, if they would do Arma2 Properly this time in terms of realistic behavior of weapons, then such stuff would be there by default....
However i hate to say it but i personally doubt that we will see any more realism in this manner in Arma2 - even though such munitions like Canister round or Airburst Grenades are very common on todays battlefields.....

I really hope BIS reads that and consider some seriously military advisory. (Anyone remembers that they didn&#39;t knew until patch 1.08 or so, that APFSDS Rounds don&#39;t do large explosions.........)

[Johnnie_Walker]

I&#39;m quite sure this has been mentioned earlier, but I&#39;d like to see a possibility to alter values from the config on the fly in the game.

Per default an object would simply contain a pointer to its own class (as I assume it does now), but if this is modified it&#39;d get own instance of variables.
That would really be very usefull. As an example, we could modify tanks armour on warfare maps, to add some nice tank battles.

[wipman]

Hi, i&#39;ve had a silly idea; to attach actions to certain objects, for
example to doors and human size gates, to allow the player to open
&#39;em up by two methods, Breach Door and Kick Door. And then allow
the player to perform this actions when he&#39;s at 0&#39;5m from the target
door; in this way we could also send an AI to open up the door while
we cover it in case of direct OPFOR presence... or some defensive
position after the door. All this with the propper animations fired
by the performed action and that they dissapear if the object (door
or entire wall section) is previously destroyed. Let&#39;s C ya

[Spooner]

7. New command rayIntersect [posa3d,posb3d] which returns the array [distance, object] from posa3d. I.e. rayIntersect[getPos player, getPos "house5"] returns [15, "terrain"] or [15, objectID]. This would enable us to test for line of sight.
We can already do this perfectly well with the standard intersect command. The only issue is in fact that intersect only "collides" with named selections and only infantry have named selections covering their whole body (buildings and things don&#39;t have any names; vehicles have a small number of parts named). Thus we could have this entire functionality in ArmA 1 if BIS had named the selections of objects they put in the game. I&#39;m hopeful that they remember to do this for A2 http://forums.bistudio.com/oldsmileys/wink_o.gif

[Q1184]

I really miss a function that would return a list of vehicle/ammobox cargo magazines/weapons. Something like _mags = transportmagazines _weaponbox1 and _wpns = transportweapons _veh. Currently we can retrieve the initial list set in the config, but it is impossible to track the contents in game.

[Wolfrug]

I really miss a function that would return a list of vehicle/ammobox cargo magazines/weapons. Something like _mags = transportmagazines _weaponbox1 and _wpns = transportweapons _veh. Currently we can retrieve the initial list set in the config, but it is impossible to track the contents in game.
QFT

[mr.g-c]

A scripting command to get "weaponholders" contents or any other way to "pick-up/move/whatever" dropped weapons by script.

(Today i found after 5 hours scripting and much backtalk with "Xeno" out, that this is not possible in Arma1 http://forums.bistudio.com/oldsmileys/wow_o.gif )

[Celery]

An eventhandler that triggers when the unit kills/destroys another unit or object. It would make score modifications SO much easier without giving a "killed" eventhandler to every unit in the mission. It would also enable you to make a hunting mission with scores because if I&#39;ve understood correctly, animals are generated into the world rather than placed so giving eventhandlers to them could be tricky.

[Q1184]

Hit/dammaged eventhandlers could return more useful information:
- Type of ammo object that hit the vehicle (if the damage is &#39;indirect&#39;, eg from a grenade, the object class should still be returned). Ideally, run-over-by-a-car and fell-from-the-roof situations would also be handled.
- Current &#39;hit&#39; value of the ammo object
- Model coordinates of the impact point (hit selections are too vague). If it&#39;s HE damage, model coordinates of the exploded ammunition should be returned.

It also seems a good idea to introduce a damage threshold for vehicles - ie, if the vehicle is hit with force less than specified in its config, the damage will not be taken at all. It will remove the absurd situation with machineguns destroying heavy tanks etc. This value may also be set per selection rather than for the vehicle as a whole.
Hit eventhandler, on the other hand, should not have the threshold for triggering it has now.

These modifications will allow the community to create detailed damage/wounding systems without having to recur to very complex and CPU-intensive workarounds.

[h -]

Quote[/b] ]Hit/dammaged eventhandlers could return more useful information
http://community.bistudio.com/wiki/VBS2:_Event_Handlers
VBS2 eventhandlers.. ***http://forums.bistudio.com/oldsmileys/confused_o.gif

I so hope at least those will be implemented in Arma 2.

[mr.g-c]

These modifications will allow the community to create detailed damage/wounding systems without having to recur to very complex and CPU-intensive workarounds.
Perfect Suggestion&#33;&#33;&#33;
I have sent Suma a PM, so hopefully he looks over the suggestion in future ***http://forums.bistudio.com/oldsmileys/tounge2.gif ***http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[CarlGustaffa]

Not sure where to put this, but... Please BIS, so something about the thunderstorms. I&#39;m not saying that the worst possible weather shouldn&#39;t have thunder like it is today, but some in between levels would have been nice. Like thunderstorms being possible gradually from 0.8 to 1.0. At 0.8, a thunderclash maybe only every 5 minutes or so.

The current only level is so insane it drives me mad.

[Lou Montana]

The current only level is so insane it drives me mad.
Actually, it was only made to test Civilian_Undead_1-4... http://forums.bistudio.com/oldsmileys/biggrin_o.gif

Grrreat ambiance with that http://forums.bistudio.com/oldsmileys/smile_o.gif

[Chaos]

A special "turn on place" command is needed for tracked vehicles like tanks. So the commanders can turn the most armoured side (the front) towards enemy.

Another very usefully, and needed command is, "reverse gear". So can ai controlled tanks move backward a longer route and turn the best armoured side towards enemy. This is for me very important.

[[APS]Gnat]

Not sure if its been mentioned before, but it should have been because it seems such a big miss from OFP and ArmA

A command that returns the <span style='font-size:11pt;line-height:100%'>SELECTED / LOCKED TARGET</span>
i.e. The current object (target) within the square onscreen selector.
The command should also return if its locked, i.e. Diamond over square.

please, please http://forums.bistudio.com/oldsmileys/notworthy.gif

[Crowe]

Dear BI developers,

i don't know if it has been mentioned before. How about implementing a scripting command that downloads strings from a URL?

This would give mappers the possibility to:

provide mission files with automatic updated scripts
the mission to interact with a database


Example:


PRIVATE ["_script"];
_script = loadurl "http://somehost.tld/website/latest-script.sqf";
[] spawn compile _script;


Example for Interacting with a database:


WESTSCORE = 320;
EASTSCORE = 210;

PRIVATE ["_result"];
_result = loadurl format ["http://arma2-liga.de/SubmitScore.php?west=%1&east=%2",WESTSCORE,EASTSCORE];

//SubmitScore.php will save the arguments
//passed via HTTP GET into a database.


Thanks in advance!

Regards

Crowe

[PhilippRauch]

but you know Armalib already? if so nevermind my post :). But im sure something like that will emerge soon after ArmA2 release, although 'built-in' is always (?) better .

[Crowe]

but you know Armalib already? if so nevermind my post :). But im sure something like that will emerge soon after ArmA2 release, although inbuild is always (?) better .

Arma Lib does not work on linux servers and it is detected by BattlEye.

Regards

Crowe

EDIT: As i see some kind of similar feature request has already been made: http://forums.bistudio.com/showpost.php?p=431488&postcount=104

[Crowe]

Gnat;1267389']Not sure if its been mentioned before, but it should have been because it seems such a big miss from OFP and ArmA

A command that returns the SELECTED / LOCKED TARGET
i.e. The current object (target) within the square onscreen selector.
The command should also return if its locked, i.e. Diamond over square.

please, please http://forums.bistudio.com/oldsmileys/notworthy.gif

Seems already to be implemented:

http://community.bistudio.com/wiki/assignedTarget

[SaBrE_UK]

Isn't that the ordered target rather than the selected target? I wouldn't know, though.

[Buliwyf]

Hi..

I would like to see an simple array of own side players. Actual there is a command named playersNumber side, so something like playerNames side would be great.

:rolleyes:

[Celery]

Hi..

I would like to see an simple array of own side players. Actual there is a command named playersNumber side, so something like playerNames side would be great.

:rolleyes:

"players side" would cover the whole thing: you can pick both their names and their number from the same array.

[SirSmok@lot]

Mayeb late in teh game for this one:

Refer to player position in vehicle better. Meaning instead of Unit as player as driver only and be able to refer to commander and gunner position more accurately. This seems to be an issue with alot of scripting since you have to settle for unit as driver in most cases.

"is Player == Commander" as a reference and similar. Defining player position better would be nice. If there's a better way to reference this please let me know!

[Crowe]

SirSmok@lot;1270248']Mayeb late in teh game for this one:

Refer to player position in vehicle better. Meaning instead of Unit as player as driver only and be able to refer to commander and gunner position more accurately. This seems to be an issue with alot of scripting since you have to settle for unit as driver in most cases.

"is Player == Commander" as a reference and similar. Defining player position better would be nice. If there's a better way to reference this please let me know!

I think there are enough vehicle assignment funtions :confused:
I dont understand what you want them to improve exactly.

http://community.bistudio.com/wiki/commander
http://community.bistudio.com/wiki/gunner
http://community.bistudio.com/wiki/driver

(more: http://community.bistudio.com/wiki/Category:Command_Group:_Vehicle_Assignment)



if (player == driver vehicle player) {
hint "You are the driver. Drive!";
};

if (player == gunner vehicle player) {
hint "You are the gunner. Shoot!";
};

if (player == commander vehicle player) {
hint "You are the commander. Command!";
};

[Crowe]

A function to get the ping to the server would be useful :)

regards

Crowe

[CarlGustaffa]

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?

I.e. stuff like:
normalizeValue [value, minrange, maxrange] returns value as 0-1 if within range.
posDirection [position1, position2] returns direction in 0-360 degrees.
polarAdd2d [position, direction, distance] returns new 2d position.
getHeight [object] returns AGL.
getAltitude [object] returns MSL.
and many more.

[d3nn16]

getMarkerShape : similar to setMarkerShape. Would return "ICON", "RECTANGLE" or "ELLIPSE".

I need this command in a ctf map template where map makers place markers and the template scripts create the corresponding triggers (with same shape and size as the markers). I'm currently using a workaround with the names of the markers but it is too cumbersome to use with lots of markers.

getTriggerArea : similar to setTriggerArea. Would return [x radius, y radius, angle, is_rectangle].

I need this command for the same map template where I parse all existing markers and create an array of trigger references. Instead of reusing the array containing the triggers which in turn contain the markers' sizes and shapes I have to create a separate array containing the markers' sizes and shapes that I need to place objects around the markers' edges.
This would mostly help simplify the code.

isAdmin player : would return true or false if the unit is controlled by a player who is admin.

The reason I want this command is because I'm making a voting script and players don't really take the time to vote game parameters. A way to determine which player is the admin can allow a script to show him a dialog so he can quickly change the variables for the game like weapons, weather, etc.

[d3nn16]

More parameters to be defined in description.ext file, for now there are only 2 :

titleParam1 = $STR_PARAM1_TITLE;
valuesParam1[] = {};
defValueParam1 = 0;
textsParam1[] = {};

titleParam2 = $STR_PARAM2_TITLE;
valuesParam2[] = {};
defValueParam2 = 0;
textsParam2[] = {};

And so this would go on up to a certain limit :

...

titleParam19 = $STR_PARAM19_TITLE;
valuesParam19[] = {};
defValueParam19 = 0;
textsParam19[] = {};

titleParam20 = $STR_PARAM20_TITLE;
valuesParam20[] = {};
defValueParam20 = 0;
textsParam20[] = {};



The way this could be represented in the lobby is :

In the left list box the names of the parameters would be listed :
--------------
| TimeLimit |
| ScoreLimit |
| Weapons |
| Weather |
| ... |

In the right list box the values of the parameter selected in the left list box :
For instance if Weather was selected in the left list box this would show in the right list box :
--------------
| Cloudy |
| Stormy |
| Sunny |
--------------

[Sil]

Please to do some random utilities, to be able to do things like
- select random player in group
- select random place in some area
etc.

[MadDogX]

Please to do some random utilities, to be able to do things like
- select random player in group
- select random place in some area
etc.


There is already a random command. You can use it to create functions for whatever you want, for example selecting random players and positions. It's very versatile.

[NeMeSiS]

Please to do some random utilities, to be able to do things like
- select random player in group
- select random place in some area
etc.

http://community.bistudio.com/wiki/random

[mr.g-c]

I would like to have the possibility to get "distance" bases on "axis"....
Currently when i use the "distance" command i get distance based on all 3 axis (3D).... however i would love to only get distance on horizontal or sometimes only vertical base.

This also for commands like "nearestObjects" and similar ones.
For instance if i only want to get the nearestobjects of type "man" in horizontal, then maybe like this:

_whatEverArray = nearestObjects [_unit, ["MAN"], (xy)50];or so.... (xy) to illustrate only on horizontal way.... if for full 3d maybe (xyz) as prefix....

[Deadfast]

Just do a little math...



_x = _x2 - _x1;
_y = _y2 - _y1;
_z = _z2 - _z1;

_xy = sqrt(_x*_x + _y*_y);

[Lou Montana]

you can also do
[getPos g1 select 0, getPos g1 select 1] distance [getPos g2 select 0, getPos g2 select 1] ;)

[Deadfast]

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

[Lou Montana]

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]

What are you talking about?

You indeed can create your own functions.

[Lou Montana]

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

[MulleDK19]

I want Lua!!!

[NeoArmageddon]

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! :yay:

[Issetea]

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]

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

[CarlGustaffa]

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 (http://community.bistudio.com/wiki/markerShape).

isAdmin is still missing...

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

[Ravice]

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.:yay:

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

Ravice

[Maximus2015]

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]

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]

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]

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]

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?

[ruebe]

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:
http://non.sense.ch/shared/FN_randomCirclePositions_2.jpg

[Cato Larsen]

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 :)

[ruebe]

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. :yay:

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? ;)

[code34]

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.

[ruebe]

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 :/

[d3nn16]

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.

[ruebe]

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

[Charon Productions]

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. http://www.flashpoint1985.com/ikonboard301/iB_html/non-cgi/emoticons/confused.gif

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]

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]

Would love to see getMarkerDir and setMarkerAttached in Arma 2.