OFPEC Forum
Editors Depot - Mission Editing and Scripting => OFP - Editing/Scripting General => Topic started by: THobson on 05 Jul 2005, 21:20:49
-
I have made several changes to my mission based on the asumption that once I have used a trigger a
deleteVehicle triggername
will completely remove the trigger and there will be no residual load on the processor. Does anyone know if this is the case ot not?
Similar queston on objects. If an object is in the editor with condition of presense set to false, I assume it does not exist as far as the game is concerned and so does not contribute to lag.
-
I would say both things are a safe bet, but I have no way of being 100% certain.
-
I have no idea about the first question. An easy way to test it yourself would be to make a trigger, activation "anybody present", on activation "hint {trigger is here!}". Set it somewhere that you have to walk to get to.
Then, in your init.sqs or elsewhere, delete the trigger (after a few seconds delay). Run the mission, wait for the trigger to (supposedly) be deleted, and then walk into its area of effect. If you get a hint, then you know the trigger can't really be deleted.
I would bet my firstborn's soul that you are correct on the second question. I don't see how the game could keep track of an object if it never created it... unless it creates the object, and then hides it? :P
-
General Barron;
Sorry if I was not clear. I do know that a deleted trigger will cease to work. I have done this a lot in my mission, when a trigger is no longer needed I delete it in an attempt to cut down on CPU load. I checked this works by making them repeating triggers and in deed after deletion they do not fire.
I am suffering some lag and am looking for a cause. It is a long shot but I was wondering if a trigger that is deleted still contributes to cpu load. I have strong suspicions that a fire once trigger does continue to require the cpu after it has fired (my data for this is the fact that thislist for the trigger will continue to be updated after a fire once trigger has fired).
-
Maybe this has something to do with the thislist array getting updated:
Array assignment
Assignment used on arrays assigns only pointer to the same array to the target variable. When b is an array, after executing a = b both a and b represent the same array. When b is changed, a is changed as well. One particular situation that can lead to this behaviour is aList = list sensor_name. You can force creating a copy of array by using unary operator +Array
Try using something like testArray=+thisList and see whether the thislist array gets updated after the trigger is fired/gone...
Well, this actually probably has nothing to do with the case at hand... :tomato:
(which G. Barron/UNN will soon point out ;D )
I would bet my firstborn's soul that you are correct on the second question. I don't see how the game could keep track of an object if it never created it... unless it creates the object, and then hides it?
I concur...
Although I think OFP doesn't hide the object, it deletes it :beat:
Anyway, I'm pretty sure the type of object also has it's impact in this scenario since if it's some object that has many animations etc. OFP has load those anims (and probbaly even pre-render something else??) and I really doubt that OFP then 'flushes' the unneeded anims out once it has noticed that "oops, prob. of presence was that, me better delete this object"...
-
Interesting. I am trying to slim down a mission, but having spent ages putting things in place I am lothe to delete them, in case I later chage my mind. So I am setting their condition of presence = false, but it may be that some animations etc are not being removed. I can see the logic there.
Bye the way
Well, this actually probably has nothing to do with the case at hand...
You are correct. :)
The fact that thislist is being updated implies that the condition in even a fire once trigger is still being actioned long after the trigger has fired. Hence my tactic to delete triggers once used.
-
i think it gets rid of it as in one of my missions when i delete a teigger wich is syqronised to some tanks when the trigers deleted the tanks go on to their next waypoint so im guessing yes
-
I assume this is for your Abandoned Armies mission, which is going to stress the cpu no matter what you do (since it has so damn many units doing stuff at one time). This might be getting off the topic at hand, but it is about reducing CPU load, so here goes:
One suggestion would be to get rid of triggers ENTIRELY. The only triggers you MUST use are ones that update an array of units, and radio triggers. EVERYTHING else can be simulated via scripting, with a large delay loop.
Another suggestion has to do with scripting commands. Always try to get by with whatever the least-CPU heavy command you can use is. A common one for me is the "distance" command, which I tend to need a lot. It is pretty CPU heavy, since it works in 3D. If you only need to find the 2D distance between 2 units/locations, then just calculate it via trig. Better yet, if you don't need to find the actual distance, and only need to make > < comparisons, then don't square root. I use this function extensively:
GENB_distancePosSqr = {(((_this select 0) select 0)-((_this select 1) select 0))^2 + (((_this select 0) select 1)-((_this select 1) select 1))^2}
Just some stuff that the ECP has run into in trying to reduce lag.
-
In deed it is Abandoned Armies. There are a lot of units, probably around 650 loons in total (it is random each time), but nowhere near the 63 groups per side. I need to spend time cutting down on CPU load and I am looking to where I am likely to get the biggest bang for the buck. I was originally very careful about triggers, only using them where I needed some thing to hapen that was either time or spacially critical. Recently I have added quite a few thinking 'its okay they will be deleted soon' I then had a worry that maybe they still drain the cpu. I guess I am jumping at shadows.
Good tip on the distance command, thanks.
I have tried to get a feel for what causes lag. As a test I had an empty Malden on which I put 5,000 BMPs each running the smoke script I use.
That is 5,000 @ getDammage _veh > 0.98 commands all running at the same time. Providing I could not see the BMPs there was no discernable lag. If I could see them then the lag was deadly
Replacing the @ command with a loop also generated a lot of lag even when they were not visible.
I keep reading that static units create lag. I tried to create lag by placing alot of the white wooden fences on the map. I gave up at 30,000. I just couldn't create any lag - mind you I couldn't put them close enough together that I could see that many of them either.
The lesson for me from all this is that I could spend a lot of time making changes that do nothing.
Multiple mobile units in the same viscinity, even if they are dead seem to cause some problems.
I'm rammbling now so I'll stop.
-
I keep reading that static units create lag.
This is a crock. Static objects have about the smallest effect on lag possible, as you have seen from your experiments.
Islands have thousands and thousands of static objects placed on them, and they don't usually "lag". OFP was designed to handle $%#-loads of static objects like that. Otherwise we wouldn't make missions on huge islands, when we normally don't use 1/5th of the island for any one mission (since all the other static objects on the map would "cause lag", so for efficiency islands would be much smaller).
The biggest lag causers are just plain units I think. They seem like they would take the most CPU power to keep track of, since they have AI and can do more than any other object. Once bullets and explosives start flying, those have a huge effect on lag as well, if there is a sizeable amount at one time.
Here's an idea I just had: try disabling the AI on some or all of the units. Maybe then OFP won't run ~650 AI routines, which might considerably reduce CPU load. Use this command:
unit disableAI "target"
That will disable their combat movement AI (such as flanking). The change might not be noticable to the player. In fact, the AI usually isn't that noticable since they can't see past their noses. :P
-
>since all the other static objects on the map would "cause lag", so for efficiency islands would be much smaller
Voila. Says it all.
Do you think this applies also to camCreated static objects? Certainly should do.
>explosions and movement.
there's the issue imho (with a very large H). Folklore says that choppers are the worst offenders and this would certainly make sense. Explosions would be the largest movement lag of all.
-
Multiple mobile units in the same viscinity, even if they are dead seem to cause some problems.
Dead units are turned into static objects after a minute or so. So I doubt they would contribute any more to lag than any other static object. I bet you didn't wait long enough in your tests for them to be turned static.
Do you think this applies also to camCreated static objects? Certainly should do.
I would assume so. Actually, I think ANY object that is camCreated is "static". Try camcreating a soldier--all you get is an empty shell that can't "do" anything.
-
This is getting helpful. Thank you.
I have also read that the number of groups is more significant than the number of units - so 10 individual loons each in their own group will cause more lag than 10 units in a single group. I have not tested this, but in my mission I have kept group count down and loon count up where I can.
Dead mobile units becoming static after a while would explain why lag diminishes in and around the battle field over time.
There is something though I feel about the visual representation of placed static objects vs those already on the island.
How about Event Handlers?
All my west loons have killed EH that says - was I killed by resistance if so set a flag, was I killed by east if so set a different flag . Similarly for all the east loons. I use one EH for each of these test - not knowing any better at the time. Now I do know better I could do both test in one EH. Only three kills are relevant in the mission. The first east killed by resistance, the first west killed by resistance and the first kill of east v west (it is the same flag). In fact this flag over rides the other two. I had contemplated taking out all these EHs once they were not needed, but haven't yet.
Any thoughts would be great appreciated?
-
EventHandlers are not loops.
I don't believe they cause any lag themselves...
Well, they might some sort of loops on some level if you wanna be pedantic and go insanely deep into C++ coding (or whatever OFP is written with) ::)
-
That was my logic too. But when a battle is going on these EHs are firing for each loon killed, mostly unnecessarily, so with all the bullets flying, explosions happening as well it might be area to cut down on the load.
-
Up to 650 loons active when the mission is running? You, Sir, need bn880's excellent "AI on demand" system. ;D
This lets you put groups that are currently not involved (ie near the player) in "stasis". That way, they are removed from the game world until they're needed again. They are brought back based on conditions chosen by you. It can be as simple as a boolean variable determining their reentry or a more complicated conditional expression.
A common example of the latter is having AI groups be brought back to life as the player gets closer than a set threshold distance from one of their waypoints.
bn880's "poster child" mission for this system is the multiplayer "Bastige Island", presented here: The Bastige Island 6 (http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=6a174d43af742c682ea2b1e249aad6ba;act=ST;f=55;t=39977).
The latest (of this writing) source AIOD scripts are available here: CoC AIOD rev. 36 (http://s92713009.onlinehome.us/OFP/CoC_ADrev36.zip)
NB: Once brought back, the AIOD-governed groups are there for the duration of the mission. The system can't bring them back into stasis again after "re-animation".
On event handlers
The event handler system is great for many things, but also something that too often is so misused it makes me cry. Examples of the horrors people do:
* Use the fired event to exec a heavy .sqs script. <-- this should really trigger FADE on the originator's computers...bloody 'eck... ::)
* Use the killed event to spawn off a "body cleanup script", one per loon killed leading to oodles of .sqs:es running. :-X
(Keywords for solving #2 there: array, queue, 1 singleton monitor script...well duh...)
-
Killswitch:
Thank you. The problem with puttung the ai to sleep is that things are meant to be happenign all over the island, including soldiers setting off to find the player - that could not happen is they were asleep. No I need them all corpus mentis.
-
Putting my C++ hat on, I certainly agree with HateR, more to the point, he's 100% on the money
Event handlers are interrupts. They don't in themselves contribute to lag except the small amount of crunch time they use, when used. You wont do a thing to reduce lag by removing them because the internal workings that check if an event handler is 'registered' is still going to check if an event handler is 'registered', there, or not.
What you can do tho is make 100% sure that the very first thing you do at top of script is to get the hell out of there. Even at the expense of some very convoluted code.
The reason is the engine interprets all syntax on the fly, it doesn't have a 'compiled' version internally, it interprets scripts each time, every time (with some minor adjustments to an internal syntax and stucture, but, 'MyBestLoon' remains as 'MyBestLoon', not, binary[45723]-> to something.
Obviously preventing an event script from happening by removing it altogether, is going to reduce lag, but you'll do nothing to remove the need to check for one. If as you say, everything more or less funnels into one of three events, then making sure that script exits real fast, is the best option, combined with Barron's statement that don't put anything in that exit condition that relies on complex (engine) math.
I would do this
if permanent simple flag get the hell out of here
do lots of stuff
if lots of conditions, set permanent flag.
Ie reduce all the complex test stuff to a simple top of script, flag and exit.
Edit:
@KillSwitch
Precisely. If authors understood the nature of an interrupt, that it's operating in 'real time', they'd hopefully be more circumspect in what they wanted to do, real time. At least their expectations would be a bit less dramatic and they'd then only have themselves to blame, as in DUH!
-
Thinking about Killswitch's suggestion. Instead of creating a group on the other side of the island and giving them a Move order to some place, why not just remember where they're supposed to be, and only create them if the player gets close to them?
You could have an array of locations for these units (current + destination) and speeds. Once every 10 seconds a looping script could simply make the current-location closer to the destination. Also in the loop, check distance to player, and if <500m create the unit and put it in the other array that you probably use already.
When the "current location" reaches the destination, fire your other script to pick a new destination as currently.
Ok, so it's not precise. It won't create traffic jams as batallions of trucks bump into each other. It probably won't slow things down as loons get in and out of transport or move up hills & through forests. Groups would fly across the sea rather than going round the bay, and so on. But it would surely load the CPU less than using actual groups, precisely because it would ignore all that stuff.
-
Bluehand:
Nice idea, but not for my mission I am afraid. To work it would require that I knew where each group was supposed to be and when it was supposed to be there. Possible (maybe) for a mission that lasts 20 minues, but not one that can easily last 20 hours.
-
I am not familiar with your mission (shame on me for not playing it already), but I assume that you are using one or more scripts. If this is the case then this may help some although others have debated the merits of this theory.
This was directed to a different simulator that begins with a "V", ends with an "S" and has a "B" in the middle so it may not be totally correct in regards to OFP. The premise is to amend scripts so there are fewer lines of code but they are longer. An example:
Example 1.
#start
_i = 1
_i = _i + 1
_i = _i * 22
_i = _i + 1
goto "start"
Example 2.
#start
_i = 1;_i = _i + 1;_i = _i * 22;_i = _i + 1;goto "start"
Example #2 would be more effecient than #1. Again, there are some that disagree with this theory. As another OFPEC poster stated on the "other" forum that "the engine allocates time to the scripting system on a per-line basis".
The only reason that I think that the theory has merit is that the "other" sim just had a series of patches and one of them re-formatted the mission.sqm to a format similiar to example #2 as opposed to the "classic" OFP style of the sqm. More to the point it eliminates most of the blank spaces found in the OFP sqm by displaying the code from the border while listing addons in a format like example #2.
Just some food for thought but I would be interested to hear what others have to say about this concept.
Wadmann
-
>allocates time to the scripting system on a per-line basis
As far as I'm concerned the engine would allocate time on a per command basis. semicoloned or otherwise. Not on lines, or any other device.
The only 'evidence' for this theory is that a scripter thought this new layout looked more 'professional'. Debatable in itself. I've never seen a benchmark proving or disproving it. Am happy to declare it an old wives tale till proved wrong. Not that you are wrong to mention it, all comment is good comment, to nail this mother of a problem.
-
@THobson
putting 1 and 1 together to make 11 I've been told, and/or discovered the following:
The engine does *not* retain a compiled version of a script. It process it on the fly.
The engine (afaik) does not use THE script again after first encounter, but rather an internal copy of it (which ends up in the fps file). For this reason, you can't edit sqs files middle of the mission, and expect them to work the new way.
Some mission.sqm's (among other things) are so-called 'encrypted'. Which isn't encryption at all, just an internal, tableised view of the script. It is this 'encryption' I believe is the internal structure of any sqs file eg. I already wrote a decrypter, thanks mostly to hard work done by Bas, but if I reversed it to 'encrypt' various script files, it might make a peformance boost.
This would come about only if there were an intermediary stage that the engine goes through in converting scripts to table entries each time, every time, before using them.
I'll contact you via pm for this, as it may be long and painfull, but am mentioning it here in the hope some kind soul can slap me down quickly before I run up a long dark tunnel.
-
The engine (afaik) does not use THE script again after first encounter, but rather an internal copy of it (which ends up in the fps file). For this reason, you can't edit sqs files middle of the mission, and expect them to work the new way.
**buzz** Wrong. I don't know if this changes after you package the mission into a .pbo, but if you are working in the editor, you can start a mission, run a script, edit the script outside of OFP, and then run the script again, and you will get the changed script.
This only works if the script exits and then is started again. I believe OFP loads the entire script into memory, then reads it line by line, and then gets rid of it once the script exits (this checked by editing a script while it is still running and seeing if it changes in OFP).
For this reason, one way to reduce memory load by a little bit is to use the smallest variable names possible. So instead of something like _man, use something like _a. Of course, this makes it difficult to keep track of what is what when writing the script. To fix that, MachoMan had made a tool for the ECP that will take a script and convert all local variables into _a, _b, _c, etc. You might wanna PM him to see if you can use it.
if I reversed it to 'encrypt' various script files, it might make a peformance boost.
I would be VERY interested in such a tool if it indeed worked.
-
Indeed...
If that 'encryption' really does give a performance boost, I would also be very intersted in it... :)
EDIT:
About the semicolon stuff...
I really doubt that putting the code on one line separated with semicolons would be any more efficient than putting all in separate lines ending with a semicolon...
The same thing more or less... me thinks.
-
So variable names like:
_MGPatrolVehicles
HoudanWoman_Clone
_knownInfantryGroups
Are probably not a good idea?
Bugger!
I have the same experience of being able to edit a script within a mission being run from the editor and so long as the script had exited the revised script will be used.
I have assumed that when a script (in a pbo version of the mission) exits then OFP unloads it so, for example, all the local variables would then cease to take up space (and name slots).
In my mission I have tried to minimise the number of sripts permanently running it the background. There is one for the weather; one for the fog; four instances of a script that detects if the lead vehicle of group has got screwed up and fixes is; two instances of a script that moves a couple of triggers with each convoy and controls the disembarkation and embbarkation of the infantry on board; about 44 instances (one for each armoured unit) of script that generates the burn effect when they die; and one script that does the housekeeping - running all the other scripts at set intervals. I also had 33 instances of a script that dected when a flag carrier died and passed the flag to the new group leader - but I have removed that functionality. Even with these 33 instances running that is hardly exorbitant.
I will now have a look at the numbers of variables and the variable names I use in the scripts, especially those that run continuously.
-
>Buzz wrong
One of those rare instances in human nature where I'm thrilled, to be wrong.
>on exit
that's the key I missed.
>string names.
Complete furphy. This is ram overhead only, and insignificant at that. Definately the wrong dark tunnel chasing labels to improve performance. Arrays yes, mutliple and profuse variables, yes, but not whether one has 1 or sixteen characters attached. The storage alone to hash and index them would take more space. Drop it.
>Semicolons
no engine in the world can handle immeasurable lengths of string. the command, and command alone is the definition of what's processed, not the line, not the white space, nor //comments nor embbedded brace{} (except each brace alone is considered a 'command' for the brief time it's processed)
It would be a far stretch to assume any amount of whitespace (newlines, comments, tabs) contribute anything significant to parsing the text. Even visual basic can rattle through this stuff at a rate of knots.
Will start working on an encrypter. Hope people realise it's the wrong choice of words, it's just a hash tableiser.
-
>string names.
Complete furphy.
Heh, I guess I'm guilty of just passing along rumors I heard elsewhere ;).
Anyway Thobson, if you want to know the source of 99% of the lag in your mission, it is going to be the units you have. I seriously doubt that you are going to be able to get much of a performance boost by changing around anything else.
I made a mission with about 150 units and very few scripts/triggers, and it lagged me worse than other missions using much less units but much more scripting. It's just a case of the simulated objects taking way more CPU power than any script or trigger, and you having a ton of those objects. Makes sense when you think about how much stuff the AI must have running thru it's head at any given moment. Then multiply that by x groups, and you get the picture....
Have you tried the disableAI command on all the units yet? I'd be curious just to see if it has any effect, even if you didn't end up using it.
-----------
One thing I would suggest though is using either the benchmark command or an options dialog that would change the effects settings based on the player's computer.
A fire script on armored vehicles might be nice, but not if your computer is already lagging. And having a script that monitors the damage of a vehicle to play a fire effect at 80% damage isn't as good as just using a killed EH if your computer could still use some help. If his computer runs the mission fine, then it isn't a problem to add in the full effect (Although an even better way to do it might be to use a "hit" eventhandler that checks to total damage value after each hit. If the damage is too low, it exits. If it is high enough, then it plays the fire effect and removes the EH).
You could then add back in your flag effect for computers that can run the mission smoothly. And then you could tailor any future effects you wanted to add in a similar fashion.
-
Anyway Thobson, if you want to know the source of 99% of the lag in your mission, it is going to be the units you have. I seriously doubt that you are going to be able to get much of a performance boost by changing around anything else.
I think you are right and referring to an earlier post of yours I think specifically it is live armour units. The OFP seems smart enough cut down on its own work on these if they are some distance from the player so lag happens when there are a lot of them in a smallish space. Your comment about them becoming static objects and so less laggy when they are dead is supported by my recent experience, a very laggy location when left for a while became quite okay.
I could try a Hit EH on the vehicles. I was reluctant to do this because with men a hit EH doesn't capture all damaging events, explosions for instance. The problem with using a killed EH on a vehicle is that vehicles can to all intents and purposes be dead, but not actually dead. Anyway I ran a test on Malden using 5,000 armoured units all with the script running and as long as I couldn't see any of them the lag was not detectable. Again leading me to the same conclusion that you have - it is units not scripts that is doing it. So I may even put the flag swapping back - but see the third paragraph down from here about a threshold.
I have found the benchmark command not to be a reliable indicator of a machine's performance. From the comments of some of the beta testers machine that are lower spec than mine perform less well, but can have a much higher benchmark. So I really don't know what is going on there. A dialogue is a good idea. I avoided that because from the start of the intro I wanted the player to be completely immersed. I could try and put the dialogue at the start of the intro though, or as a Plan B I could create a separate pbo file for lower spec machines.
Disabling the AI would be an interesting experiment. Forgive me if I don't do that soon. I first need to create a reliable way of generating lag in somewhat less than the 1 to 2 hour of mission time that it currently takes. I do have ideas about how to do that though.
I may be completely wrong in this but the feeling I have about OFP is that there is some threshold of ‘load' beyond which performance deteriorates rapidly. Rather like a windows machine where the swap file goes beyond what can be held in RAM and starts paging to the hard drive. I am not suggestion there is hard drive paging in OFP, just that it feels like there is a similar threshold. Something happened around v1.2 of my mission that reduced performance significantly at certain times. Or it seemed to, it might be that threshold is psychological and is in my head, what was just acceptable was fine, what was just not acceptable was horrible. Anyway around v1.2 I added about 20 triggers, 15 of these are deleted early on, certainly long before I hit the main lag, the reminder are for environmental stuff like bird noises etc. that could go and no one would notice the lack. I also added a few small groups of infantry one large group of resistance and one large group of civis. All of that was for environmental feel. I did nothing to the armour or the chopper count.
Any thank you for all your help.
-
havent read all of this, so my excuses if this has already been mentioned.
Reducing lag when having max no of units on the map
1) Use COC's AI on demand system
This places all the stipulated units in stasis until required.
There re initialisation can be brought about by comparing the distance of their position to the nearest enemy unit or by a boolean
(Group waypoints are also seen as a possible position of these "In Stasis" units)
I've use it, its very good although sometimes you do see a slight stutter as these units are re introduced)
2) Place units in cargo in a vehicle and then when ready setpos the vehicle, unnasign them units from the vehicle and delete the vehicle. Very low cpu intense method
hope that helps
as was said before reduce triggers to a bare minimum, and if you need a lot of west knows about east or activated by west type triggers then simply use the one trigger and setpos it to each location every second or so
3) Place all your commonly used global variables in ram memory by stating them in a .sqf which you run once at the start of the mission.
Place any commonly used script or segments of (That dont have "wait until" or "goto" statements in them) into functions and then call these functions from scripts
an example
The following system is made up of a looping script that calls a number of functions every so many seconds
(forget the content, its basically monitoring conditions that a bunch of triggers used to do)
My method in my scripting is to have where possible ONLY 1 looping script. Which i call my monitor script
It looks for certain condition and then when true runs a linear script (Non looping) which runs it commands and then exits
In the example below i check a lot of endgame conditions,
Check the blue line out, this runs the checkA function
The beauty of this is, the function, which is basically a linear script is already in memory, it doesnt require the hard drive to be accessed or data written across to ram, its much more instant and therefore a lot less cpu intensive
the looping script
?!(local server):exit
~ 3 + random 1
#INIT
_a = 0
#START
~1
if(tx_StopSqs)then{goto "END"}
_a = _a + 1
if((_a == 3)&&(({alive _x}count tx_destroy)==0))then {call loadfile "tx_sys\server\CheckB.sqf"}
if(_a == 4)then {call loadfile "tx_sys\server\CheckA.sqf"}
if ((_a == 5) && (count tx_damcon >0))then{{_x setdammage 0} foreach tx_damcon}
if(_a >=5)then{_a = 0}
goto "START"
#END
;; does some boring end of mission stuff then exits
exit
checkA.sqf
if((((tx_EatStart - tx_Enow)/tx_EatStart)* 100)>=tx_Ecaslimit)then{tx_Ecashigh=true;tx_StopSqs=true;tx_Efail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Ecashigh","tx_Efail"]}
else
{if((((tx_WatStart - tx_Wnow)/tx_WatStart)* 100)>=tx_Wcaslimit)then{tx_Wcashigh=true;tx_StopSqs=true;tx_Wfail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Wcashigh","tx_Wfail"]}
else
{if((((tx_RatStart - tx_Rnow)/tx_RatStart)* 100)>=tx_Rcaslimit)then{tx_Rcashigh=true;tx_StopSqs=true;tx_Rfail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Rcashigh","tx_Rfail"]}
   else
{if(time >= tx_timelimit)then{tx_StopSqs=true;tx_timeout=true; {Publicvariable _x}foreach["tx_StopSqs","tx_timeout"]}
   };
};
};
The above stuff is used in a template for A&D missions, when the template is bug free all the long variable names will be changed to a much smaller string length
as am sure many have pointed out before in this thread
few more tips
try never to use @
better to use
#start
~0.5
?(condition):goto "SKIP"
goto "START"
#SKIP
the refresh rate for the @ command is that of a trigger
also think about reducing setviewdistance
or smoothing of the terraingrid
for some reason boats use a lot of cpu, probably because the system has to keep recalculating their height as the waves come in.
Infantry patrolling through woodland is also cpu hungry
long distances between waypoints is another
use of lots of drop commands is another, eg campfires, flares, anything that burns or gives of light basically
-
There is a lot of stuff in this thread that I am sure someone could begin to make a turorial out of. Though that person would need to do a lot of testing, for example, my experience is that an @ instruction can be smoother and less laggy than a loop of the type:
#start
~0.5
?(condition):goto "start"
but not always.
-
an @ in reality is a loop, but more in the way of
#START
@ (condition): goto "SKIP"
~0.001
goto "START"
#SKIP
so i have no idea where you get the impression that a slower loop of say half a second or even slower can be more cpu intensive
-
>encrypting files
ok, to save me a bit of time for the moment, have tracked down Amalfi's cpp2bin tool (version 1.2)
Gen Barron would be fairly familiar with it. It is, the so-called 'encryption' I'm on about. And I only use that word because other people have done so in the past, a sort of legacy thing.
For you guys to use it on files other than config.cpp (which it is hardwired to tableise) simply, and I mean, simply, rename your mission.sqm (eg) to XYZ.cpp and let this tool go to work. When done, rename it's output (XYZ.bin) back to whatever gave you a thrill in the first place.
I have tested it on various items like description.ext, mission.sqm and a few others. There are no ill effects I can detect, but I sure as hell could find them if I started *really* hunting.
It is quite logical that this tool from amalfi can 'encypt' most, almost any, 'script' file, regarldess of it's intent because the whole shebang of all scripted text begins and ends with classes that have a few and only a few, hard nosed variable types attached to them. Specifically, arrays, floats, integers and strings.
You will encounter various disparate script files, such as description.ext, such as mission.sqm, and often, config.cpp which have been encrypted in this fashion. I suspect binarize tool from bis has done the job on some of them but the intent is the same,
you can grab cpp2bin here (http://andrew.nf/ofp/tools/) (200k)
Note that, as GenBarron pointed out on the digitalgrenade forum some time ago, this tool makes a muddle of #defines other than integer and is quite pernickity about 'correct' syntax. (use and location of comments)
For the most part tho, this would be a great start for you Thobson, because it must be _very_ close to the internal post scrunched text files the engine normally reads.
Just apply it to any one of your scripts to gain confidence that the bugger works. If as GenB and others have pointed out, that the engine re-reads any given script file,(this makes perfect sense now) you're on a winnner here.
Also, I have read elsewhere (haven't we all), that COMPRESSED pbo files are slower in operation that uncompressed. Your 'armies mission is riddled with compression.
Will bury my head deeper and try and improve on Amalfi's rather good tool.
-
Terox:
i have no idea where you get the impression that a slower loop of say half a second or even slower can be more cpu intensive
Not sure about more cpu intensive, but certainly generates lag. I guess it is something to do with the scripted loop being interpreted on the fly and @ being some form of compiled instruction. Clearly there must be a value of the wait interval where they are similar in performance terms. My experience is that it depends on the complexity of the condition statement, but for a simple condition the @ beats the wait loop at intervals < 0.5
I put 5,000 BMPs on the map (I know this by heart now), each running an @ command to detect the damage of the vehicle and start the smoke script if necessary. No lag whatsoever, providing I could not see the vehicles. Change the @ to a wait loop and it was ugly anywhere on the island. The wait loop I used was:
#loop
~0.5
if (getDammage _this < 0.98) then {goto"loop"}
The @ command I used was:
@(getDammage _this > 0.98)
Mikero:
Also, I have read elsewhere (haven't we all), that COMPRESSED pbo files are slower in operation that uncompressed. Your 'armies mission is riddled with compression
I've not read it. How do you know the pbo has compression in it? How do I create one without compression?
-
Well, Amalfi's PBODecrypter reports most files in your mission pbo are compressed.
Files not compressed are ogg's and jpg's, which are already a compressed format.
17 files were reported with checksum errors, but the program managed to recover them.
Your readme and trignotes were two of them and most of the rest were .sqs files, except for one which was description.ext.
I re-pboed your mission using StuffPBO which doesn't compress anything, the resulting PBO was 16,041 Kb as opposed to 15,289 Kb with the compressed version.
Planck
-
A quick jump in in case Hobson has just been terrified. hmmm on the other hand that may be some nice revenge. Nah, I'll be nice.
>17 files reported as corrupt
this is an 'undocumented feature' of Amalfi's, they aren't. He mistakenly did a signed, not unsigned, checksum. Winpbo and my own depbo.dll confirms them as ok.
Apart from stuffpbo (which being old and no longer supported *might* have errors) you can use Amalfi's Makepbo version 1.5 Makepbo has the option of which types of file, if any, to compress, but make sure you grab 1.5, not, the more available 1.3 which has problems.
All of this stuff is here at ofpec in the editing depot.
>>have read elsewhere (haven't we all)
that was meant to be dripping sarcasm., more along the lines of yet another myth, but easy to check out whether true or not.
-
StuffPBO has never failed me yet, I use it to make any PBO I want.
Why would anyone want to make 'compressed' PBO's anyway, it just means the game has to uncompress them before use. And it doesn't save that much on space used.
Planck
-
so i have no idea where you get the impression that a slower loop of say half a second or even slower can be more cpu intensive
~ is just @ with some extra parameters. Try running this:
Hint "Hello"
~
Hint "Goodbye"
You get the following error message:
(http://homepages.gotadsl.co.uk/~gssoft/Error01.jpg)
So ~ is just a version of:
_Delay=_This Select 0
_WaitUntil=_Time+_Delay
@(_Time>_WaitUntil)
If you passed a parameter of 0.001 or used ~0.001, it would really pause for 0.002. Time increments in values of 0.001, BTW you can test this easy enough.
@(True)
So the above is faster, with less commands to process, because it pauses for a preset time period. But like any loop, dont try and do to much in one go.
@!(IsNull (NearestObject [_This Select 0,_This Select 1]))
Is probably just as bad as:
#L
~0.0009
If (IsNull (NearestObject [_This Select 0,_This Select 1])) Then {goto "L"}
And this is not much different to the above:
#L
_TTime=Time+0.0009
@(Time>_TTime)
If (IsNull (NearestObject [_This Select 0,_This Select 1])) Then {goto "L"}
-
>why would anyone compress pbo's anyway?
On 'standard' missions and *especially* campaigns, the saved space isn't large, it's HUGE. PMCfury eg, (253+ missions)compresses to one tenth it's size (don't quote me, 10 meg to 1 meg from memory)
As you point out it has little effect on jpg's and sounds (in fact, jpegs EXPAND !!! For this reason you wont see it used on most / many? addons that are models (Bas stuff eg). Thinking about it, I'm guessing this is where the myth has been generated from because people started noticing many addons are uncompressed. They put 9 and 6 together and came up with halfpence. Still, all the same, it's worth checking out if compression really does slug the engine or not. Anyone playing Hobson's masterpiece would pick the difference, real quick.
Afaik, stuffpbo doesn't provide resistance signatures in it's pbo file. I'm not aware of anything that actually takes note of those signatures but it is a deficit.
-
StuffPBO is Pre-Resistance anyway.
I placed THobsons mission with the one I re-PBOed with StuffPBO in the missions folder, replacing the original.
It played the same as before, no discernable difference in my fps rate anyway.
It even still loaded my saves from the original.
Planck
-
@Mikero
Could you open a new thread to discuss this "compression" that you are talking about? I'd like to ask some questions, but I don't want to use Thobson's thread. Plus I'm sure others would be interested in such a thread as well.
A dialogue is a good idea. I avoided that because from the start of the intro I wanted the player to be completely immersed. I could try and put the dialogue at the start of the intro though, or as a Plan B I could create a separate pbo file for lower spec machines.
Err... IIRC, your mission has no cutscene at the start of the real mission (after the intro). So why not put the dialog there? When the player first gets to climb that damn cliff I mean.
I may be completely wrong in this but the feeling I have about OFP is that there is some threshold of ‘load' beyond which performance deteriorates rapidly.
I'm not so sure about that. Like I said, an old mission of mine (Platoon Commander) has like 150 units in a relatively small area, but nearly no scripts. It lags my computer a noticable amount at the start of the fighting. Your mission was still playable on my computer, and it didn't seem to have an 'excessive' amount of lag to me, considering how un-great my system is, and how much stuff is happening in that mission at one time.
for some reason boats use a lot of cpu, probably because the system has to keep recalculating their height as the waves come in.
That might be an idea. "Sink" that boat at mission start, since I doubt it gets used anyway. Would add to the feeling that "there's no turning back".
-
Goto #label vs not
I get the feeling that using 'goto', or in fact looping in any way, is a large source of lag - simply the act of completing one loop and returning to a label causes a heck of a lot, for some reason
I ran into this problem during some drop scripts, where I was tring to produce a continuos glow in a single spot. One or two scripts worked fine, but after three or more were running consecutively the lag demon reared its head. So, I replaced
#loop
drop ...
~0.01
with
#loop
drop ...
drop ...
drop ...
drop ...
drop ...
drop ...
drop ...
drop ...
~0.05
and completely counter to what you might expect, the framerate shot up. Unbelieveably, the second version still outperformed the first version with 10, 20, 30 and all the way up to about 50 drop commands in the space of one loop. By 'outperformed' I mean that the colour was more intense (drops were in the same spot), less drops were missed AND framerate was much higher/less lag. This is what led me to the conclusion in the first paragraph. I've no idea why it might be, but it is.
-
I have some experience that when a goto is executed the program pointer goes back to the top of the script and then searches forward until it finds the lable. Directionally that would support your experience, though I am surprised that is was so significant.
-
>program goes back to top of script
I believe this to be correct too and you are *definately* onto something here. The engine doesn't compile scripts only interprets line-at-a-time. It has no knowledge of where the #loop is until it encounters it.
This _might_ be a fundamental difference between sqs and functions. Maybe, perhaps, and well worth checking.
-
I have some experience that when a goto is executed the program pointer goes back to the top of the script and then searches forward until it finds the lable.
Very interesting, and I'll definately take note of that. From now on, if I have any loops, they will go at the top of the script!
The beauty of this is, the function, which is basically a linear script is already in memory, it doesnt require the hard drive to be accessed or data written across to ram, its much more instant and therefore a lot less cpu intensive
This _might_ be a fundamental difference between sqs and functions. Maybe, perhaps, and well worth checking.
Err... yes and no. A "function" is just a STRING, which is executed as code via the "call" command.
Standard practice is to save these strings into a variable, with something like my_func = preprocessfile "blah.sqf" or my_func = loadfile "blah.sqf". The difference between "preprocess" and "load" is that all the comments are taken out of preprocessed files (I believe--although it would be simple to check).
Since this variable is saved, it would make sense that OFP could access it faster, since it doesn't have to load up the file each time it is run. However, I doubt that OFP actually RUNS the code in any different way than normal script code (except that functions can't have delays or 'goto's of course).
So Terox's statement is somewhat correct. The .sqf file itself is nothing special. It is the act of storing these functions into a variable that makes them different than scripts. I had to point this out because look at Terox's example code:
?!(local server):exit
~ 3 + random 1
#INIT
_a = 0
#START
~1
if(tx_StopSqs)then{goto "END"}
_a = _a + 1
if((_a == 3)&&(({alive _x}count tx_destroy)==0))then {[b]call loadfile "tx_sys\server\CheckB.sqf"[/b]}
if(_a == 4)then {[b]call loadfile "tx_sys\server\CheckA.sqf"[/b]}
if ((_a == 5) && (count tx_damcon >0))then{{_x setdammage 0} foreach tx_damcon}
if(_a >=5)then{_a = 0}
goto "START"
#END
;; does some boring end of mission stuff then exits
exit
Notice that he LOADS the function every time he calls it. This is essentially the same as loading a script each time it is run, like OFP does. If he wanted "a linear script already in memory", then he should have loaded the file ONCE, and saved it into a variable (local or global).
But if he were to do that, then I think there would be some performance increase--at least in very fast looping scripts that repeatedly execute another script (or function).
Another great thing about functions is that line breaks are indicated by semicolons; instead of the 'return' key, so you can lay out long strings, if/then, or do/while conditions in a neat way. :)
EDIT
I think you guys already mentioned this, but I'm kinda dense :). Anyways, if a "goto" causes the script to be read again from the start, then that might explain why an @condition usually runs faster than an very short "goto" loop.
The @condition is prolly checked every clock cycle or so--while the "goto" statement causes the script to be searched thru until the label as mentioned. Unless the label is near the top of the script, then there might be quite a bit of code for OFP to search thru--every 0.5 seconds or so, depending on the delay.
So which is faster? Searching thru X lines of code to find a label, then checking a condition, every 0.01+ seconds? Or checking a condition every 0.001 seconds? I imagine the answer is going to be a combination between how much code is above the label, and how complex the condition being checked is. With that in mind, it seems likely that an @might be faster than a ~0.5 delay, if it is down under a bit of code.
Good stuff to keep in mind, instead of just blindly making loops everywhere, in fear of using an @condition.
Oh yeah, and I have more evidence to support this (labels being searched for from the top): if you ask a script to "goto" a non-existant label, the script will exit instead of giving an error or continuing on--indicating that it just kept searching until the end of the file, as opposed to 'preprocessing' the labels on first execution.
-
I imagine the answer is going to be a combination between how much code is above the label, and how complex the condition being checked is. With that in mind, it seems likely that an @might be faster than a ~0.5 delay, if it is down under a bit of code.
Good stuff to keep in mind, instead of just blindly making loops everywhere, in fear of using an @condition.
I fully agree. Each case needs to be checked, my 5,000 @s vs 5,000 loops give a very clear result the @ won by a mile - and the loop was at the top of the script (the first line after the comments and the _this select lines)
In addition to running a script with a goto to a lable that doesn't exist, try running one with mutliple duplicate lables.
My experience - but I have not tested exhaustively - is that the scriipt will continue at the upper most occurance of the lable.
My flag changing script had a loop with a delay of 11.11 seconds, even replacing that with an @ seemed to improve things. I only had 33 instances running so it could have been psychological. I need to try it with a few thousand. The problem is I think my company will stop paying me if I don't spend some time with them. I'll put it on the list of things to do.
-
>gotos cause scripts to start at top.
A *minor* tweak here that is more consistent with GenBarron's statement about falling thru (no label=no errors)
The engine is likely to scan downwards and then start at top if not satisfied.
This would make
#very_slow;
....
goto very_fast;
goto very_slow;
.....
#very_fast
Indeed I have seen apparently convoluted code do similar to this (and think there was an example in an earlier post or two on this thread)
@Hobson
the scriipt will continue at the upper most occurance of the lable.
in which case it would blow my theory out the door, UNLESS all of these labels were after the goto. (you're not specific about 'uppermost')
>re-reads file
I don't think that's true, i 'think' it uses it's in memory copy because I've never been succesfull in altering a *running* script. (one that doesn't exit) Can easily be wrong here and a ten second loop displaying a hint would prove one way or other.
----
I think what needs to be established here is
1) is the file re-read.
2) is there a difference between forward goto's and reverse ones.
3) depending on 2) is the file re-read.
The answers may make incredible differences in performance.
-
Okay: I have not investigated this in detail, but my experience is (if I am remebering correctly) that a lable above the goto will be selected in preference to a lable below the goto. I do need to check but my recollection is:
#lable
goto"lable"
#lable
never get here
I am at work and cannot check I am remebering correctly.
-
Gee, what an excellent discussion!
So, as a result of the fact that script searches the entire length of the sqs from top to bottom, you are saying that I would be better off replacing my 0.01 loop with this:
#LoopYouAreBad
cmd
cmd2
cmd3
~0.01
cmd
cmd2
cmd3
~0.01
cmd
cmd2
cmd3
~0.01
cmd
cmd2
cmd3
~0.01
cmd
cmd2
cmd3
~0.01
goto "LoopYouAreBad"
or something similar? Perhaps even more commands between the goto and the # ? And I would benefit from putting all of this as close to the top of my sqs as possible?
Whoever said 'scripting is like black magic' - you were dead right.
I will experiment with these two concepts next time I get the chance, possibly tomorrow.
Assuming we haven't already, isn't it time to get confirmation from the people who wrote the code themselves- i.e. Bohemia Interactive - by starting a topic on the official forums? Or has such confirmation already been attained?
-
Fragorl:
In general I would never suggest a structure like that in preference to a straightforward loop. It is untidy, error prone and ugly. BUT: In some circumstances, where a script will be run many times simultaneously and where speed is critical it might just be excusable.
A lot of this discusion has been about @ vs a goto loop. Not mentioned so far is a goto loop vs a forEach loop or a while - do loop
I am developing a strong preference for these, especially the forEach loop, but have not tested their impact on performance. My guess is that forEach will beat a goto loop because the program pointer doesn't have to go anywhere.
-
Yeesh, just read all four pages. Way to start an interesting topic Thobson. ;)
I only want to comment on one thing. About dead bodies, it was said they are turned into objects a little while after they die, I don't think that's true. I've grouped people to me and then set their health to 0 via the slider and previewed the mission. Come to find out, my dead buddy was part of the team, still listed on my group list and on the screen as number 6. I could order him to do stuff yet being dead, he'd just respond negative after a while. He even reported enemies when I placed some east troops around him. So I wonder if that could increase CPU? Or is what I said a special circumstance, any other unit would just die and cease its AI routines?
I've also tested some of the dead body lag effects in one of my non released missions, simulating a DDay invasion. You guessed it, tons of troops, boats, MGs, mortars, and tons of enemy troops negoitiaging the hillside while firing down on us. Noticeable lag I can tell you that. Now I used a delete body script which really seemed to help out near the middle and end of the mission. I only deleted certain people that the player would not want to look for weapons from so I could keep the look of carnage on the beach while getting rid of any lag causers who were out of view. But I may be wrong on bodies, since I don't really know. ;)
@your enviromental sounds: I forget if you're able to put the sound object in. You know its hidden in those drop down menus under empty and there are objects that I thought just repeat the sound over and over again, no trigger needed. May be wrong on that too. :P
EDIT: Now that I'm thinking about it, if I'm on to something on the dead AI still being a part of the team and what it means to other dead then maybe when the unit dies, he is just ungrouped so he can't talk to them anymore. A single unit can't really communicate with anyone else, especially when they are dead. I think I could support this by saying what happens when you setdammage 0 to a dead unit?
Hmm, after testing my idea doesn't quite work out all the way. Someone prove me wrong. :D
-
I know people delete bodies to cut down on lag. I don't want to do any of that. What we were talking about though was the lag generated by having mutiple armour units nearby. That lag seems to diminish after they have been dead for a while.
I started off using Sound Objects. Several problems - you can't create a sound object, nor can you move it, also they do make the sound over and over, for a while, but not for hours. Eventually they seem to run out. I want the sounds only under certain circumstances so I need to be able to move or create them and I want the sound to be heard hours after the start of the mission. I have used triggers only as a last resort.
The Wolf Packs are different. I use my own script to create those. I might do something similar with the other sounds.
-
@ Dead bodies
I'm sure that they turn into static objects after a while. The fact that you can't 'bring them back to life' after a certain amount of time supports this theory. So does their output if you print them via the 'format' command (it says "STATIC" and looks like any other static object).
The reason the lag difference is so noticable when deleting them may be because they can and do hold weapons on them, unlike a regular static object such as a wall or bush. I would assume that having those weapons around requires more work for OFP to handle, since it has to pop the actions into your menu whenever you get close to them, etc.
@ Foreach / do-while loops
I would assume that these both run much faster than a 'goto' loop. I would assume that the program thread reading the script stays entirely within the codestring used by both commands. Problem with these commands is that you cannot have any delays in them. Other than that they are great to use, except for the fact that you can't put stuff on multiple lines in a script! I hope they change that in the next game...
-
@ functions, interpreting and comments
Similarly to scripts and goto calls, it would make sense that a function's length is also very important in its speed of execution. And of course one of the biggest contributers to function length is in fact the comment. Going on what we have learnt here, whilst languages like C++ are precompiled, where comments themselves are totally left out of the resultant machine code and so have no effect on the speed at which the code is executed whatsoever (:P), the same is obviously not true of functions.
Some experimentation shows that neither preprocessFile nor loadfile remove the comments from the stringified function - surely, then, the parser spends valuable time searching, character by character, for the end of any comments it comes across, during the function call. Sounds as though comments are out then...
Btw, what did people think about starting a topic on the official forums to get these kind of questions answered in detail by the creators?
-
>neither preprocessFile nor loadfile remove the comments from the stringified function
WOW!
>starting a topic on the official forums
would they really know?
There was a thread on bis about functions where Raptor (I think) made the comment that 'unfortunately' they don't have or use an internal compiler. From that point on, everthing about interpreting functions and scripts then made sense to me.
-
neither preprocessFile nor loadfile remove the comments from the stringified function
I wonder what the difference between preprocessing and loading a file is then?
-
I wonder what the difference between preprocessing and loading a file is then?
Assuming we have this:
// func.sqf
comment { Some comment };
// Another comment
player globalChat "Hello world";and do a
func = preprocessFile "func.sqf"
hint format["%1",func]
...you will see that the comment {...} block is still there, but the "//-comments" are gone. Go figure... yet another "feature" of our beloved OFP ;D
-
Hm... don't know why, but whenever i've tried to use // comments, the dubugger spits out an error and tells me i've made a mistake...
-
@fragorl
a common mistake is
a=1 // a comment
(needs a semicolon)