Praise to OFP's script engine!

[KaRRiLLioN 0]

I think the best part about OFP scripting is that it's complex enough to give scripters a very wide latitude in their mission-making decisions, but simple enough for anyone to learn without being a programmer.

Also, functions added some extra depth to the scripting playbook as well since much needed If-Then commands were added.

Debugging exists...although mainly in manual form. If something isn't happening the way I want it, then I debug with hints galore to tell me what ofp is doing with the code.

My main experience is in SQL programming, which bears little resemblance to ofp scripting code, and I'm definitely no expert on C++ etc, but I think OFP's scripting is pretty good, especially considering how long it's been around.

I think the current command set is a good base for OFP2 and hopefully it'll be greatly expanded upon.

[crashdome 3]

Quote[/b] ]If it's all about ease of use, why not precompile the code before execution (like in Perl)?

I think that is why whe have the preprocess ability of functions. Functions are more coder friendly too. There are still issues with functions IMO, but that's probably because it was introduced late in the game.

I agree with you ag_smith on improvements, but that is why there is the OFP2 suggestions forum, right?

[ag_smith 0]

I think I remember Suma (or another OFP guru ) saying that preprocessFile doesn't compile the code, I could be wrong, though.

I agree with you that intoducing functions was a move in the right direction.

BTW. I checked out the Suggestions forum and to my surprise, I've found that all my and many more suggestions are already there.

[hardrock 1]

I think I remember Suma (or another OFP guru ) saying that preprocessFile doesn't compile the code

That's correct. preprocessFile works like loadFile, they both load files into a string variable, which can be executed by the call command. The difference is that preprocessFile is a bit more CPU intensive since it allows you to write C-like comments with // and /* */, also you're able to use #define for variables (and makros?) in functions loaded via preprocessFile.

Another important fact about preprocessFile: For whatever reason it can't be used in addons, means if you include your function in an addon, you won't be able to load it with preprocessFile. Thus, the above mentioned C-like language can't be used in addons.

None of these two functions compiles the code though, which would mean packing it together into a format that could be read and executed more easily and faster by the OS/program (which you could never understand, just look at an .exe in a hex editor ).

[KeyCat 131]

However if youre not making missions using KeyKat's GL2 with snYpir's Support pack youre not making Missions your making Arcade Romp and Stomp Games like AA.   .

@ WW: Glad you like the GL 2 script. Just want to add that Toadlife should have shares of that credit to. It was his original script that got me starting.

Quote[/b] ]

Ok... enough of these rant, I should be thankful for what I got, right?

@ ag_smith: Yea, at least I know I am

/Christer (a.k.a KeyCat)

[Victor_S. 0]

I absolutly hate the error messages it gives you. They are usually something totally different than the problem, but you learn to understand what they mean. The reason I like scripting for ofp is because it is so accessible. because it is not compiled I can sit there with my script and ofp open, change the script, alt-tab in, test, alt-tab out, edit. Yea its primative, but for someone who only knows basic scripting its great.

[sanctuary 19]

I totally agree, OFP scripting is brillant.

What i appreciate the most is that It is very user friendly for people like me that has no programming background (i doubt making programs in BASIC on my MO5 and CPC464 are counting as programming knowledge ) , allowing me to create scripts i need for my missions and having them to work .

And for programming gurus, it seems to allow them a very lot more (just take some look at some ECP scripts and some OFPEC complex ones).

Of course, it can always be better and some more functions added in vbs1 could really make OFP scripters life easier (some hope OFP2 will have even more) instead of forcing them to try to make workarounds.

[iceman316 0]

Quote[/b] ]

OFP has a LARGE share of bugs and errors.

@ iceman316: Do you mind telling us what all those bugs and errors are?

I'm not saying OFP is perfect, again few things are, but current version (1.96) only have a few (minor) bugs still there. If you haven't you should try out OFP 1.00 then you have something to compare against

/Christer (a.k.a KeyCat)

Heh, ive played and modded OFP from the very beginning, ive seen it all.

I can't say iv'e run into a bunch of fatal errors because the only ones there where, BIS fixed in patches. (the yellow screen of doom, MP game creation glitches... both where fixed).

Most of the stuff that i have seen is just goofy bugs and glitches. Like the wrong animation playing when you get into vehicals and the guys head sticks through the roof, just stupid stuff like that.

Aside from that i still stand firm in saying OFP is a nearly perfect modding platform.

[Dreamline 0]

Another example, suppression....

You are so right on with this post, it's not even funny. I

always found it odd that a game most celebrated for its

"realism" has one of the most unrealistic implementations of

infantry combat I've ever played. Now, the simulation of an

individual soldier is very well done (ie: scope drift), and taken

to a level that is just about as far as you can get short of

attempting to implement the physical and psychological

affects that combat has on the mind and body.

I can only imagine how intense and satisfying OFP would be

if the infantry simulation was something similiar to what BIA

has in place; however, with such, you would need sufficient

cover all across the map.

[UNN 0]

Quote[/b] ]Most of the stuff that i have seen is just goofy bugs and glitches.

I can think of two or three major bugs (CTD's that causes you to loose your unsaved mission in the editor) but in the grand scheme of things it's not an issue, as carefull testing can ensure nobody else suffers from the same problem.

As far as the scripting language goes, OFP is a game that comes with it's own programing language and not a programing language that comes with a game. One of the Broadsheets here in the UK hailed BIS as pioneers in making sophistcated modding tools\functionality available to the public, other games can only follow in it's footsteps.

While I'm sure many games companies have similar in-house untils for developing thier own software, they are kept under wraps. So to me, it's better to pay tribute to BIS's forsight and comittment to the gaming community, over anything else.

[ag_smith 0]

I can think of two or three major bugs (CTD's that causes you to loose your unsaved mission in the editor) but in the grand scheme of things it's not an issue, as carefull testing can ensure nobody else suffers from the same problem.

Just a little idea of mine, maybe let's make a list of these bugs with a detailed description of situation in which they take place. This should help people avoid potential hazards and speed up script testing.

[KeyCat 131]

Just a little idea of mine, maybe let's make a list of these bugs with a detailed description of situation in which they take place. This should help people avoid potential hazards and speed up script testing.

Yea, that was what I was thinking when I asked Iceman list the bugs and errors (but I now see he meant OFP itself not the script language).

However, Blanco did list a few. Maybe we could continue to build on that??

/Christer (a.k.a KeyCat)

[UNN 0]

I thought listing bugs in a topic about Praising OFP's script language is kind of off topic. Well if not off topic, certainly diametrically opposed

But the two that sprung to mind both relate to getting in and out of vehicles.

I added this to the init parameter for CreateUnit, which appeared to cause a CTD:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">This action ["getin gunner",Vehicle01]

In the end I had to call a script that just contained the above line. Now I could have used MoveInGunner, but that would not trigger the getin event (which I guess could be another bug?). But to be fair the "GetIn Gunner" action is not in the offical reference.

The second is the GetOut event:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Vehicle01 AddEventHandler ["GetOut",{DeleteVehicle (_This Select 2)}]

I think the GetOut events returns the unit before it disembarks, so deleteing it causes a CTD. Again you have to call it via a script. Never did test to see if the same happens with GetIn.

Ohh and the old error about outputting strings greater than 256 characters with the format command, also causes a CTD.

A minor bug, using SetPos to remove a unit from a vehicle, seems to disable the units AI, it wont move or follow orders. Even if you use UnAssignVehicle.

[Blanco 0]

Most things are brilliant, some things were forgotten...

Like an undo button

I still remember my early days in the editor, I was so happy when I found the usage of the cycle waypoint and the switch trigger 

Quote[/b] ]Just a little idea of mine, maybe let's make a list of these bugs with a detailed description of situation in which they take place. This should help people avoid potential hazards and speed up script testing

That's a great idea (was also mine), i just ran in such a hazard when my mission was 90% completed. My mission had lots of scripted waypoints, then I realised the status was not saved...