Scripting

[raedor 8]

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

if (getStatus player == standing) then {player playMove "CombatToPutDown"} else {player playMove "PutDownLyingToLying"}<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 [axis, number]

e.g.:

trigger1 setAxis [a,50]

or

triggerName setActivation [side, class]

e.g.:

trigger1 setActivation ["west","tank"]<span id='postcolor'>

[Rune 0]

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 'Max Payne' 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't leave it out just because you don't think anyone would want it or because it is very easy to make crap missions with it.

[uiox 0]

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

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

You can't build a global variable for each of object of a same addon.

Or global variable relates to an object.

[Cannon Fodder 0]

A cut and paste 'Script Board' 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'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!

Even better was an idea suggested by Peaknuckle a little earlier about a 'Point and Click' 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 8]

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

I don'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 { |unit|

unit.damage = 0

unit.sayRadio("I feel great!")

}

<span id='postcolor'>

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

Great?

[tracy_t 0]

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

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.

[raedor 8]

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

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

[bn880 5]

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

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

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

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

[tracy_t 0]

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't fired a shot?  Why should my soldiers run for cover? They might not know they're being targetted yet!

PS: I don't like the fired event handler - it doesn't tell you where the bullet is aimed at according to the Flashpoint command reference. I suppose you'd have to use NearestObject to get a reference to the bullet and manually work out its trajectory!! Yuk

Cheers,

Tracy.

[bn880 5]

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

I have build a draft of radar, for the moment i use a trigger, it's for my script suite of uv addons, and I'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 ---> boolean (of course it's not relate to distance but the possibility relates to terrain (add buildings? great! )

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

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

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

Simplify? In OFP1 you can'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't script in MP.

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

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! 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 (someunit.damage() > 0.5)

{

  someunit.damage(0);

}

You can get access to the unit's damage value by using an overloaded method (no parameter: GetDamage behaviour; parameter: SetDamage behaviour). Ensures object encapsulation...

[Dirt 0]

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.

[Guest]

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(myA10)

That returns:

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

["All","AllVehicles","Air", "Plane", "A10"]

[toadlife 3]

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

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

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

[friendlyfire 0]

OK, but I would suggest that learning a bit of SQL was fairly mild compared to some of the ofp scripting I've seen here!

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

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

Resistance doesn't crash on errors like CWC did, are you using resistance cideway?

[bn880 5]

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