Scripting Ideas to reduce Lag

[AUS_Viper]

For all the budding VBS1 scripters, after much trial and tribulation on my part, I have a few handy tips to keep the framerates to an acceptable level.

Many of these tips I wish I knew when scripting my first few missions...

1. Try entering commands / functions etc in the init field of triggers, units etc rather than calling external sqs files. On some occassions, you just have to call sqs files - but if your don't need to, don't do it. A common mistake is doing a sqs file for weapon loadouts. Sure it's easier in wordpad, but it's less CPU intensive in the init fields

2. Don't complicate vcl's or unit movements with CPU intensive scripts, when just a simple trigger sychronised to a waypoint will suffice. ie move to the combat zone when "this" condition in the trigger is met

3. It's fun to jump into the editor and place units here, there and everywhere. DONT! Place specific units where you need very specific positioning (ie a sniper behind the bush), but if it's standard patrols, spawn them with an associated waypoint when you really need them. Linked to a few gamelogic triggers, you can really get a random starting pos for a squad working quite well.

4. Delete things if you don't need them anymore using a trigger and a DeleteVehicle command. For example, if a chopper drops you off and flys into the sunset - delete him. Don't let him waste CPU usage by hovering or landing somewhere.

4. View Distance is a big CPU performance hit. It's nice to stand on the beach and see the mountains in the distance some 3000m away, but since the standard rifles don't fire that far - use either the SetViewDistance command or the negoview.sqs file for MP. Negoview can be found about the 7th item down on this page.

I have found this to be one of the biggest reductions in CPU processing. Hell, some CQB type missions in the desert cities (ie Mau Samet) need only a view distance of 500 - 900!

5. There is much to be said about using the event handler to delete dead bodies after a certain amount of time. Many will say, add an eventhandler linked to a script that will delete the bodies after they are killed - sounds reasonable? Surely the dead body is taking up CPU time by just lying there?

IMHO - I thoroughly disagree! The very fact that you may have upto 20 or so scripts running to delete the dead bodies in the first place really nullify's the intention. I have a low end system and I can say from personal experience, that the scripts running to delete all these dead bodies are more CPU hungry than the bodies themselves. Test for yourself Don't be confused with the deletevehicle issue in point 4 - this is specifically talking about adding an event handler to all OPFOR to delete when killed as opposed to deleting a couple of choppers or so.

6. sqf (function files) are less CPU intensive than sqs (script files)

7. When you are using external sqs files - notes are good to explain how to use the file (whether it's yours or a third parties). However, in your final mission version, delete the notes (anything with a ; prefix). It's just another line of code that the engine has to check.

8. Sometimes a well placed sniper with a keen "one shot and move" script, coupled with a random placed squad working under a hunter killer script will keep the boys heads down just as well as adding 50 OPFOR units.

9. Keep eye candy to a minimum. A common mistake I made was to build these fantastic bases (as per the old command and conquer doctrine) with tanks, aircraft, etc. Trouble is - all this takes up CPU usage. Question yourself as you script...

Will our BLUFOR players have a much easier time against 2 T80 tanks as opposed to 3 T80's? If they only have one Javelin, then why throw in 3 tanks? Two will suffice.

Do we need two Mi24's and a Mi17 in the air? Maybe just one gunship will be OK.

10. Rather than have 50 OPFOR units on the map with individual waypoints, actions, domove commands, etc if they detect the BLUFOR boys, use information sharing scripts with much less OPFOR numbers. A big issue I found early on with the OPFOR is when his mate is standing some 50 metres away and is taken out by a 5.56mm round, he still stands there whistling dixie (or whatever the Russian version is). I am a big fan of the AI Information Sharing script by General Barron over at OPFEC. Basically, you can get away with much less units as the OPFOR will share information on where the targets are (ie you and your mates). Instead of 50 units guarding a base, you may only need 20 - since once the brown stuff hits the fan, they all have a fair idea of where the fire is coming from - much more realistic than just using the editor. Download this script from this page.

These are only a few tips to help reduce the framerate lag. There are many more and for all the GR scripters going over to VBS1 I suggest you stop off at http://www.ofpec.com/ and check the editors section. In GR we had a small map to work with, so we were much more carefull of unit and vcl placement and spawning - in VBS1 we have a huge map so it's easy to fall into the trap of placing units all over the place. God knows I did at first

For OFP converts - all this is probably old news

For anyone who downloaded my early VBS1 missions, you will probably say "Hey Vipes - What gives? All the points you advised against were actually in your missions"

My answer is - Yes youre right. But I just tested my latest mission with 12 MP players in Coop, which is much more difficult than any of my earlier attempts - with one slight difference.....no discernable lag.

Hope this helps.

Cheers

[dekela]

good post vipe's with sound tried and proven advice

cheers......

[CrowmanUK]

Cheers mate, some good points raised there, one thing you can do that took me ages to find out is you can copy and paste, so if you make a unit with a specific loadout you can select him, CTR + C, then paste him over and over to build your teams up and they'll all have the same loadout, that comes into its own when you're making minefields too.

[en4rcment]

Excellent post!

As a former GR modder converting to VBS1, these tips are necessary and crucial.

Many thanks for all of the advice (keep it coming!) for us novice mission makers...

[dekela]

very good point crowman, it does indeed speed up placement of troops, vcl's etc. also the copy and paste function in the init field can save some finger slapping.

the point vipes makes about triggers v scripts cant be overstated. i for one use very few sqs file's and those that i do are indeed crude and basic. mostly because it's like talking martian to me. most of my events are trigger based, and with a little thinking "outside the box," you can accomplish nearly anything with triggers alone

the other point regarding number and placement of opfor is also vital. while everyone woould love to duplicate unisol's century, a balance must be met. this is both in relation to keeping things realistic, as well as improving performance. in my missions i tend to use a three to one ratio for opfor units. so if you have a ten man SASR section, face them off against 30 odd well placed and "scripted" troops. and yes, one sniper that is keeping your head down from 1000m is both daunting and functional. in my second mission, once the sniper becomes active, a spetz team run a hunter killer script on the unit leader. can make for some rather intense moments.

cheers......

[AUS_Viper]

@crowman - yes a very good and often overlooked piece of advice.

Another one that took me ages to figure out....

When you are typing in text into init fields in the editor and you notice that a word pops up just above where your typing, similar to autocorrect in Word.

ie you start typing setbe...and the word setbehaviour pops up. How do you have this suggested word added without typing the entire thing....just hit the "TAB" button.