Jump to content
Sign in to follow this  
CTI player IF

TZK CTI MOD/MPMissions

Recommended Posts

(Latest version: 2.12 v08)

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 author optimized the design of CTI basing on his personal comprehension about CTI, added many practical functions (e.g. "join" system, which allow players passing their members to other groups) and fixed discovered bugs. Since TZK_2.00, inspired by the "SE" mod of TZK, the author added some units and upgrades. And since TZK_2.12 the 2.01 Arma:Resistance is applied, which allows the author to design some MP-stable visual effects, edit strings, precisely check units ammunition, design radio channel as an enhancement of the action list, etc.

 

There're some designs not widely accept by players. For example, many EU ppls complained that in TZK AA are too strong and the game is "world of tank", but CHN ppls are mostly opposite, they think plane too strong. And many other ppls who don't often play mod-required CTI prefer vanilla game. The author decoupled mostly scripts and EventHandlers in latest 2.12 MPMissions (actually since version 2.12R) and move them into MPMissions, which can reduce the difficulty transplanting TZK design into vanilla game. However, TZK still remain many UserActions, for its radius and condition parameters although it doesn't pass the "caller".

Mostly EventHandlers can be found in "Common\InitVehicle.sqs", and in those "EH" or "Effect" subfolders.

Besides, since TZK 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 very useful for CTI. Details will be posted below when the author have free time.

 

(Actually, if [4RTech] make addAction so functional as listed in BIKI, I'll be glad to decouple UserActions and recover the addAction. The "addAction" and "addEventHandler" is applied well in XR mission, which thus owning good independence and requiring a light MOD. But addAction is really insufficient.)

 

Download:

Spoiler

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)

Spoiler

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.

 

A document of 2.12 new features.

Edited by CTI player IF
Update.
  • Like 1

Share this post


Link to post
Share on other sites

On this floor I'll post something about the "no-response" problem and Server FPS, both of which is basic but important.

No-response Server.

There was 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. Having been bothered by it and all analysing failed, the author experimented many times with "controlling-variable method". Finally the author found the inconspicuous source. Aiming to make AI able to carring enough sniper rifle magazines with a satchel, the author defined a "portable satchel" in this way:

	class PipeBomb_Pistol_xj200: PipeBomb {
		magazineType = 32;
		picture = "\dtaExt\equip\m\m_timebomb.paa";
	};

And the surprising result is all MPMissions with some AI carrying such satchel caused the "no-response" server problem.

This phenomenon is strange. It won't appear when AI carrying "portable mine" defined in same way:

	class Mine_Pistol_xj200: Mine {
		magazineType = 32;
		picture = "\dtaExt\equip\m\m_mine.paa";
	};

The author also tried setting that satchel using "enableAttack = 0;" but useless.

This problem isn't related to 2.01 ArmA:Resistance because it existed since TZK_2.10, which was played on 1.96 game.

 

When exploring the reason causing "no-response" server, the author "summarized" other reasons. Not sure whether they're right nowadays and requiring proof.

Spoiler

Groups ID

Spoiler

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

Spoiler

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 (i.e., the "portable satchel" mentioned above, which isn't spotted when writing these)

Spoiler

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.

 

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 only few days before the date he posts this floor), the server FPS will reduce with the increase of players. In TZK mission, on a cheap CHN cloud server, 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.

Spoiler

EventHandler

Spoiler

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

Spoiler

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

Spoiler

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.

The cycling scripts

Spoiler

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.

 

 

Edited by CTI player IF
Solved the "no-response" problem and update info
  • Thanks 1

Share this post


Link to post
Share on other sites

Factory Type:

Spoiler

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).

Attach:

Spoiler

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
Posted (edited)

Shooting Target Command:

Spoiler

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.

 

(Updated in 2.12 v08) More exploration made by the author and new discoveries raised.

  1. The "HeliHEmpty" is not a good target for this design. AI can't see it (probably because of its simulation and model) and thus can neither aim precisely nor response to the change of its position. The "HeliH" created by "camCreate" command with only local effect should be better.
  2. The "fire" command have problems as mentioned on the next floor. In order to make the command being executed when the muzzle is loaded, the delay must be assigned correctly, and it's necessary to process the situation reloading magazine. The reloadTime and magazineReloadTime should be gain by 2.01 commands, and be applied to make sure the frame "fire" works the muzzle is loaded.
  • Besides, if a vehicle is rearmed in CTI, which remove all magazines and add magazines again when rearm completed, will cost long to reload the magazine, if no one sitting in the gunner seat on the frame its magazines being added (probably the reloadtime in this case is equivalent to a "skill = 0" gunner). This will cause problem as well, especially for mortar structure, in which AI units always killed himself when metting this situation.
  • And TZK thus remove the current magazine when AI starts to execute this order, and soon recover this magazine, to mandatory make the vehicle "reload" the magazine and thus cost only common magazineReloadTime. The 2.01 command applied in this step is introduced on the next two floor.

Marker Displaying:

Spoiler

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.

 

Edited by CTI player IF
Update.
  • Confused 1

Share this post


Link to post
Share on other sites

I will temporarily write some notes about script commands and other notes about OFP (including some 2.01 related commands) here, since BIKI refuse new edit.

fire

Spoiler

The syntax of fire is unit fire muzzle or unit fire [muzzle, mode, magazine]. The fire command is valid if its 2nd parameter (about muzzle) is match the 1st parameter (about unit) in the frame it's executed, i.e., require the unit does have the correct muzzle (with magazine and mode).

However, "actual fire" require more, i.e., the existence of gunner and the loaded magazine. This make the "fire" command sometimes deviate the "actual fire". Furthermore, if the valid "fire" command is executed at the moment unable to "actual fire", the AI will aim down (depends on the "minElev" of that weapon), and when the frame able to "actual fire" comes, AI will shoot immediately, which is possible hurt itself.

This command is Irrevocable. No matther what the editor do in script (e.g. remove magazines from the vehicle or ask the gunner eject), the "actual fire" will occur on the frame all conditions met. A remedy can be a temporary Fired-EH which can catch and remove the bullet, with the EH itself. However the index of EH in OFP isn't well designed, and if other same kind EH is temporary add/removed, this remedy might cause other severer problem. Fatally we can't know whether a muzzle is loading a magazine or not by script commands in OFP.

 

The author designed a "shoot target" design in TZK, which relying on fire command. Aiming to get avoid from those situation which will cause dangerous when applying fire, the author combined some 2.01 commands to prevent them from appearing. See next floor in this topic.

 

Side

Spoiler

Although the return value of side is (displayed by format) "GUER, CIV", etc, we have to use "resistance", "civilian“ to tell right side to OFP.

createGroup

Spoiler

The side command of a group created by createGroup but without any units (and, maybe a group that all groups are removed but group didn't be destroyed. NOT verified yet) will return "unknown". However we can still get its side with the help of 2.01 command substr. The first 4 letters of group's name indicated its side.

Since this command has global effect, we should better only ask server to execute it.

setGroupID

Spoiler

This command has only local effect. CTI use this command to set 18×2 playable groups' ID with "no group color". Since createGroup command lacks "init" parameter, this command should be applied with enough research.

The order of group's ID probably are fixed. It's possible to judge new created groups' ID in this way. However unfortunately we can't use "call" + string to get "group" data. The way broadcast its ID can via the "init" parameter of createUnit command.

 

animate

Spoiler

As BIKI told us, the effect of this command is global.

However there's another limit of this command. In SP game, this command won't effect when the object on which the animation attached is far away from the player. The distance threshold probably be the viewDistance. Some mods use the animation to control a vehicle's statue (like after burner's turning ON/OFF), in these mods the group leader can't control planes belong to him but far away to switch the after burner.

Not sure in MP whether this command effect to different players with different distance.

to be continued...

Share this post


Link to post
Share on other sites
Posted (edited)

On this floor I'll introduce how 2.01 ArmA:Resistance improve the TZK design.

mission.sqm

Spoiler

Editors must place many groups, markers and sensors in mission.sqm in OFP/ACWA. With the help of createGroup, createMarker and createTrigger, they can be dynamic created by scripts in-game and don't have to be pre-defined in mission.sqm any longer.

Take CTI for example. Except for those playable groups, editor must define town groups, patrol groups, some functional groups (e.g. temporary group, join group), markers for displaying (in TZK we need near 2000 markers), and sensors for units near the town flag, for game end and for teleporting of the bridge. With the help of createMarker and createTrigger, those standard functional markers and town/end sensors can be removed from mission.sqm, and only those unique markers (e.g. for town's name) and sensors (for teleporter bridge) require being remained here. Groups, as mentioned above, aren't created dynamic yet. But with the help of allowDammage, editor don't have to find lands to place leaders when transplanting missions. All leaders are set allowDammage false, and hence can be placed in sea.

This surely will make transplanting very simple. One can directly merge existed mission with an island, and only adjust the flagCarriers' name and position, necessary marker and teleporter sensor.

Besides, since 1.99 ACWA we have "isServer" command, and don't need a game-logic to judge whether a game is server or not. Thus TZK remove that logic and place a resistance group instead. This group is for some initialization, and for "center" of resistance side. The center is necessary for createGroup command on every side.

Text of Leader Markers

Spoiler

The new command setMarkerText allow editor to set the text of markers. And thus in TZK we can display players' name on their marker.

Creating Markers

Spoiler

The covering of markers depending on the order in which they're created. Besides, new created marker has the type "empty", which will display nothing including its text. Thus one must assign a type to it, even though you only wish it display text without marker (in this case you should assign the size of the marker [0,0]).

The number of town groups units marker can relying on the number of towns.

TZK also create those "Respawn_west" markers. They're for respawn mode.

Town, GameEnd Triggers and Radio Channel

Spoiler

Town triggers can be created exactly at the position of every flagCarriers.

Since the CTI using a public variable to broadcast "GameOver", GameEnd triggers can be created when client received this variable.

Radio channel is defined by triggers whose "Activation" is between "ALPHA" and "JULIET". Before 2.01 editor can only pre-define at most 10 channels. Since 2.01 support editor edit the triggers in-game, TZK make the radio channel design to partly take place of redundant action list. There's a script "UpdatePlayerVehicle.sqs" activated when player's vehicle changed, and the refresh of radio channel is set here. The radio list is different for different vehicle.

 

Precisely reload the current magazine

Spoiler

The 2.01 ammoArray command will return an array. The array is consist of current magazine name and its ammunition. Since the removeMagazine will remove the current loading magazine, editor can thus know which magazine should be removed.

The 2.01 addMagazinePrecise command allow editor to add a magazine with defined ammunition. This command make editors able to return exactly the removed magazine to the unit.

 

Actually, the returned array of ammoArray will list all modes of current magazine, although the displayed string is still the magazine name but nor modes' name.

Example 1:

<east grenadier> ammoarray "ak74muzzle" will return ["ak74", 30, "ak74", 30, "ak74", 30], corresponding to 3 modes of AK74.

Precisely gain no empty magazines of a unit

Spoiler

Exhausted (but not removed) magazines will remain in the returned array of magazines command. And for those weapons whose "autoReload" = 0 (like soldiers' rifle), remove the empty magazine and add a new one won't make the magazine being loaded, and thus the ammo command will still return "0". This causes indistinguishable situations.

Although exhausted magazines will remain in the 2.01 command magazinesArray command as well, the magazinesArray returns ammunition of each magazines, and thus make editor able to judge whether a magazine is empty.

Precisely know whether a unit exhausted all available magazines of some weapons

Spoiler

An unit has weapons. A weapon equipping muzzles. And a muzzle can reload magazines. That's the idea.

However one'd better develop his comprehension about the relationship among "weapon, muzzle, magazine and mode" first.

The 2.01 command GetWeaponParamArray can be used to gain its muzzles. BUT, if "this" is one of the muzzle, it is actually defined by the weapon class and uses parameters of the weapon class. In other words, that muzzle should be treated as a muzzle whose class is equal to the weapon's.

If a muzzle is defined in the subClass of the weapon, editor should use the 2.01 command GetWeaponSubParamArray to gain magazines of the muzzle. Otherwise editor should still apply GetWeaponParamArray to the muzzle's class (usually this class is just the weapon's) to gain its magazines info. Again if we meet "this" we should know its class is actually the class it belongs to, i.e., can be the subClass of the muzzle or the class of the muzzle (again, usually this class is just the weapon's).

Finally editor gains all available magazines to a weapon. What remain to do is just check whether a unit has not empty magazines available to the weapon. To this end, it require only checking the magazinesArray.

 

Know how many soldiers can a vehicle load

Spoiler

Using GetVehicleParam one can get the value of transportSoldier of a vehicle.

Get the mass of a unit

Spoiler

Using getMsss. The return value is the mass (kg) of its model.

to be continued...

Edited by CTI player IF
Update.

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  

×