Jump to content
Sign in to follow this  
Guest

Scripting

Recommended Posts

getpos [TheUnit,{TheMemoryLodPoint}]

Share this post


Link to post
Share on other sites
getpos [TheUnit,{TheMemoryLodPoint}]

yes! 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/2like<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 biggrin_o.gif

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!). that would save much scripting work.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.. tounge_o.gif

So why should anyone take the time to read what you say?

Read the thread.

Share this post


Link to post
Share on other sites

RETURN VALUES

I would suggest that most scripting commands be revised to make sure they return something like 'null' 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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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's point.

While I'm here, apart for bringing OFP'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.

Share this post


Link to post
Share on other sites

<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

(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(_blah.class.property, values, misc)

could create:

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

get(player.position.x)

set(player.position.x)

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

Cargo.index.contents

(or driver, gunner, commander, crew, pilot, etc; each of those would be indexable as well, for multi-gunner, -pilot, etc crews...)

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'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(?)

code line

error

values given

values expected

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(unit.position.relational)

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

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

For "disableAI" commands we need "EnableAI" commands !

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.

!!!

Greetz

Chaos crazy_o.gif

Share this post


Link to post
Share on other sites

OK I'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. 'DISCONNECTED' 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'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 'disconnected' 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.

smile_o.gif

Share this post


Link to post
Share on other sites

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 'action' 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'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 'color' value that would return upon 'pointing' 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  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 'RPG' elements of the game could have some alternate interactions besides the object-based.

Whaddya think?   band.gif

Share this post


Link to post
Share on other sites
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 ---> ie

Yeah, I'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 <Pointer>

GetPointer Car01

<Pointer> could be anything from another object, an array or another pointer.

Line of sight function for combinations of objects, and\or XYZ positions?

Cheers

Share this post


Link to post
Share on other sites
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. 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'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 'goto' 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

? !condition : goto "blah"

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 'goto' 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'd like to see, if it hasn'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'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't sure if it was currently 0 or not. With SC, you could just do this:

_num = [0,2] select random 1

? _num != 0 && 30 / _num <= 15 : ....

Okay, bad example, but you get the drift.

Share this post


Link to post
Share on other sites
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 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="My OFP Addon";

..............

};

#EndIf

#IfDef V2

Class AAV2SPECIFCADDON

{

DisplayName="My Armed Assualt Addon";

..............

};

#EndIf

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="External addons for OFPV191SPECIFCADDON";

........

};

#EndIf

Cheers

Share this post


Link to post
Share on other sites
getTarget "guy1"

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

That is ALL that I ask, oh god PLEAAAAASE include a getTarget command. Pleeeeaaase!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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's all for now... whistle.gif

Share this post


Link to post
Share on other sites

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

A script command to return texture\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

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×