Max # of scripts in a mission

[Mike]

What is the max? and if there is no Max then what is recommended..

[Dinger]

Tons of scripts can run.
How many are recommended?
As few as humanly possible.

[CareyBear]

And if ur usin loops - esp if they are gonna iterate through a very large number of items - make sure there is a slight delay (~0.01 to ~0.05 is enuf) so that they don't chunk up the game. Just think about how soon u need the answer, not how soon u can get it.

be nice script.. share.. no! bad script! bad! Down boy..

[toadlife]

If you have tons of scripts going at once with loops, and especially if you have the same script running multiple times, I would recommend putting a random wait time at the begining of the scripts. This helps to more evenly distribute the computer's CPU cycles betwen the various scripts.

Instead of this:

#loop
do something
~0.1
goto "loop"


Do this:

~(random 2)
#loop
do something
~0.1
goto "loop"

[Mike]

I have 300+ but most aren't looped not getting lag, but I was just worried that too much would make it all go to the crapper.. how about max # of triggers? I've had over 63 and things worked.. I figure theres probably either no limit or its a high limit.. I couldnt have more than 63 gamelogics

[toadlife]

Triggers are just pre made scripts, so the group limit had nothig to do with them.  300+ scripts and 60 triggers is alot. That would probably bog down lower end CPU's (500-1000mhz).

[CareyBear]

Ok. I gotta ask.

What are you using 300 scripts for?

* CareyBear has thought and thought and can't tink of anything that u need 300 scripts to do.

hmm.. can u group gamelogics? Or does each have to be on it's own? If u can group 'em u can have 700+

also, triggers will eat varying amounts of cpu dependin on the size and type of trigger. If u start playin around with the thislist of a map-size trigger, esp passin it to scripts.. things can get jumpy with just the one.

[toadlife]

Yes you can group gamelogics, which gives you the ability to add hundreds and hundreds. I feel that this too would lag the mission anyway, as the players (or players) still have to know where all of these gamelogics are. A gamelogic is still an object, and the more objects, the more lag

A tip for trigger. Careybear is right when he says just one trigger can cause lag. If you are using a trigger, for which the only function is to wait for a variable to come true and execute some code, consider using a script with the @command instead. The reason is:

A) Regardless of how little they do, triggers allways take up more CPU resources, and time than an equivalent script.

B) Triggers will take up more space on your hard drive than a script.

If you have to use a trigger, that only waits for a variable and then executes something (displaying briefings in MP for example), then make sure the trigger's size is 0x0. The reason is that if you leave it the default 50x50, I think the trigger still has to calculate who is in it's radius, even if it doesn't matter. (I'm not 100% sure about that one)

And one last thing...

What ever do you need 300+ scripts for!!!  

[Chris Death]

OK, that question, what causes less or more lag:

triggers or scripts ?

Was that kind of interesting - many different opinions, and
even all of them (wether pro trigger or pro scripts) was
based on logical reasons.

Therefore, as i found a thread at the official BIS forum,
which was close to this, i also asked, what's causing really
less lag then.

Fortunately, Suma must have got some time left, and he
quickly replied to the questions in there.

For those of you, who don't know who Suma is:

Suma = Ondrej Spanel = BIS Lead Programmer
So you can trust this man, he knows something about
mission editing in OFP.  

Here's the link to the thread on BIS forum:

http://www.flashpoint1985.com/cgi-bin/ikonboard301/ikonboard.cgi?s=3da749956048ffff;act=ST;f=7;t=20961

And here's the link to the thread on OFPEC forum (which i
started, once Suma answered):

http://www.ofpec.com/yabbse/index.php?board=6;action=display;threadid=2491


You should take the time to read that (i've started the thread
here close before it became weekend, and i suppose therefore
not as many ppl could read that).

hope this clears up

~S~ CD

[Chris Death]

If you have to use a trigger, that only waits for a variable and then executes something (displaying briefings in MP for example), then make sure the trigger's size is 0x0. The reason is that if you leave it the default 50x50, I think the trigger still has to calculate who is in it's radius, even if it doesn't matter. (I'm not 100% sure about that one)

Toadlife, i can also only do a speculation on this, but i think
it depends on the condition, wether the trigger is checking
an area or not.

e.g: If you create a trigger with size: 50/50, activated by
west/present
condition: this
or condition: this AND (anything else)
You can always access the trigger's list by using the option:

list triggername

If you use exactly the same trigger without a "this" in the
condition field, you can't access the trigger's list anymore.
I've been working with such triggers lately, so i can ensure
this result for sure.

This result makes me think, that the trigger area will not be
checked, if the condition is not requiring to check it (true,
anything (not alive), "_x blabla" count (units groupx), etc.).

Hope this makes sense to someone else too  

~S~ CD

[toadlife]

Well that just mucks up my theory now doesn't it!  

I'm one of the 'pro script' people. They have much more flexibility, they take up less space, and for me, they are easier to edit and test.

[Chris Death]

hehe - i expected something like that toadlife

As you probably noticed, i'm that gamelogic + triggers freak,
but i'm also in the meaning, that for more complex stuff,
the script is the better solution.

 ;D  

~S~ CD

[Tactician]

I've fallen into the habit of using triggers for everything I don't have to use scripts for.  I don't trust a script to sit around and wait for @condition to be met.. maybe I'm just traditionalist, but all my scripts are activated by triggers and other scripts.  Haven't had any trouble with triggers though.  File sizes still small, flag systems work fine.

A good point of scripts is that they're easier to distribute than triggers, if you're into the sharing thing ;d

[toadlife]

I don't trust a script to sit around and wait for @condition to be met

LOL! Trust me they are just as reliable as triggers!  Everyone has their own preference though.    

[dreaming_adam]

All of you prolly know this already, the only difference between a trigger (inserted in the mission editor) and the @ command (used in scripting) is that a trigger runs through a predefined list of subroutines where as in scripting an @ will only contains the code required for the conditional switch.

This means that an @ trigger is a lot more efficient than an ingame trigger (efficient in the sense of less processor intensive).

This however is dependant on the count of triggers that you have. In scripting the @ pauses execution of the script until the condition is met, where as a trigger executes a function when a trigger is met. That is, @ is sequential programming, triggers are simultaneous. In order for you to use multiple conditional switches simultaneously in scripting requires that you have multiple scripts running. THIS causes lag (even if it is just multiple copies of the same script running).

To put all the above in simple terms - If you plan to have just one or two triggers, OR you want to pause a script mid execution until a condition is met, use "@"

If you want to have many triggers that can all be activated at once, use in-mission-triggers.

-Adam

BTW there are exceptions to the above rules and you will just have to experiment. Even so, I doubt many of us will get much of a performance boost choosing the correct conditional switches anyways.

(This information may not be totally factual, it all comes down to the way that BIS programmed flashpoint. If their coding is logical opposed to shabby, the above statements will be correct)

[Chris Death]

(This information may not be totally factual, it all comes down to the way that BIS programmed flashpoint. If their coding is logical opposed to shabby, the above statements will be correct)

errm dreaming_adam,

a few posts above, i've posted 2 links, where the first link
leads to the official BIS forum. If you click on the link, you
will find yourself in a thread, where the BIS lead programmer
already gave an answer on that.


However, since not that lot of ppl, than i thought, are following links, i'll copy/paste something into here.
But if you want to know the whole story, you still have
to click on the first link of my first reply to this thread above.

my question:

Code: [Select]

If there really would get someone to read this thread
(i mean someone who knows ) could we maybe also
get compared, what eats more cpu power:?

Triggers (e.g: waiting for boolean, numeric variable, unit-status, syncronized with anything, checking an area,
placeholder triggers (to use their trigger_list by trigger-name,
etc.)

to

@conditions_in_scripts

AND

#loops
in_scripts
~000001
goto "loops"

 

I've neaver seen written black on white, that script conditions/loops are faster/slower than triggers,
only rumours, and even those move into different
directions. Some say trigger's, others are saying scripts
are faster.

Suma sayz:

Code: [Select]

Quote (DV Chris Death @ Oct. 11 2002,20:17)
Triggers (e.g: waiting for boolean, numeric variable, unit-status, syncronized with anything, checking an area,
placeholder triggers (to use their trigger_list by trigger-name,
etc.)

to

@conditions_in_scripts

Trigger are evaluated approximatelly twice per second, therefore they are less CPU intensive than script conditions. Trigger with condition condition used almost the same CPU power as script

~0.5
@condition

Triggers associated with area may require more a little bit more CPU power, as vehicles need to be checked to see if they are entering/leaving the are. The perfomance hit should not be significant though. If you want to know exact numbers, some measurements would be necessary.


Code: [Select]

Quote (DV Chris Death @ Oct. 11 2002,20:17)
@conditions_in_scripts

AND

#loops
in_scripts
~0.00001  // <- quote fixed added decimal point
goto "loops"

Those two are almost identical. ~0.0001 will get executed once per frame (unless your fps is higher than 10000).

~S~ CD

[Ranger]

e.g: If you create a trigger with size: 50/50, activated by
west/present
condition: this
or condition: this AND (anything else)
You can always access the trigger's list by using the option:

list triggername

If you use exactly the same trigger without a "this" in the
condition field, you can't access the trigger's list anymore.
I've been working with such triggers lately, so i can ensure
this result for sure.

This result makes me think, that the trigger area will not be
checked, if the condition is not requiring to check it (true,
anything (not alive), "_x blabla" count (units groupx), etc.).

Hope this makes sense to someone else too  

~S~ CD

Hmm, I"m not 100% sure I believe that.  I have a mission where I have a trigger that checks for the presence of East within a 200m radius.  In the condition field, I have the following code:

count list trigger1 < 2

The idea is that if there are less than 2 East soldiers remaining in the area, the trigger activates.  I do not have this in the condition field, but yet the trigger seems to work properly.

Admittedly, I haven't gone around counting every last body to make sure there really were less than 2 East soldiers left, but it works as far as I can tell.

I'll have to go double check my code to make sure that I indeed don't have this in there, but I'm pretty sure I don't.

[toadlife]

"count list trigger1 < 2" is the same type of thing as putting "this", therefore, the question still remains: Does the trigger access it's list only when it is queried, or is it's list maintained regardless of the condition?

A test might be to create a tigger and set it to "west present", and set it's condition to "false".

Put a west unit in the triiger and then create another trigger that lists the first trigger.

But then, that still wouldn't really answer the question. The second trigger querying the first and getting an answer wouldnt neccessarily mean that the list is being maintained/updated at all times by the first trigger, just that the list is allways accessable regarless of the trigger's condition.

[Chris Death]

  - OK, my fault on this one here

I've been checking this again, and figured out, i've
done it in a bit different way, than i wrote above.

When i made my e.g: west/present trigger, i've created
2 arrays from the activation field of this trigger. And when
i was disabling the trigger's condition, instead of using
"this", the two arrays did never exist. So my other triggers
in this tist couldn't work.

I've been testing that again now:

west/present
name: triggerA

condition: false    : i've also tried some other conditions,
just to make sure

and a radio-alpha trigger, displaying me the list of triggerA

Whatever the condition was, the list was displayed.
So sorry for the wrong info above - me couldn't remember
correctly in that case  

I've tried moving units in and out the trigger area, and it seems that the trigger list also gets updated every time
it should.

~S~ CD

[Ranger]

"count list trigger1 < 2" is the same type of thing as putting "this", therefore, the question still remains: Does the trigger access it's list only when it is queried, or is it's list maintained regardless of the condition?

Those are not the same thing.

"count list trigger1 < 2" checks to see if there is 0 or 1 East unit in the area.

When using "this", I had the trigger checking if East units were not present (despite what my previous message said).  Thus, it would not activate until there were 0 East units remaining in the area.

They are very different in their uses.  I used "count list trigger1 < 2" for my trigger since what often happened was the last East unit would hide in some bushes somewhere and wait there until the end of time.  Since my mission did not continue until all east units were cleared, it would always take 20 to 30 minutes just to clear out one town.

Thus, by using the "count list trigger1 < 2" condition, if that last guy was indeed hiding out in the bushes where no player could reasonably find him, then the condition would be met anyway and the mission could go on.

[toadlife]

What I meant is, that they are the same type of thing - they both are conditions which depend on the trigger's contents.

[Ranger]

What I meant is, that they are the same type of thing - they both are conditions which depend on the trigger's contents.

Oops.  That's what happens when I don't read too carefully.  

Anyway, as Chris Death clarified, the list is constantly updated even if you don't use this in the condition field.  At least, that's what I think he's saying.

It must be, otherwise my trigger wouldn't work.

[Chris Death]

Yeah, that's right, i've also tried that with conditions,
which had really nothing to do with the trigger, and
the list still was updated everytime.

~S~ CD