Jump to content

CTI player IF

Member
  • Content Count

    14
  • Joined

  • Last visited

  • Medals

Community Reputation

3 Neutral

About CTI player IF

  • Rank
    Private First Class

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. CTI player IF

    TZK_3.00 CTI MOD/Missions

    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". The TZK mod modified many settings, and the TZK_3.00 applying 2.01 to gain some improvements. One may read the PDF for more details. TZK_3.00 MOD TZK_3.00 missions. Keep on updating missions to fix some bugs.
  2. CTI player IF

    OFP Materials

    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.
  3. CTI player IF

    Grades in CfgWeapons

    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.
  4. CTI player IF

    Grades in CfgWeapons

    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.
  5. 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”}, 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. A weapon can have multiple muzzles, defined in muzzles[]. Default value is {”this”}, meaning it using itself as its unique muzzle. 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[]. Default value is {”this”}, meaning it using itself as its unique magazine. 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[]. Default value is {”this”}, meaning it using itself as its unique mode. 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”}, weapon’s parameters also available to its muzzle(s), magazine(s) and mode(s), so be muzzle’s and magazine’s parameters, 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 Magazine 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.
  6. CTI player IF

    Unofficial patch ArmA Resistance 2.01

    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?
  7. 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.
  8. 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.
  9. 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?
  10. CTI player IF

    OFP Materials

    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.
  11. CTI player IF

    OFP Materials

    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.
  12. CTI player IF

    Infantry/Soft/Armored/Air Score in Config

    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
  13. 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?
×