Jump to content
Sign in to follow this  
CTI player IF

TZK CTI MOD/MPMissions (ver 2.12 v03)

Recommended Posts

Hello everyone. This is a mod and missions about CTI, naming TZK, which is developed basing on crCTI of XR missions, the irparaZ-@RES2C3C8. The XR missions is good in independence and rarely relying on mod, however the "addAction" and "addEventHandler" are insufficient due to their lacking of functionality. UserActions at least have radius and condition parameter although it doesn't pass the "caller".

There're many designs in mission setting recommend to experience. Many European players complained that in TZK missions AA are too strong (Chinese players are mostly opposite, they think plane too strong), and many players wish to play vanilla CTI without extra mod. The author has decoupled mostly EventHandlers and scripts with the mod, and editors can try by themselves to transplant TZK designs into their own CTI MPMissions. However, the author still remain many UserActions in TZK mod, since UserActions have radius and condition parameters, which are better than "addAction". This should be handled by editors when transplanting. Besides, since TZK MPMissions applied 2.01 Arma Resistance by [4RTech], many settings require new engine and don't fit 1.99 ACWA.

2.01 Arma Resistance by [4RTech] is useful for CTI. Details will be introduced in the future, posted below when the author have free time.




Stable TZK_2.10&2.12:

TZK_2.10 MOD (Backup link)

TZK_2.12 Patch

TZK_2.12 MPMissions(Require @TZK_2.10 and @TZK_2.12 MOD, beside with  2.01 Arma Resistance)


TZK_3 not stable yet and not recommend to download (actually, failed agaiin. Probably because of MOD setting):

TZK_3.00 MOD

TZK_3.01 MOD (Use with TZK_3.00. Make sure TZK_3.01 is BEHIND the TZK_3.00, i.e., in format "@TZK_3.00;@TZK_3.01...")

TZK_3.01 missions. Keep on updating missions to fix some bugs.

Project TZK on github.


There is strange phenomenon since TZK_2.10, i.e. the dedicated server process "no-response". TZK_2.10, 3.00 and 3.01 are failure since they can't get rid of this phenomenon. This problem hasn't been resolved completely yet in latest TZK_2.12, luckly it seldom happens when few game player and haven't occured when many players.

  • Like 1

Share this post

Link to post
Share on other sites

Server FPS:


It would be good if server FPS always more than 30. However in TZK (not verified in other CTI yet. The author know the "#monitor" command for only few days), the server FPS will reduce with the increase of players. In TZK mission, a game with only 1 player, full 8 groups AI tanks, full enemy AI 18 group tanks and full resistance patrol groups still has about 36-38 FPS. However, when about 10 players, server FPS will reduce to about 15-20, and 12-15 with 12 players, 6-8 with 17 players (once).

Several attempts are made, trying to find out what the problem is, and to optimize it. List below, and keep on updating.



Aiming to reduce server burden and make scripts easier to be upgraded (by updating MPMissions but not MOD), most EventHandlers are decoupled with MOD.

This project started in 2.12R (3 version behind v00).

Init: This EventHandler can be used to broadcast something, and thus remained in MOD. They're well designed, set to execute scripts mostly deployed in missions. This EH probably don't related to server FPS.

Fired: This EventHandler in TZK_2.12 applying 2.01 Arma Resistance is used for limiting the weapon range of vehicles of player group, and for global (in MP) tracer effect. This EH is only added on players clients but not server. However since Fired EH is global, it might related to server FPS. But the global effect require this EH thus it won't be modified.

IncomingMissile: Although this EventHandler is "global", it won't be triggered by a rocket/missile if IncomingMissile EH isn't added on the client of the rocket. Thus this EH must be added to dedicated server, or IncomingMissile EH attaching on players' vehicles won't be activated by rocket/missile shot from server units (i.e., mostly AI).

Other EH added in MPMission designed in XR: They're totally remained.

Towns' Spawn/Hibernate


In previous designs, the server will check all units' position to decide whether a town should hibernate or not. Is it possible that reading remote units (of players' clients) cause server FPS reducing?

The author modify the design. Server now will only check server local units (of AI groups). Players will check their members, and send message (by publicVariable) if his member are closed enough to some towns.

This project started in 2.12T (1 version behind v00).

The "find" command and SQF


According to @krzychuzokecia, and introduction of Scheduler, the author think it necessary to reduce the use of SQF. Besides, in 1.96 there is no "find" command and must use a SQF to search for array element, but since 1.99 "find" is available.

This project started on the beginning of 2.12. Recently in 2.12 v03 SQF of AddRearmData and EditRearmData are removed, and the use of GetRearmData.sqf and GetUnitTypeFromObject.sqf is reduced on server. Besides, the script of resistance patrol group uses mostly SQS syntax as well.

Up till 2.12 v03 attempts above are all failed to solve the problem. They seems even have no little improvements. Server FPS is always about 40 (highest level of our TZK server) on the beginning, and keep on reducing up till it reaches a stable value, which is related to the number of players.

Next plan is to analysis the "GetClosestStructure.sqf“, which is widely used by AI units to ask them attack enemy base. To be honest the author has little hope now.

No-response Server:


Groups ID


In 2.01 Arma Resistance the createGroup command is available. Missions applied this command cause no-response server.

The problem probably because of different group ID in MP game. The effect of "setGroupID" seems to be local, according to BIKI. In TZK scripts groups placed in mission.sqm will be initialized frist, then playable groups' ID will be set by "setGroupID" in init.sqs. Probably "createGroup" command should strictly be executed behind Init.sqs, that is, better after game has started.

The command "createGroup" don't have such "Init" parameter as createUnit. However the order groupID be used by groups should follow a fixed rule defined in OFP. It's possible in this way to get new groups' ID without applying "publicVariable" but by calling strings pre-defined in the way groupID being used.

Objects' id in mission.sqm


It seems unacceptable to set multi groups/vehicles sharing same ID in mission.sqm. This setting probably caused no-response server as well.

Discontinuous ID is acceptable, i.e., some number can be jumped without being used by any groups/vehicles. Actually those playable roles being closed in MP game are deleted, and surely will cause ID discontinuous.

Unknown Problem of 2.10 mission and 2.12 missions now


Settings above aren't included in 2.10 missions. Thus there must exists other problem sources. Remain unspotted.

As mentioned above, 2.12 missions now have same problem. This phenomenon used to disappear in 2.12H~N, which are relying on @TZK_2.10 only, without having upgraded to @TZK_2.12. Thus probably the problem is of the mod, however problem of 2.10 mission isn't found as well.


An important discovering, or I'm ignorant, is that SQS scripts keep on looping may lag the game.

Having been looking for reasons causing "no-response" server for months, with taking the server FPS as an important indicator, I finally realized the possibility that problems might be caused by cycling scripts. I tested in CTI, first close all west/east groups but remain resistance patrol tank groups and town groups, then did nothing but only observed the server FPS. FPS is 59 in the beginning 20 minutes, then reduce to about 35. Second I adjust scripts of res patrol groups, making them not to loop but pass status to a new script and terminate this being executed one. Surprisingly the server FPS kept at 59 for long.

The reason to this phenomenon might be that some local variables aren't totally released until the script ends.
Cycling scripts are widely used in crCTI design, at least since XR version, and XR missions sometimes (if not often) crashed server. This is not the only reason reducing server FPS, since in other games that many scripts were adjusted in this way and west/east groups were opened the server FPS can't hold 59. It probably isn't the only reason causing no-response server either, since the design existed in XR mission but no-response server problem didn't. However, at least by this method players' dragging map by mouse and spectator's moving camera are smoother.

  • Thanks 1

Share this post

Link to post
Share on other sites

Factory Type:


crCTI use unitDefs matrix to define available units in mission. Each unit is stored as an array, recording its "display name in buy list", "available side", "price", "factory type", "class name in CONFIG", etc. The udFactoryType is a constant of the index of the "factory type" element.

In previous designs, the factory type is related to supplying scripts (to judge whether the unit is an aircraft, and thus control air's behaviour when supplying), attach (only allow trucks and helicopters to attach units built from Light Factory. No limits to Ambulance APC) and displaying in buy list. If wish to design an object supported by different factories, they must be defined many times for different factory type.

New designs in TZK use binary system to store the factory type, i.e., 2^(type of light factory) + 2^(type of heavy factory). Scripts will decode them when necessary (LOG command is powerful here, but it might lost accuracy and need rounding). In new design, a unit allowed to be created by multi factories need to be defined only once.

This project started in 2.12S (2 version behind v00).



As mentioned above, previous design of attach requiring units' factory type.

2.01 Arma Resistance support a new command "getMass", and new design using mass to check whether an object is attach-able for some tug.

This project started in 2.12S (2 version behind v00).

Share this post

Link to post
Share on other sites

Shooting Target Command:


The history of artillery support in OFP probably as long as the history of OFP itself. However, for playfulness and balance, the author opposite shell created via scripts and insist that shell must be shot by vehicles directly.

This project started in 2.12 v03.

It's not hard to "camCreate" invisible HeliH (the "HeliHEmpty" in CONFIG") to guide AI's shooting. But if wish to design it better, those obstructing because of OFP's imperfect must be faced or got avoid.

  1. "fire" command for soldier. This command is invalid for soldier since they'll always aiming up immediately, before they fire their weapon. The author thus gived up the command supporting to mortar soldiers.
  2. Inaccurate trajectory computation on distant target. This design using simple first-"doTarget"-then-"fire", but for distant target (or low initSpeed weapon) the trajectory given by game engine is inaccurate and the shell thus will certainly missed when distance far.

Problems above can be totally solved by one who can calculate accurate trajectory in OFP. However this is beyond the author's ability limit.

Marker Displaying:


In previous designs the main part of marker displaying script using SQS syntax. The period is 0.5 second however the time executing codes cost another 0.5 seconds.

In TZK the main part reading units' position and setting markers' position is processed by SQF. Enemy vehicles' marker (mostly are aircrafts detected by air-radar) requiring calculate radars first and checking distance then, thus they're using SQS with a 1 second delay. TZK added structures' marker displaying as well. Since strutures are unable to move, they don't have to be refreshed in high frequency. The period is 30 seconds for them, and only check whether they're null or not.

This project started in 2.12 v00.


  • Confused 1

Share this post

Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
Sign in to follow this