Scripting

[uiox 0]

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!

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

[raedor 8]

yes, a debug is a very good idea!

not only for scripts, but also for description.ext! 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 0]

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

Other note: I'm not sure if its already possible...but to be able to control your character while having a dialog up (provided you aren't using a camera affect with it)

[OneStiffRod 0]

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

well i'm not sure if its been mentioned yet... i did a search on nearest object but couldn'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'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

oh well....just a thought...and would come in handy

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

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've heard that you can have the computer aim or shoot at game logic points (might be me but i can'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 0]

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

I object to any change of syntax personally. OFP1 script works great for me, I can't think of an easier syntax (maybe because I'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's really nothing you can'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'm all about the ability to change a unit's vehicle type midgame. Would open up a world of possibilities.

[SilverB1rd 0]

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

Edited couse i posted at the wrong place..........

[johnnylump 0]

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

unit getAmmo

unit setAmmo

That way we don'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 5]

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?

[Skumball 0]

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

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

Above all, though: OFP is a distributed, real-time simulation. Make the scripting language work with that. Unambigously and *very* clearly documented.

[superskunk 0]

another important thing:

MAKE ALL OBJECTS POSSIBLE TO USE IN EDITOR, SO NO ADDON IS NEEDED!

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

Ss

[Gollum1 0]

another important thing:

MAKE ALL OBJECTS POSSIBLE TO USE IN EDITOR, SO NO ADDON IS NEEDED!

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

Ss

Yep, I agree.

[Harnu 0]

getTarget "guy1"

Able to name a persons target in a script. And getting it's position, distance, height. Etc.

[kegetys 2]

I object to any change of syntax personally.  OFP1 script works great for me, I can't think of an easier syntax (maybe because I'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'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'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.":

and as I select or type "engine":

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

That'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's you assign any type of value to any variable on the fly, this would probably have to be stopped.

[kegetys 2]

A whole can of worms would be opening up with OFP, as it let's you assign any type of value to any variable on the fly, this would probably have to be stopped.  

huh?

[bn880 5]

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's like allowing you to assign a control object to an Integer variable, and then expecting the editor to pick up it's the object not an Integer.

[kegetys 2]

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.

[bn880 5]

No you don't, not for what I'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't define it, and better yet later change it's type several times?

I can use _x as a float value, then later in the script as an object. How's the editor going to know the difference. That's what I'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's dealing with.

[-AIA- silentwolf 0]

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.