Scripting

[Scrub 0]

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 'Z' 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 0]

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'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 0]

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 3]

Didn't see this mentioned yet:

XML and lots of it.

I just got done looking at Civ4'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 0]

More overall access to gamestate for scripters ie:

---

[*]bindKey function (bind scripts to a key or combination on keyboard)

...

And bindMouse.

[djura 0]

ex:

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

where NEAREST_BUILDING is a predefined BIS constant. And yes, TakeCover is a predefined function

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'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 1]

Suma[/url]+Mar. 04 2003' date='07:38)']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's scripting language . . .

Something like

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

string[0] == "s"

; or

string select 0 == "s"

; or

array = str2array string

array select 0 == "s"

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 = [entry1, entry2, entry3]

array[0] == entry1

; associated arrays

array['my_key'] = "my_value"

I hope this hasn't already been mentioned.

[rübe 127]

Don't know if something like this has already been mentioned... Anyway: I'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:

- obj1Failed = false;

- obj2Failed = true;

- ...

Script "myScript.sqs": (runtime...)

- _v1 = [0,1,0];

- _v2 = [1,0,0];

- ...

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

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

best regards,

rübe

[Hawk666 0]

Hi,

I like in general the 'open' 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'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'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 'real' debugger does not help either.

To be honest, I'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's the benefit of a script language that gets more and more commands and results in 'spaghetti code' ; probably you have more and more work with the maintenance of your 'own' code too?

- You'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 0]

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 0]

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 $0.02

[baddo 0]

Didn't see this mentioned yet:

XML and lots of it.

I just got done looking at Civ4'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's a bit old comment but I must say this:

XML is relatively slow to process! 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'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 'most fantastic thing' which is... well... a slight exaggeration?  

[.kju 3244]

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 0]

Yes I agree, if you are about to write tools then XML is nice. I'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' "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' tools from working. Because their binary<-->XML converter would handle the changes.

[CarlGustaffa 4]

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'pbo'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'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't disagree more strongly when it comes to "secrecy".

I'm all for XML, if the tools would be available on game purchase. But I really can'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'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'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'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'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 0]

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'pbo'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'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'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'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'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'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'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't worry, nothing that has been suggested of XML or XML<-->binary converter here is going to prevent you from looking at data or from learning.

[CyDoN 0]

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 0]

One thing that would be very useful from a mission design perspective would be the ability for a server'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 0]

Network Scripting

I second that of course. While I am grateful about BIS implementing 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 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.

Edited April 10, 2009 by lwlooz

[bn880 5]

Further to that I would encourage BIS developers to review some of UNIX'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 0]

--

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'' to the end) is played 5 times continuously (without blank between cycle).

playMusic ["Track13", 10, -1]

Part of the track (from 10'' 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 6]

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 0]

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

[Wolfrug 0]

Since it hasn't been suggested yet:

Add a "getTeam"-equivalent command to go with the assignTeam and unassignTeam commands. Currently they'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!"}; :P (also make the AI -not- randomly unassign the teams once they've been assigned, eh?)

Regards,

Wolfrug

[dentist guba 0]

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.