OFPEC Forum
Editors Depot - Mission Editing and Scripting => OFP - Editing/Scripting Multiplayer => Topic started by: myke13021 on 08 Apr 2004, 05:42:28
-
Ok, i'm a little unsure...the map i make will need lots of triggers...around 50...how much will they cause lag and does it make sense to replace them by looped scripts with a wait time of about 1 or 2 seconds?
If you already had similar probs, please tell me how you solved it. I really like to learn of your knowledge.
Thx in advance
-
With triggers you must understand a few things.
- Triggers check for condition every 0.5 seconds. This needs x amount of cpu.
- The size of the area which the trigger checks affects the x amount of cpu required increasing it when larger and decreasing it when smaller.
- The number and complexity of the conditions which the trigger is made to check affects the required cpu increasing it when complex and decreasing it when less complex.
- In MP triggers are always checked and executed on all machines.
With scripts you can
- Raise the amount of time the condition is checked, which lowers the required cpu usage.
- Use local variables instead of global.
- Execute the script only on server and use publicvariable to pass the needed info to client scripts, which gives the server more workload and less for clients.
- Do more efficient scripting.
Your question is obvious. Use scripts where possible and smart. The best and usually easiest way is to use scripts executing and passing info to scripts. :)
-
If you have multiple triggers that do exactly the same thing, then it is more efficient to use one, and have it run through a setpos cycle
Triggers loop faster than 0.5 seconds, they i believe run at the same speed as the @ command which is something like 0.001 i believe
-
yep i see the point...so theres a few triggers i could (and will) replace by scripts with a 1 or 2 second delay...this would be fast enough for my purposes.
too sad there is no option to slow down triggers ;D
thx lads to share your knowledge...life is a permanent school ;)
-
The loop delay may be dependant on framerate. For example, a loop without a delay:
#loop
hint "text"
goto "loop"
Seems to execute once per frame. I haven't tested it, but it seems like a decent way to detect framerate. Hmm.. how about a script that adjusts view distance or visual detail automatically by framerate ;)
Also, I think loops can't run faster than once per frame.
-
lol Tactician.....i don't need faster runnin loops...i'm just about to figure out how i can make my actual map i'm working on, multiplayer friendly, means: how can i prevent lag the best way....so i'm about to transform some of the triggers i already set to scripts with a 1 second delay.
So i hope this will make the map better playable on the internet.
-
Actually after some testing, loops seem to go much faster than once per frame; my result was around 1200Hz for a delay-less loop.
Here's a script to test it.
pollfps.sqs
;; execution: [] exec "pollfps.sqs"
;; best by a radio trigger
_i = 0
_endTime = time + 1
#loop
;; optional delay here
_i = _i + 1
?(time < _endTime): goto "loop"
hint format ["%1",_i]
This can still be a good way to judge performance, as the results very each time. With some more research.
P.S. There was no noticable framerate drop during the poll, but it was always lower while I was moving.
-
very nice Script Tactician....i'm getting values at 3750...does this mean my machine is a little faster than yours? ;)
-
ok, i hope this will prevent major lag on my map....replaced 30 triggers by 3 1 sec delay looped scripts.
Thank you all for your input.
-
Thnx to Tactician for the nice little fps script.
I've been using it a lot to pinpoint fps heavy units, triggers scripts.
after a while the annoying hint-ping...almost freaked me out lol.
So here's a little tweaked version of the script which uses titletext instead of hint:
;; execution: [] exec "fps.sqs"
;; best by a radio trigger
; By Tactician , modified a tiny little bit by ponq
#loop2
_i = 0
_endTime = time + 1
#loop
;; optional delay here
_i = _i + 1
?(time < _endTime): goto "loop"
_txt = format ["%1",_i]
titletext [_txt, "Plain Down"]
~1
goto "loop2"
;D
-
if you want to monitor the fps on a client server system then run fraps in the background. The server has its own monitor system
#monitor 1
turned off again by #monitor 0
the number being the refrersh rate in seconds of the monitor
this is a decent way to measure the load that your units scripts etc are creating
anything 10 + should work okay
20fps + is good
30+ is great
the island chosen for the mission effects this also
the vast majority of missions runs at 15 to 25 fps
you will start to see noticeble lag below 10
hope that helps
NB>>>> My reference to triggers refreshing at the framerate is incorrect, its as stated above by Artak 0.5 seconds
ASpologies if this was misleading
A good way of reducing triggers a lot, is to have 1 trigger that encompasses the entire mission area
Activation: Anybody
Set to Repeatedly
Condition: this
lets name this trigger "EveryUnit"
Using side queries and distance queries you can then pull just about all the information you will need about units on the map
eg
to create an array consisting of all units for a particular side, you can run a script and use the following line
EastArray = []
{ if (side _x == EAST) then {EastArray = EastArray + [_x]}} forEach list EVERYUNIT
you then have an automatically created array which you can then query or setcommands to each unit
eg adding an event handler
{_x Addeventhandler ["Killed", {_this exec "server\civvykilled.sqs"}]} ForEach EastArray
or used as a distance command to say a mine
{IF (_x distance (MinearrayA select _MineNo) <=15) THEN {_detonate = true}} forEach EastArray
as you can see for one simple trigger you can pull out a lot of data which you can then query and run commands on
i believe if the trigger is set to Activation: Civilian, it will even allow the creation an array of empty vehicles for you
what this basically means is that you can make a template for your missions which requires little user input to fill in player side arrays etc etc and is almost fully automated