Good editing practices

[jaenak 0]

The other day I was finally told that the game slows down if scripts are too complicated for the computer to read and calculate. I can understand that, I've just never really thought about it because my computer hasn't ever bogged down with OFP unless I was messing with my video settings.

So all that got me to thinking. What are the best practices a mission designer can incorporate so as not only to create missions, but create them in a manner most friendly to the CPU. I know one is to create scripts that are short, and potent. Ideally, have all your scripts have their note in a separate Notepad or Wordpad file, and avoids the "list" function, use short variable and label names, use if/then statments instead of "goto" and use the ~2 or ~.5 idea whenever possible. I got all that from the Mission Editing FAQ. All that might not be possible in every given instance, but I'm simply speaking of ideal editing practices whether or not they may be practical. Any other ideas?

[RED 0]

Try to avoid using @ to wait for conditions.

RED

[crashdome 3]

I'm sure bn880, Dinger, or Denoir (from CoC) could post a thing or two!

I usually follow these rules:

1) Keep it Simple - Start with few features and add as NEEDED.

2) When working with loops - one is better than ten obviously. (Can you do more than one thing in a single loop?)

3) Find were there are alot of calculations and see if you can reduce the amount of information or calculations performed by approaching from different angle.

4) If it requires alot of work to perform something simple or minor it is probably not done correctly or not worth doing.

and 5) SIZE MATTERS with everything. Smaller Variable Names to Smaller Script Sizes mean a world of difference. (bn880 taught me this one)

Another Note: Instead of looping, use events. It is better to trigger something either from another script or event than to use a loop to "listen" or "wait" for something to happen (e.g. use waypoints, eventhandlers, or one single "listen" loop.)

[jaenak 0]

As I intended this thread to be about creating missions in general as well as scripts I just thought of something. Is it better to use the init fields for stuff or to put things into scripting files regardless of sizes?

*And, try to reduce the amount of triggers and waypoints you use. The smaller amount of anything the CPU has to calculate, the better.

I caught myself abusing the triggers the other day when I could have just combined them into two different triggers for the same event.

[tracy_t 0]

Wouldn't this information be better going into the FAQ?

The FAQ appears to be a "sticky" thread, whereas this is not.

[jaenak 0]

If someone else wants this in the FAQ, then that's fine. I simply want it for my own knowledge. Maybe after this thread has seen it's better days I'll post all the info into one post in the FAQ but not now.

[TheMcDeth 0]

Also you might want to think is it always necessery to run all scripts locally or should they be run only on server. Using publicvariable broadcasts things to all clients so it is not necessery always to run scripts everywhere. Also you can set the wait for loops even higher than 0.5 - 2. I use ~10 quite commonly for things that are not very urgent.

One thing that I have been wondering about is that should sometimes scripts be used instead of triggers. For example if you want to check if certain targets are destroyed or not, you could do this in a server side script with for example~10 wait easily. Or you can do this in a trigger. Which one is more CPU friendly?

Also does it make more sense to run many things in one script or should one try to accomplish as many things as possible in one script. Combining multiple scripts into one makes them more difficult to make reusable in other missions.

[m21man 0]

I think using "killed" eventhandlers is a very good idea, at least in SP editing.

[bn880 5]

One thing that I have been wondering about is that should sometimes scripts be used instead of triggers. For example if you want to check if certain targets are destroyed or not, you could do this in a server side script with for example~10 wait easily. Or you can do this in a trigger. Which one is more CPU friendly?

In general using a script to check for some destroyed vehicles is a lot less CPU intensive than having a trigger do that on (basically) every game cycle. That is if you do that ~10 of course.

Quote[/b] ]

Also does it make more sense to run many things in one script or should one try to accomplish as many things as possible in one script. Combining multiple scripts into one makes them more difficult to make reusable in other missions.

Usually running one script versus many is easier on the CPU, however not when you are doing polling and then having un necessairly many conditions polled. And if you have to do long Goto's that's not good either. So if you need something polled at 1 second, and something else at 10, write 2 scripts. Also if you keep your scripts seperate you can shorten all text to the max and still understand it, with one giant script you need to keep everything very long....

[iNeo 0]

How exactly do you make a script run on all clients, and how do you make a script run only on the server and then broadcast to all clients?

[bn880 5]

Various ways to run a script everywhere. Basic idea is the script will run where it is started, that can be init.sqs of a mission, init event handlers of addons, init field of addon, fired EH of addon, sometimes Fuel EH, etc. Triggers can start scripts everywhere but it is unlikely they will start them at exactly the same time, and it is not reliable depending on trigger distance to local player.

There are probably various other ways to start scripts everywhere that I can't remember at the moment. To run the script only on the server, basically you should place an object or gameLogic that you _know_ becomes local _only_ to the server, you give that a name like "CoC_Server" and in your scripts you can insert a line that exits on non-server nodes: ?!local CoC_Server:exit

That's basically it, the inverse would be to run the script on clients only by doing: ?local CoC_Server:exit

If your scipts by default start only on a local node and you want them started everywhere from some event, one of the solutions is to use the CoC Network Services, or write a bunch of custom polling on a PublicVariable.

Hmm hope that helps a bit.

[Junker 0]

I used to build missions on my 800 and when that started to slow down i knew it was time to delete a few units and finish it, This way i could calculate the lag factor on the server and other peeps computers.

The best thing i got the other day was the Spawnmanager2 script very handy to have.

REMEMBER: its not about the number but about where you place the enemy units, And the terrain around them.

mission makers should TEST TEST TEST TEST

[MachoMan 0]

Also use scriptz too spawn units when and where they are needed, instead of using the editor to place units everywhere the player could go

[Taurus 20]

Ah testing yes.

Three weeks down the drain!

Nothing works the same way in "singel MP" and "Real mp"

F**ck it!!

[dinger 1]

testing yes -- a hell of a lot.

Use as few scripts and effects as possible.

I disagree with the "on demand" spawning. Units that aren't doing anything (AI is not engaged) take up very little processor time. Ones that are in proximity to enemies eat a ton.

Use as few addons as possible.

With addons that have effects, turn all but the essential ones off.

[igor drukov 0]

Hey !

Quote[/b] ]REMEMBER: its not about the number but about where you place the enemy units, And the terrain around them.

Could you be more specific ? What is it exactly that you mean by "terrain around them" ?

Ig.

Edit : typo

[Rastavovich 0]

One good think in scripts is aswell if you try to avoid sin/cos functions.

Another issue I often see is the declaring of an variable and then the variable is a static value.

I also have seen quite a lot that ppl call a script [_this select 0] ....

and have then to use inside the script.

_x = _this select 0

instead of using

(_this select 0) ...

and then working inside the script with

_this

as the passed variable/object.

Those are all small issues, but especially the sin/cos stuff can ruin your fps when used wrong.

You should suspend/exit scripts as often as it is possible without it will affect something.

ie: You have a duster script. Over a certain height you could simply use ~5 or so to suspend it (for greater heights even greater values are possible), since those scripts tend to have quite some checks in it.

[bn880 5]

I also have seen quite a lot that ppl call a script [_this select 0] ....

and have then to use inside the script.

_x = _this select 0

instead of using

(_this select 0) ...

and then working inside the script with

_this

as the passed variable/object.

Those are all small issues, but especially the sin/cos stuff can ruin your fps when used wrong.

Two issues with this, it is good practice to send everything to any function in an array, even a single variable. The reason is, if you screw up sending something in an array you will see some errors and will eb able to perort from the script with the problem. On the other hand, if you screw up sending witohut an array, the script dies before it starts. No debug possible. (you can literally get lost for ever on a large system with this)

Second: save your passed variable to _x or _y whatever by using _x=_this select n; if you access _this select n more than once. This is more efficient in OFP scripting due to realtime parsing of '_this select 0' versus '_x'.

[dinger 1]

heh rasta, you can have my trig functions when you pry them from my cold, dead hard drive.

But yeah, suspend whenever possible. avoid polling scripts.

[Rastavovich 0]

Quote[/b] ]Two issues with this, it is good practice to send everything to any function in an array, even a single variable.  The reason is, if you screw up sending something in an array you will see some errors and will eb able to perort from the script with the problem.  On the other hand, if you screw up sending witohut an array, the script dies before it starts.  No debug possible. (you can literally get lost for ever on a large system with this)

Second:  save your passed variable to _x or _y whatever by using _x=_this select n; if you access _this select n more than once.  This is more efficient in OFP scripting due to realtime parsing of '_this select 0' versus '_x'.

Your 2nd strongly depends on your first issue. If you pass only one variable (without array) the access for the game engine is as fast as if it would have to look into a placeholder.

But you are right creating placeholders when the variable is stored in an array and you have to access them more then once makes sense.

To your first point. You might be right there aswell, but I still prefere the only variable thing for myself and have no problems debugging it. But since you do the more complex programming you should have the better experience with it, so people (especially code newbies) should probably use your method.

PS: Thnx Dinger, I have allready enough pc trash here. BTW, what trigger functions are you talking about.

[dinger 1]

trigonometric functions. sin and cos. it's a joke man.

[Rastavovich 0]

When it comes to OFP scripting I don't like jokes ;)

[terox 316]

Something i learnt very recently

Good practice, with the never ending addition of mods like ECP, or addons, is to have a prefix for all your global variables, so that they dont conflict with addon or mod scripts running alongside your mission scripts

eg

instead of using

<span style='color:blue'>counter = 1</span>

use

<span style='color:blue'>TX_counter = 1</span>

or some such meaningful prefix

and have all other global variables carry the same prefix

This is something i will be implementing into all new templates and maps i will be building from now on

**********************************************

1) Dont have any commented lines in script loops

2) Dont have a script run too many commands in one run before a delay

3) Keep variable names at a minimum length

4) Run as much local client as possible, and as few Public variables as you can

5) If an object does not serve a purpose on a map, then dont add it unnecessarily for cosmetic appeal. Folks dont really give a monkeys about it

6) If you are running say 5 C&H Flag scripts, that are all identical, then have them stagger their initiation, so that they dont run in a synchronised manner (eg have script A wait ~0.5 on first line, next script wait 1.2, next 1.7 etc etc

7) Run a short intro to give the server and clients time to settle down and synchronise after initial load

8) If you have finished using a global variable, then "Nil" it to get it out of mem and re declare it later

eg

TX_Counter = nil

**********************************************

Triggers v scripts

I found a massive efficiency difference when removing all the triggers used in CTF's and replacing them with scripts, or rather one script that does the lot

On the downside i believe triggers synchronise between clients, is this true

Keep the

<span style='color:blue'>~X</span>, no shorter than 0.5 and preferably 1 or a value higher

Loop timings

Dont know in what order these run at, eg fastest to slowest

Some clarification would be nice

<span style='color:blue'>Triggers</span>, loops to check if condition is true at what rate???

<span style='color:blue'>@</span>, loops to check if condition is true at what rate

<span style='color:blue'>~</span>, loops at what rate

I would imagine

@ loops the fastest

then triggers

then any wait period

**********************************************

Some of this stuff may be incorrect, but unless somebody corrects me, then i will continue to practice these things

[toadlife 3]

Regarding triggers vs. loops vs. @, here is a good thread to have a look at.

[bn880 5]

Quote[/b] ]Two issues with this, it is good practice to send everything to any function in an array, even a single variable.  The reason is, if you screw up sending something in an array you will see some errors and will eb able to perort from the script with the problem.  On the other hand, if you screw up sending witohut an array, the script dies before it starts.  No debug possible. (you can literally get lost for ever on a large system with this)

Second:  save your passed variable to _x or _y whatever by using _x=_this select n; if you access _this select n more than once.  This is more efficient in OFP scripting due to realtime parsing of '_this select 0' versus '_x'.

Your 2nd strongly depends on your first issue. If you pass only one variable (without array) the access for the game engine is as fast as if it would have to look into a placeholder.

But you are right creating placeholders when the variable is stored in an array and you have to access them more then once makes sense.

To your first point. You might be right there aswell, but I still prefere the only variable thing for myself and have no problems debugging it. But since you do the more complex programming you should have the better experience with it, so people (especially code newbies) should probably use your method.

PS: Thnx Dinger, I have allready enough pc trash here. BTW, what trigger functions are you talking about.

Not really the point I am making... the number of characters is what kills you the most, and number of seperate tokens to be processed. Not that it's a reference VS operation.

Second point: No you are incorrect in my opinion, any scripter can lose a lot of time using non array passing if the system is complex enough, for example the Net services from CoC. Or if you make utility functions, you _never_ want to leave someone with a function that won't even drop a syntax error, how will you debug it when someone jsut tells you in their large MP session your script didn't run, sometimes, but only with 12 people on. I think you underestimate the problems that can occur. Sticking to good scripting practices is usually more important than a slight cometic appeal, or slight CPU usage reduction. (usually)