fred41

@Blue1, i'm really curious about it. Seems i have to adapt ASM to display more then the current 50 players correctly :D

@blue1, thanks for your work for reviving this great CTI game mode. For me, CTI is a new experience (since i have spend some hours in domination, injurgency and yes wasteland and dayz :). I like the balance of tactic, strategy and action in CTI. My last evenings, i enjoyed CTI on your server and have to say, great work at all!!! I hope that you still found the time to continue your development. BTW: Introducing a steering for the number of spawned AI depending on current player count could help, to reduce lags in high load situations. I mean that a high player number should result in less (server local) AI spawning, to balance the overall load on server.

... cool, sounds very interesting, are you planning to make it? Because this will result in longer sessions, i think this should have a persistent db store in background, so that players can have a rest inside a session without loosing all the equipment.

... did you tried to fall back to system memory allocator (-malloc=system OR just delete all dll's from dll folder)? Why do you use -noCB on your server? Could be a problem with your wasteland mission too. Try to monitor the memory usage with #monitor interval for example.

I really dont know what this values in the player list mean (could be sent, receive or the sum of both?), so i cant help answering the 3 open questions. But maybe i have an interesting hint, did you tried this: #login password #debug 0.1 // updates each 100ms #debug userSent username It shows the following values: sent [bpsec], receive [bpsec] and MsgPerSec in both directions, for the specified user. It will show how dynamical the bandwith consumption per client in real is. Or, by using larger time intervals it shows very precise average results. I think this way offers a better imagination, how MaxMsgSend very likely work. This tool is required to monitor the output: http://technet.microsoft.com/en-us/sysinternals/bb896647

correct (if you assume 30FPS like before) Wireshark is very helpful for almost all network related analyses. I think this value, MaxMsgSend, is not suitable for network performance tuning. It could be used to cut bandwidth peaks per client, to prevent monopolizing of bandwidth.

Terox, you perhaps overlook one important point: MaxMsgSend is a upper limit for the number of packets allowed to be send per simulation frame and per client (it does not mean, that our server has actually to send that much packets to each client and each of this packets could be smaller then MaxPacketSize ) So, there is no reservation of bandwidth for each connected client by MaxMsgSend. BTW: thanks for you effort, to make a useful documentation for this important values

Why do you close critical posts/threads that fast/rigorous? What is the sense of this forum, if not exchange of informations/meanings and yes, emotions? Examples: open for only 8 min, although contains very interesting statements http://forums.bistudio.com/showthread.php?156795-Is-ArmA-3-engine-really-this-bad here another thread, closed... http://forums.bistudio.com/showthread.php?156675-Anyone-left-working-on-ArmA-3 To remember this is the topic: "Discuss all aspects of the Alpha version of Arma 3" ... i think a bit more respect would be appropriate ...

... sorry, what rule do you mean exactly?

... confusion seems to be bound to occur, if the same term "entities" is used with two different meanings ... thanks, for testing this

LOL ... me and my perfect englisch :rolleyes:

... entities looks very interesting, because i am basically most interested in alive ones (which should produce the most load to the script interpreter). (agents seems to be mainly interesting, to be prepared for the next dayz like mod :) thanks, for the hint ...

@Predator.v2, yes. Simulation frames per second (server FPS) is basically the same, what diag_fps returns on server (and what you get from #monitor x command in game). A normal value on an empty server is 50.0 FPS, each simulation frame is here a time window of 20ms. Enough time to process the few events (generated by eventhandlers etc.) in full speed (non scheduled), to process a few statements in the VM (scheduled ececution, execVM, spawn), to eavaluate the conditions from FSMs and something else. If server load increases more and more, there is a point, when a time frame of 20ms is not enough to process all this. The length of the time frame must now be extended to process all the additional events e.t.c. (an time frame of 100ms, for example, is equal to 10.0FPS (1/0.1s). Simple spoken, the server FPS value (1/time frame length) shows you, how much non scheduled load your script interpreter have to process currently. Condition evaluations per second, on the other hand, is more related to the scheduled part (VM) of script processing. CPS is a value currently not directly available as a command, but instead measured from an reference FSM. This reference FSM counts, how frequently an internal condition is evaluated. On an empty server, conditions are evaluated for each simulation frame (50CPS), but this will change if the load increases. So this value (CPS) currently indicates two things: First: what delay you have to expect currently, for all FSM driven units (like AI). I think values above CPS = 5.0 (200 ms delay) should be not critical. If you see, for example, a CPS value of 0.2 (5000ms = 5sec), you should expect "stupid" AI in your game. Second: because condition evaluation seems to be scheduled executed, it indicates additional, something like how "loaded" script interpreters VM currently is. See here for more details (be warned it is a bit fancy): http://forums.bistudio.com/showthread.php?156542-optimization-for-script-interpreter-possible I think, if you use Arma Server Monitor for a while, with different missions and changing load, you will get very soon a feeling for the practical meaning of FPS and CPS.

@killzone_kid, thanks, sounds like a good idea. EDIT: But according to this: http://community.bistudio.com/wiki/agents (Note from Rocket bellow) this: {alive _x} count agents; would return an error ...?

@Dwarden, ok, agents, (this ones used in dayz as zombies). They should of course counted too. According to the wiki "Return a list of all units (all persons except agents). Dead units and units waiting to respawn are excluded.", "allUnits" seems to not include agents. Could you suggest an efficient way to count agents too? (Maybe vehicles|isAgent?) Thanks ...

I started to focus on values impacting the script interpreter performance in a direct manner. I think there is a lot potential to show something more from inside the server. The only limit seems to be, the performance impact of the fetching commands itself. Minimizing this impact, will still have highest priority in this project. For counting players and AI, i simple used the "allUnits" and filtered the result by "isPlayer". Not sure what you mean with "Agent"?

I am talking just about ArmaServerMonitor-client running on device where the admin is sitting (playing or doing something else) and ArmaServerMonitor-server running on device where arma3server.exe is running too. ASM-client is polling the data from ASM-server via UDP. Both ASM-server and ASM-client are able to display the data!

@Terox, related to the remote viewing capability of ASM: I have the following idea for a "pure man" solution (UDP): Given ASM a start param to configure it ether as server (on the device where arma server is) or client (on the device of remote admin). Client and server will need two additional start params, ip and port from server ASM. Then let the client, if connected to server, poll the current data from the server ASM periodical and display it for the remote admin. Do you think this is a useful solution for the common arma server admin?

... AFAIK, this data are not available per .sqf (directly or indirectly), or i am wrong? It should be generally possible to get the bandwidth per process (Total), via windows ressource monitor api. Not sure, but i think so.

just this, one per instance, updated one per second: struct ARMA_SERVER_INFO { DWORD PID; DWORD TID; DWORD PLAYER_COUNT; DWORD AI_COUNT; FLOAT SERVER_FPS; FLOAT FSM_CE_FREQ; char MISSION[64]; }; Are you able to interface this to a web page? I could give you the source of the .dll if you like (just a few lines). The best is: There is currently no worker thread implemented, you could add one, as usual :)

... congratulation, your first really self made thread ..., (remembering the nice feeling, when the fresh thread starts to say "... papa ..." :) Mutex is a relative slow thread synchronization function. If you have fun with optimizing, look for InterlockedIncrement/Decrement/ExChange. You could use it to safely modifying two array indices (pointing to your array of strings fields, one for reading from and one for writing to array of string). But 0.23s for 100000 callextensions is already very, very fast :)

Thanks for reporting and ideas. AI counting is fixed now (i used playableUnits, instead of allUnits in fn_ASM.fsm). So all you have to do for update, is replacing the ASM.pbo file. But i am not able to reproduce the other aberration (starting fn_ASM.fsm twice on your system). So i simple added a check to the fsm init, to avoid an second start. Making this monitor a web service is a good idea and i will think about this later (currently it is beyond my "arma time window").

Thanks for your answer. ... like me :) ... i did my best to consider the specific behavior of .fsm, by using diag_tickTime as reference and just counting everything in global vars (see the attached FSM). By using large time intervals (10sec) i got very precise averaged results. But i got no info about the distribution inside the simulation frame, right. ... this is the info i was searching for! A fixed time slice of 3ms. That explains something. I think i generally understand the reason for limiting the scheduler, but i guess it cant be optimal to do it in this inflexible manner (a fixed time window). The first obviously disadvantage of this simple solution is that the scheduled part of script processing is not using the whole potential in low load situations (less players, less events). There is time left in the standard 20ms frame (on server) which could be used for scheduled processing if nessecary. The second more important obviously disadvantage is the discrimination of scheduled processing in high load situations. Here the length of simulation frame is extended (e.g. 100ms for 10FPS) and the scheduler VM gets still only 3ms. In result we see sometimes heavy delayed AI even at 50FPS and the whole scheduled part tends to accumulate schripts in high load situations, where the timing will be streched at all. Is it possible for you to ask the responsible developer(s) my question for optimizing this? Thanks ... EDIT: An possible first idea improvement could be the following: Lets introduce a new sqf command like setSchedulerRatio( ), where the argument is the ratio of SCHEDULER_TIME_WINDOW/CURRENT_FRAME_LENGTH expressed in percent and in the range from 10 to 90. That way, mission developer could optimize this value for a specific mission or better adapting it dynamical ingame dependent of current load. I am sure the community will find very soon an optimal algorithm to adapt this value dynamical. At this point this algorithm could be implemented in the engine and the setSchedulerRatio( ) command is no longer nessecary.

... ok i decided to make a new thread to be not to much off topic ... this was the original thread started by killzone_kid: http://forums.bistudio.com/showthread.php?156402-callExtension-can-cripple-main-process-even-if-spawned/page2 @Deadfast, thanks for clarification, that is what i assumed. I did some performance "research" with the current script interpreter. My intention was, to find "the rules" how to optimize .sqf code. This way i found some "strange" behavoirs of the script interpreter. Especially the scheduled part seems to be not optimal and i think there is a lot of potential to accelerate the processing by adapting it to the current load situation. The following is the output of a .fsm, specialized to measure the throughput of the script interpreter (non scheduled, scheduled and condition evaluation in .fsm): "_FCEF_Logger.fsm started" "Non Scheduled Frequence Calibration 960225 Statements/sec" "Scripts = Num of scripts; SSF = Spec Sched Freq [statements/sec]; FCEF: FSM Cond Eval Freq [Conditions/sec]" "Scripts: 1 SSF: 135259 S/s FCEF: 50.085 C/s Ratio: 2700.58 TimeDiff: 10.003 s" "Scripts: 2 SSF: 68786.6 S/s FCEF: 16.8226 C/s Ratio: 4088.94 TimeDiff: 10.046 s" "Scripts: 3 SSF: 45486.6 S/s FCEF: 14.0438 C/s Ratio: 3238.91 TimeDiff: 10.04 s" "Scripts: 4 SSF: 34449.4 S/s FCEF: 11.3309 C/s Ratio: 3040.31 TimeDiff: 10.061 s" "Scripts: 5 SSF: 27301.4 S/s FCEF: 9.20792 C/s Ratio: 2964.99 TimeDiff: 10.1 s" "Scripts: 6 SSF: 22401.1 S/s FCEF: 7.62376 C/s Ratio: 2938.33 TimeDiff: 10.1 s" "Scripts: 7 SSF: 19569.7 S/s FCEF: 6.73201 C/s Ratio: 2906.96 TimeDiff: 10.101 s" "Scripts: 8 SSF: 17080.7 S/s FCEF: 5.87649 C/s Ratio: 2906.61 TimeDiff: 10.04 s" "Scripts: 9 SSF: 15256.5 S/s FCEF: 5.26786 C/s Ratio: 2896.15 TimeDiff: 10.061 s" "Scripts: 10 SSF: 13651.1 S/s FCEF: 4.76191 C/s Ratio: 2866.74 TimeDiff: 10.08 s" ... "Scripts: 20 SSF: 6683.51 S/s FCEF: 2.40848 C/s Ratio: 2775 TimeDiff: 10.38 s" ... "Scripts: 30 SSF: 4619.26 S/s FCEF: 1.6441 C/s Ratio: 2809.6 TimeDiff: 10.34 s" ... "Scripts: 40 SSF: 3447.2 S/s FCEF: 1.24521 C/s Ratio: 2768.36 TimeDiff: 10.44 s" ... "Scripts: 50 SSF: 2754.6 S/s FCEF: 0.998002 C/s Ratio: 2760.12 TimeDiff: 10.02 s" ... "Scripts: 60 SSF: 2321.39 S/s FCEF: 0.831792 C/s Ratio: 2790.83 TimeDiff: 10.82 s" ... "Scripts: 70 SSF: 1969.84 S/s FCEF: 0.710479 C/s Ratio: 2772.55 TimeDiff: 11.26 s" ... "Scripts: 80 SSF: 1714.68 S/s FCEF: 0.624999 C/s Ratio: 2743.49 TimeDiff: 11.2 s" ... ... as you can see at the top of the log, the interpreter is able to process ~1 Million simple statements per second (non scheduled on dedicated server) at a 4.00GHz CPU. The scheduled processing seems to be limited to ~ 135000 simple statements per second. This are only 13.5% of what is theoretical possible. The condition evaluations per second are degraded at the same scale like the scheduled statements per second (AI seems to be stupid, because of delayed condition evaluation) even at 50 server FPS. This is measured at constant 50 FPS without any non scheduled load in an empty mission with only one client connected! At the surface this scenario seems to be synthetical or constructed, but it isnt that simple. The scheduler, as it currently works, tends to accumulate scripts and as a result scheduled script processing can significantly slow down (FSM condition evaluation too)! My question is: Couldnt this be optimized a bit? For example by making the scheduler frequence dynamical adapted to current load? Here is my specialized .fsm for reproducing my experience: /*%FSM<COMPILE "scriptedFSM.cfg, FCEF_Logger">*/ /*%FSM<HEAD>*/ /* item0[] = {"reset",2,250,-75.000000,-350.000000,25.000000,-300.000000,0.000000,"reset"}; item1[] = {"measure",4,218,-75.000000,-275.000000,25.000000,-225.000000,0.000000,"measure"}; item2[] = {"init",0,250,-75.000000,-500.000000,25.000000,-450.000000,0.000000,"init"}; item3[] = {"settle",4,218,-75.000000,-425.000000,25.000000,-375.000000,0.000000,"settle"}; item4[] = {"spawn",2,4346,-200.000000,-350.000000,-100.000000,-300.000000,0.000000,"spawn"}; link0[] = {0,1}; link1[] = {1,4}; link2[] = {2,3}; link3[] = {3,0}; link4[] = {4,3}; globals[] = {25.000000,1,0,0,0,640,480,1,12,6316128,1,-252.080170,80.852798,-120.290154,-595.128967,671,957,1}; window[] = {2,-1,-1,-32000,-32000,880,88,1528,88,3,688}; *//*%FSM</HEAD>*/ class FSM { fsmName = "FCEF_Logger"; class States { /*%FSM<STATE "reset">*/ class reset { name = "reset"; init = /*%FSM<STATEINIT""">*/"_i = 0;" \n "SchedCount = 0;" \n "_startTime = diag_tickTime;" \n "_NextLogTime = _startTime + _MinLogInterval;" \n ""/*%FSM</STATEINIT""">*/; precondition = /*%FSM<STATEPRECONDITION""">*/"_i = _i + 1;" \n ""/*%FSM</STATEPRECONDITION""">*/; class Links { /*%FSM<LINK "measure">*/ class measure { priority = 0.000000; to="spawn"; precondition = /*%FSM<CONDPRECONDITION""">*/""/*%FSM</CONDPRECONDITION""">*/; condition=/*%FSM<CONDITION""">*/"(diag_tickTime >= _NextLogTime);"/*%FSM</CONDITION""">*/; action=/*%FSM<ACTION""">*/"_TimeSec = diag_tickTime - _startTime;" \n "_SchedCountLoc = SchedCount;" \n "_FSMConditionFrequence = _i / _TimeSec;" \n "_SchedulerFrequence = _SchedCountLoc / SchedScriptsCount / _TimeSec;" \n "diag_log format[""Scripts: %3 SSF: %1 S/s FCEF: %2 C/s Ratio: %4 TimeDiff: %5 s"", _SchedulerFrequence, _FSMConditionFrequence, SchedScriptsCount, _SchedulerFrequence / _FSMConditionFrequence, _TimeSec];" \n ""/*%FSM</ACTION""">*/; }; /*%FSM</LINK>*/ }; }; /*%FSM</STATE>*/ /*%FSM<STATE "init">*/ class init { name = "init"; init = /*%FSM<STATEINIT""">*/"diag_log (""_FCEF_Logger.fsm started"");" \n "//Number of LoadFSM.fsm instances to use" \n "NumberOfLoadFSM = 256;" \n "LoadFSMCount = 0;" \n "LoadFSMStatArray = [];" \n "LoadFSMStatArray resize NumberOfLoadFSM + 1;" \n "" \n "// number of scripts currently SPAWNED (scheduled execution)" \n "SchedScriptsCount = 0;" \n "// counter for counting the ""scheduler rounds"" " \n "SchedCount = 0;" \n "" \n "// globale variable for incrementing inside the generic test schripts" \n "globalVar = 0;" \n "" \n "// local copy of the global ""SchedCount""" \n "_SchedCountLoc = SchedCount;" \n "" \n "// define the minimal time interval in seconds to avoid flooding the log file at low load" \n "_MinLogInterval = 10;" \n "" \n "// result variable for the statements per second calculation" \n "_SchedulerFrequence = 0;" \n "// result variable for the FSM conditions per second calculation" \n "_FSMConditionFrequence = 0;" \n "" \n "// result variable to store result from time difference calculation" \n "_TimeSec = 0;" \n "// variable for counting the number of condition evaluations" \n "_i = 0;" \n "" \n "// additional running simple FSMs with 8 conditions each just to test the impact" \n "for ""_j"" from 1 to NumberOfLoadFSM do {" \n " [_j] execFSM(""loadFSM.fsm"");" \n "};" \n "" \n "// measure the speed of non scheduled script execution to have a reference, 4096*64 globalVar increments" \n "_calibrateStart = diag_Ticktime;" \n "for ""_x"" from 1 to 4096 do {" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n "};" \n "_FullSpeedFrequence = 4096 * 64 / (diag_Ticktime -_calibrateStart);" \n "diag_log format[""Non Scheduled Frequence Calibration %1 Statements/sec"", _FullSpeedFrequence];" \n "" \n "// scheduled reference load for measure the scheduler period, 64 identic statements to reduce the impact from the while statement it self" \n "SchedLoad = {" \n " SchedScriptsCount = SchedScriptsCount + 1;" \n " while {true} do {" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " SchedCount = SchedCount + 1;" \n " };" \n "};" \n "" \n "SchedScriptsCountBefore = SchedScriptsCount;" \n "SchedCount = 0;" \n "[] spawn SchedLoad;" \n "" \n "diag_log (""Scripts = Num of scripts; SSF = Spec Sched Freq [statements/sec]; FCEF: FSM Cond Eval Freq [Conditions/sec]"");" \n "" \n ""/*%FSM</STATEINIT""">*/; precondition = /*%FSM<STATEPRECONDITION""">*/""/*%FSM</STATEPRECONDITION""">*/; class Links { /*%FSM<LINK "settle">*/ class settle { priority = 0.000000; to="reset"; precondition = /*%FSM<CONDPRECONDITION""">*/""/*%FSM</CONDPRECONDITION""">*/; condition=/*%FSM<CONDITION""">*/"// waiting for the spawned reference script" \n "( SchedScriptsCount > SchedScriptsCountBefore) "/*%FSM</CONDITION""">*/; action=/*%FSM<ACTION""">*/""/*%FSM</ACTION""">*/; }; /*%FSM</LINK>*/ }; }; /*%FSM</STATE>*/ /*%FSM<STATE "spawn">*/ class spawn { name = "spawn"; init = /*%FSM<STATEINIT""">*/"SchedScriptsCountBefore = SchedScriptsCount;" \n "[] spawn SchedLoad;" \n ""/*%FSM</STATEINIT""">*/; precondition = /*%FSM<STATEPRECONDITION""">*/"_i = _i + 1;" \n ""/*%FSM</STATEPRECONDITION""">*/; class Links { /*%FSM<LINK "settle">*/ class settle { priority = 0.000000; to="reset"; precondition = /*%FSM<CONDPRECONDITION""">*/""/*%FSM</CONDPRECONDITION""">*/; condition=/*%FSM<CONDITION""">*/"// waiting for the spawned reference script" \n "( SchedScriptsCount > SchedScriptsCountBefore) "/*%FSM</CONDITION""">*/; action=/*%FSM<ACTION""">*/""/*%FSM</ACTION""">*/; }; /*%FSM</LINK>*/ }; }; /*%FSM</STATE>*/ }; initState="init"; finalStates[] = { }; }; /*%FSM</COMPILE>*/ Thanks :)

@Deadfast, thanks for clarification. I have opened a partly related thread: http://forums.bistudio.com/showthread.php?156542-optimization-for-script-interpreter-possible Maybe you are the right man to answer my question best :)