CTI player IF

According to BIKI, the IncomingMissile EventHandler is global. (When talking about local/global of EH, we're talking about whether the EH will be triggered on remote vehicles that the EH is assigned to.) However, the author found that this is incomplete. Few days ago in latest CTI MPMissions (ver TZK_2.12 v00) the author add IncomingMissile EH (used for alert) to tanks on all clients but not on dedicated server. The result is surprising that this EH won't be triggered by server-local rockets/missiles. This follows that IncomingMissile EH must be related to client-local rocket/missiles as well. Further tests show that the "command" parameter of addEventHandler about IncomingMissile EH on dedicated server can be empty string, like <a server-remote vehicle> addEventHandler ["IncomingMissile", ""] and the IncomingMissile EH on player clients' can be triggered by server-local rockets/missiles. Thus the conclusion is that although IncomingMissile EH is global, it requires at least an empty EH on remote clients that you wish their rocket/missile trigger this EH. The command of EH can be nothing, but the EH can't be omitted. It would be more clearly if compare with Fired EH. Assume there are 2 clients: call player's client "A", and call a remote client, e.g. dedicated server, "B". On A client Fired EH can be added to all tanks created on "B" to display tracer effect of tanks created by "B". The Fired EH will work for A once any tank of B shoot any bullet. But if A add IncomingMissile EH to B vehicles, the EH won't work if vehicle is attacking by missiles shot from clients except A, unless on the client where missiles are shot from added IncomingMissile EH to that B vehicle as well.

Mr. pSiKO Sorry to bother you. I'm a player of OFP. I find this topic of you by seraching "squad.xml". The "squad" files work for OFP windows server on IE6, but not work for IE11. However win10 nowadays don't allow setup IE6. Thus I come to consult whether there's a way solve this, modify "squad" files to support IE11. My problem has been solved.

Editing config and model still requiring restart OFP, though. Very useful discovering.

Factory Type: Attach:

There is a new command GetWeaponParamArray in 2.01 Arma Resistance by [4RTehch]. With the help of this command (and another command magazinesArray) it's possible to check more precisely whether a unit is out of ammo for a specific weapon. One can gain available magazines first (by picking up magazines with some ammunition from magazinesArray), and check whether some of them are in the magazines[] of that weapon. However not all weapons having a "magazines[]" parameter (e.g. GrenadeLaunchers and other weapons defined in some MODs). But all weapons must have muzzles, and all muzzles must have magazines. Thus one should gain muzzle list by GetWeaponParamArray first, and gain their magazines then. Be cautious, the magazine parameter of muzzle probably reuqiring using GetWeaponSubParamArray, because of most muzzle won't keep its name same as the one which it derived from. More applications can be found in the topic of the author's CTI project.

The author summarized this article when researching the way make Mortar weapons(both for soldiers and as structures) work well. The complete file is PDF. Chapter 1 The grade of Classes in CfgWeapons A class in CfgWeapons(and an available weapon in OFP) owning 4 grades: weapon, muzzle, magazine and mode. In the class Default, muzzles[], magazines[] and modes[] are all defined as {”this”} (which is a special design and will soon be discussed below), thus all subsequent classes, if no overriding the muzzles[] and modes[], will have indistinguishable weapon/muzzle and magazine/mode grade, namely one can hardly distinguish whether it is a weapon or a muzzle, neither do magazine and mode. Futhermore, with the help of scopeWeapon and scopeMagazine, a class can be used as both weapon and magazine, moreover it can use itself as its own magazine. Knowing better about the difference among these 4 grades can help editors making better(well) defined and functional weapons. The best way to learn how these 4 grades being divided is referring to original CONFIG\BIN of OFP. GreandeLaunchers(e.g.M16GrenadeLauncher) show the way defining muzzles[] and basic rifles(e.g.AK74) show the way defining modes[]. But one must be aware not to omit some inheritance, or misunderstandings will emerge. 1.1 Priority Order The priority order is: Weapon ≻ Muzzle ≻ Magazine ≻ Mode. We'll illustrate their relationship and introduce how "this" works. A weapon can have multiple muzzles, defined in muzzles[]. The default value, {"this"}, indicating the weapon's class itself is one of its muzzles (and since there's only one element, this", in the muzzles[], the weapon thus has only one muzzle). For"this" muzzle, all of its properties is gained from the weapon's class. Even though a subClass whose name is same as the weapon's defines a muzzle, it'll be ignored by "this". Very few weapons override this parameter. Pressing spacebar(the default Toggle Weapons key) to switch muzzles. By the way, the {”Throw”} weapon will appear after having scrolled through all muzzles if it has loaded a magazine like handgrenade. A muzzle can load multiple magazines, defined in magazines[]. The default value, {"this"}, indicating the class itself is its specific magazine. The author call attention here that, if the magazines[] is defined under a muzzle's subClass of the weapon, then in this case the {"this"} indicate the muzzle's subClass but not the weapon's class. Many (but not most, at least in CONFIG\BIN) weapons override this parameter. It’s necessary to use the Action List to switch different magazines of same muzzle(e.g.Reload Mortar). A magazine can have multiple modes, defined in modes[]. The default value, {"this"}, work similar as mentioned about muzzles, because there aren't such a definition "muzzle-magazine-mode" like "weapon-muzzle-magazine" does. Many weapons override this to gain various mode(i.e.Single, Burst, FullAuto, etc). Pressing spacebar to switch modes. Muzzles’ switching will happen when having scrolled through all modes of the magazine loading by the muzzle now(one can recall the way M16GrenadeLauncher works). 1.2 Parameters Parameters are mostly available to one of the grades. Because of being defined as {”this”}, parameters for weapon in a class is also available to its muzzle(s), magazine(s) and mode(s), so be parameters for muzzle and magazine, if no overriding. Referring to original CONFIG\BIN of OFP one can clearly know about the grades whom the parameter is working for. Here lists some parameters that are representative or hard to recognize their employer by just reading CONFIG\BIN. 1.2.1 Mode Parameters ammo Although ammo seems to be the parameter to the magazines[], it’s mode’s parameter. Mode inherit ammo from its class via {”this”} if no overriding. A magazine can shoot different bullets They share same ammunition of that magazine. One can learn how different bullets works for multiple modes in one magazine(e.g.AK74). sound[] It is the mode’s sound that decides the shooting sound. 1.2.2 Magazine Parameters InitSpeed Deciding the initial speed of bullet it shoots. count modes[] The modes is magazine’s parameter deciding its modes. Those no override modes classes using themselves as their own mode and some parameters(e.g.ammo and sound mentioned above) are used as mode’s parameters. 1.2.3 Muzzle Parameters aiDispersionCoefX, aiDispersionCoefY Deciding the aiming accuracy requirements. The higher value, the more roughly aiming accuracy will AI shoot at. Big aiDispersionCoef value can be applied for those situation unnecessary to ask AI aiming accurate enough(e.g.artillery support via MG or Shell, or guided missile launcher). reloadMagazineSound The reloadMagazineSound is neither parameter of weapon nor of magazine. Muzzles ofen inherit from existed weapons hence inherit their reloadMagazineSound[], thus in no muzzles of CONFIG\BIN can one see the override of reloadMagazineSound[], however they’ve been defined in those base class. Both M16GrenadeLauncher and Kozlice are good example for this. optics(...) and modelOptics drysound[] magazines[] The magazines is muzzle’s parameter deciding its magazines. Those no override magazines classes using themselves as their own magazine and some parameters are used as magazine’s parameters An example of overriding muzzle’s magazines[] is M16GrenadeLauncher, whose M16Muzzle’s magazines[] isn’t including ”Mortar” thus can’t use Mortar. 1.2.4 Weapon Parameters Those parameters displayed in M16GrenadeLauncher class are weapon parameters. Those Greande Launchers, besides with Kozlice, don’t inherit from the class Default, thus it must defines all necessary parameters not included by muzzles. The muzzles[] is weapon’s parameter and those no override muzzles classes using themselves as their own muzzle and some parameters are used as muzzle’s parameters. 1.2.5 Some General Parameters displayNameMagazine, shortNameMagazine and displayName The displayName is effective to mode, muzzle and weapon. Name shown in the left upper corner are mostly mode’s name. Muzzle’s name will be seen if one drop all magazines of some muzzles(or, using ”removeMagazine(s)” command to remove magazines. Exhausting all bullets will still remain the last magazine in weapon thus won’t effect in this case). As for weapon’s name, it’s shown in the Action List in the bottom right-hand corner(e.g.Drop M21 or M21 on back) or in notebook. The displayName is invalid to magazine. The magazine has its own parameter displayNameMagazine and shortNameMagazine. picture If a class don’t override the picture, namely its picture = ””, then OFP will search picture from DTA\DTAEXT by class’s name, for weapon’s and magazine’s picture shown in notebook. Since fles in DTA is unique, compatibility will be bad if editors customize the DTA\DTAEXT for their weapons in AddOns in their MOD. Thus it’s necessary to override picture for weapon and magazine, and define weapon and magazine respectively, unless you don’t care how their pictures shown in the Gear page of the notebook. Chapter 2 Application on Mortar and GreandeLauncher 2.1 Infantry Mortar The main purpose of this research is trying to solve the infantry Mortar’s problem. AI SELDOM shoot Mortar after player(as group leader) having asked them reload the Mortar and targeted an enemy, and NEVER reload Mortar autonomously. According to the author, there’re two incomplete design of OFP resulting in this. AI will switch weapons, muzzles and modes to respond actual requirements of the battlefeld, but they only won’t select appropriate magazines. However the Mortar is one(but not only one) kind of magazines to M16, M4 and XMS. The way AI use Mortar is in common with tank gun(decided by ammo’s simulation, ”shotShell”. Actually all subsequent class of GrenadeLauncher in original OFP using ammo whose simulation is ”shotShell”), the arc trajectory is owing to low InitSpeed. However the calculation of low-InitSpeed-shell’s trajectory in OFP is inaccurate. For example, M60 is easier to miss the target than M1A1, the former using Shell105 whose InitSpeed is only 900 while the latter using Shell120 with 1500 InitSpeed. And, the InitSpeed of GrenadeLauncher and Mortar is respectively 60 and 70, hence although AI aiming a target, he probably thinking he hasn’t readied to fire; Some players may have noticed that AI will shoot Mortar when lying down or standing up. Here is a hypothetical raised by author, that AI can hardly thinking himself ready to fre, but in the progress he lying down or standing up the position of his muzzle changes continuously, thus there exists a position that the end of trajectory coincide with the target(intermediate value theorem) and AI hence fire. Hence the corresponding solution are respectively making a weapon using the muzzle, not the magazine, to shoot mortar, and reduce the difficulty for AI to be ”Ready to fire”. Simply referring to M16GrenadeLauncher to write a M16MortarLauncher. Define a MortarMuzzle for it, inheriting M16. Set MortarMuzzle’s aiDispersionCoefY = 2(default value for GrenadeLauncher), define another Mortar magazine whose InitSpeed raise to 200 and set it as MortarMuzzle’s magazine. High InitSpeed may cause AI miss the target. But at least they’ll shoot, and the accuracy isn’t so bad. Keep InitSpeed unchanged and raising aiDispersionCoefY only to a big value can let AI shoot mortar too, but the accuracy is terrible. Note: There’s an unknown phenomenon. The Mortar class override its modes[] to {”this”,”this”}. If change modes[] to {”this”}, like the definition in class Default, then AI won’t shoot default OFP Mortar(magazine), and the MortarMuzzle above will crash the game. Raising InitSpeed will make the mortar able to fly far. The range AI will attack is limited by maxRange, a parameter of the ammo, hence unnecessary to worry about that this modifcation will affect the range AI using Mortar. But player surely know how to utilize the high InitSpeed and how to gain those special MortarLauncher from AI. Luckly in 2.01 by [4RTech] there are the createShell and setVectorDirAndUp command. Editor can hence set a Fired-EventHandler on player, detecting the high-InitSpeed-Mortar-Magazine and gaining MortarShell’s position and velocity, then create a MortarShell with classic InitSpeed(70) instead. Here is a videw show the way mortar used by soldiers. Soldiers using M16 muzzle when mission start and will select the Mortar muzzle to attack. They will also use M16 muzzle shooting at enemys alone and not too far away(00:01:01). 2.2 Infantry Greande, Structure Grenade/Mortar Launcher and Vehicle Grenade/Mortar Launcher The maxRange of Grenade is 150, while MortarShell is 450. The way raising AI’s utility of Greande is similar to Mortar while the InitSpeed unnecessary to use 200. In addition, last section only discussed infantry weapons up till now. There exists a Mortar structure used in XR CTI mission and a Grenade structure in TZK SE mission. Structures can’t move or standup /lie down like soldiers do, and it looks like that the aiDispersionCoefY almost meaningless to structures. As a conclusion, the only way for Grenade/Mortar structures is to raise the InitSpeed(verifed), and to adjust corresponding Structures’ Fired-EventHandler and minElev parameter in class Turret. As for vehicles, since they can move freely and their weapons don’t have to perform ”reloadAction” when reloading ammos, probably simply raising aiDispersionCoefY for moveable vehicles would be a better choice, without changing the InitSpeed(not verifed yet! If proved infeasible one may imitate the way how to adjust structures mentioned above). Here is a video show the way mortar used by structure. Not accuracy enough, though, but the shell is actual, not created by script.

Some notes about new script commands: ammoarray magazinesArray Get[Vehicle/Weapon/Ammo](Sub)Param(Array) (Set)Vector[Dir/Up/DirAndUp] And some applications about new commands. They're introduced in form of "applications" but not "commands" thus not list here directly. to be continued...

Aiming to fit the 2.01 Arma Resistance by [4RTech], I modify the OFPMonitor 1.7.4.0 and make the ArmAMonitor 1.7.4.1, supporting 2.01 games start and automation. The program is on github and pulled request.

You may use "setCombatMode" to ask all AA units not to fire, and ask the trigger to "setCombatMode" as well. I think it is impossible to ask AI not to shoot at exactly one units or not in OFP.

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; // The critical modified parameter. // Original PipeBomb use 2x 256 as magazineType occupying 2 slot of primary weapon, while (1x)32 use 1 pistol slot. 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 reason probably due to something hard-coded in "simulation". Mines has defaultMagazine parameter, allow editor assign proper magazine when activate "take/deactivate mine" action, while timebomb/pipebomb hasn't. Another parameter "enableAttack" seems don't relate to this. 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. 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. Alex_Mercer_1479(BI forum ID: @prototype1479) is interested in this. So I'll record some test result here (on my i5-8400 intel CPU. A dedicated server and a game client is hosted). No Town/Patrol groups. AICO will only ask groups' leader to take 1st town. No time limit. Server FPS is 40-45. Turn off units' scripts (while leaders' temporary take 1st town scripts remain working) in last case. Server FPS is 50-60. In most times FPS no less than 55. There're 18x2 groups with full of tanks. So server FPS seems very weak related to units/vehicles number. Turn on units' scripts, but the script contains only the simplest loop without anything else.

Feedback: "data\slgr_1.pac", "data\slgr_2.pac", "data\slgr_opak.pac", "data\slgr_up.pac", "data\slgr_up_vybezek.pac", textures mentioned above are used in GPS. Pressing M with showGPS - true will see a shining GPS. BTW I introduced your work into my CTI mod "TZK" since version 2.00 since July 2019. Great thanks.

The 60 InitSpeed is suitable for GreandeLauncher, within Grenade's maxRange 150 meters. So do HandGrenade. However the 70 for Mortar is awkward, AI can hardly shoot it in close range and can't shoot so far as set in MortarShell's maxRange, which is 450 meters. AI will shot the InitSpeed-60 Mortar when close, but since the InitSpeed is the magazine's parameter, not mode's, editors aren't able to define different Mortar muzzles/modes with different InitSpeed and sharing same magazine.

It's necessary to state modes[] in a muzzle. Elements ofmodes[] in muzzle can be {"this",...}, that is, unnecessary to assign an actual name, and classes of those modes[] isn't required here. However the number of modes[]'s elements in muzzle's statement here must be no more than the elements' number of anyone of its magazines, or game will immediately crash when someone shooting at extra mode. On the other hand, if elements' number of modes[]'s statement in muzzle less than some magazines' modes, extra modes of magazines won't be used by that muzzle. Thus it's necessary to matching muzzles and magazines according to number of modes[]'s elements. It is seems possible for editors to design an “Inferior” muzzle which has less "modes[]" than some of its available magazines. For example, design an muzzle for AK74 magazine but with only 1 element in modes[], then this muzzle can only shoot AK74 single, the burst and full-auto mode are invalid for that muzzle. However a muzzle seems unable to reload a magazine whose modes is more.

The script command about set postion and velocity to vehicles whose simulation is "tank" have bugs in OFP, will they be fixed in further 2.01? And vehicles whose simulation is "car" or "ship" can't shot missiles thus many addons use script to gain virtual missile shot by car/ship. May them allow to shot missile in furhter 2.01?

CfgModels can easily solve the problem that clan, l/p svetlo, zasleh keep showing during the whole game. And defining new sections in CfgModels can activate the "hiddenSelection" to control hiding those sections when unit created and "setObjectTexture" any time necessary (usually activated by EventHandler, UserAction, etc). However after having binarized MLOD-format-P3D, the CfgModels trick lose efficacy meanwhile clan, svetlo and zalash show up, and editor unable to hide sections via hiddenSelection. Is there any solution to this?

Problem solved. Need to add CfgModels info into binarize\bin\Cfgmodels.hpp or config.cpp. A well-defined and inherited class same-name with p3d is recommended.

Alright, it seems that units created after game had started won't have material effects. Using Alt+Tab can reset it but this is not a good solution.

After having made an AddOn, transplant some CfgTextureToMaterial and CfgMaterial to the config.cpp of the AddOn, I found the visual effect works when play SP and MP created by "New" in MULTIPLAYER, but they perform abnormal when playing on dedicated server. Paste the CfgTextureToMaterial and CfgMaterial to BIN\config can't fix this too. Is there any way to solve this problem?

Ahh, I've read the "Readme" file packaged in your addon. So the problem should be the dynamtic spawn. Since Alt+Tab can do sth with this maybe the solution should be searched in DirectX.

Great Job. I have little problem with play this on dedicated server. It'll cost some time then effects will gradually show (not immediately), and it seems that some of effects won't appear during the whole game. This problem widely exist on dedicated server with CfgTextureToMaterial, and I wonder whether author had realised this problem and tried to fix this.

According to BIKI, type = Vsoft/Varmor/Vair means the "threat" type this vehicle to other units. However I can't locate which parameter define this too. Not the model-p3d and armor-value, well