CTI player IF

Latest version 4.0.0 Beta released. Planning to break for few months, and write notes about editing and documents about TZK gradually... Download: New features: Authorship Installation Contact

Plane's taking off/landing (preliminary finding) The way AI landing is by "autopilot" system. Observing how it works on different planes, the authot think the main problem AI fail to land is "turning" during autopilot on. There're few factors known that affect this. Mass distribution The mass distribution defined in Geometry LOD will affect both sensitivity and effect of turning the plane. The sensitivity can be adjust by CONFIG parameter aileronSensitivity, but the effect can't. And the aileronSensitivity can't help autopilot do better when turning the plane. Refer to BIS-Su25, it'll be good to centralize 50%+ mass in the center part of the body. Editor may simply add a box Component in the center and raise its mass. Don't forget to check the position of the centroid. If it's beyond the gear's range, plane can't stand on their gear. CONFIG parameters AFAIK brakeDistance, landingSpeed and noseDownCoef is related. The brakeDistance probably affect the position plane start to turn around to the airport. If set it a small value, plane will turn around at a short distance and can hardly adjust its direction in such distance. Not verified yet, but the name of this parameter seems mean "the position AI start to brake". For plane, it's meaning might be the position start to turn around to the airport. The noseDownCoef seems affect the "nose down" when turning left/right. Don't know why, but this parameter's improper value will fail autopilot landing. Besides, AI planes' will always turn left/right when they've just taknig off. This parameter's improper value will make their flank hit the ground. The landingSpeed will affect autopilot as well. Don't know how it works yet. Keep it same as original plane's definition, namely set it 0, might be a good choice.

I define the sound in addon not in mission. My scripts for reference:

But vehicle without any crew can say sounds defined in CfgSounds...

I've managed to complete that (phisical) artillery module in CTI. A video for displaying.

animationPhase If the command animationPhase applied (e.g. for UserActions), it's necessary to define the animate-corresponding selections in all resolution LOD and view - crew LOD. Otherwise, the animationPhase command won't return changed value if player is in that LOD (e.g. no selection in view - crew LOD will cause inner seat can never get changed animationPhase in 1st-view. But if the selection is defined in the 1st resolution LOD, the moment player get off the vehicle or activate 3rd/tactic view will lead toanimationPhase's change and obtain correct value). The selection don't have to include any faces/vertices, but it must be defined in LOD's. Besides, the animationPhase won't return changed value for vehicle out of sight, no matter whether the last resolution LOD has defined corresponding selection. And we might conclude from phenomenons above that animationPhase is related to player's view (and camera, if switched) but not any of its members. (Update on June 14, 2020) The animationPhase won't return changed value, if player isn't facing the vehicle, even though distance is only few meters.

Memory (general settings) Only list some general, separated settings here. Those complex, systematic topics won't be contained in this floor. pos driver/gunner/commander/cargo zarmeny

Hit Points LOD, Hit-Class and Vehicle's Armor By now I've explored about simulation tank only. Total Armor Selection Damage Besides, the meaning of passThrough parameter in Hit-class remain unknown. I tested it in many cases including when exploring topics mentioned above, but unable to conclude something. This parameter can't be removed as "armor..." of tanks, but don't know how does it effect. A might-be relative phenomenon is the damage of tank given immediately by Hit-EH is different from the value given with a delay.

Lights(svetlo) The front "svetlo" (can be switched by button "L") should be defined in both CfgModels and class Reflectors of vehicle's object, otherwise the "shining" vertex won't be hided when lights are closed, and the lighting cone will appear at improper position. Other kinds of "svetlo" require only correctly defined in CfgModels.

Rotation of Commander Turret (otocVelitele)

Multiple Textured Model It'll be interesting if integrating different texture into 1 model. Editor don't have to design multiple models for different vehicles but applying setObjectTexture command. Videos displaying its effect: Selection/hiddenSelections Multi-painting vehicle Alpha Channel Materials Effect Face order/position

Converting It's necessary to convert ODOL into MLOD for editing. And convert MLOD to ODOL can optimize it as well (ODOL support longer texture path for unique AddOn's name, and able to have CfgMaterials effect). Hex Editor Vertex Lighting Property Sharpen Edges Vertices' Lighting and Faces' User

Some simple math here. The l/p raketa/strela in Memory LOD work for aircrafts (depending on vehicle's simulation) only. Proxy of CfgNonAIVehicles available is maverickweapon (maverick of A10 and hellfire of AH64 are using this design), which work for land vehicles, but unfortunately it has fixed direction same as the Vehicle but not the turret (by the way, this is same for l/p raketa/strela). However by directly calculation it's able to design such a function. In this way what the editor has to assign is not selections in Memory LOD of model but formula in scripts of vehicle's Fired-EH. The invariant things is the relative position among launching positions and the turret. Variable is both the 3D direction of vehicle and turret. Let's start our analysis here. The "VectorUp" of vehicle is a vector parallel to the axis of turret (osaVeze), and the direction vector of turret mostly can be regarded as the direction of the projectile (shotBullet, shotShell, shotRocket with nonzero thrustTime and shotMissile within initTme will have a invariant direction), which can be obtained by "VectorDir". These 2 vectors admit an unique direction perpendicular to both of them (obtain it by vector cross), notate it as "vectorH", meaning relative horizontal direction, and then obtain "vectorV" (relative vertical direction) via vectorH and projectile's (turret's) direction. Having know "vectorH" and "vectorV", the script can assign the initial position of projectile by current ammunition. It's seems faster to use setPosASL than setPos according to https://community.bistudio.com/wiki/Code_Optimisation . A video of TOS-1 unit (model is from DKMM mod). Another one of tunguska unit (model is from DKMM mod as well). Its cannon is noticeable. Here is the script for M270 MLRS unit (one can find this model in M29064mm.pbo, or in COC mod, or in latest RCWC 4.9). This design requiring 2.01 ArmA:Resistance for commandsVectorUp and VectorDir. In 1.96/1.99 it'll cost more pre-calculation due to lacking of script commands. The "VectorUp" can be obtained by 3 sensors. 3 points admits a plane, and the "UP" vector can be calculated by these sensors (the "camCreate" is recommended for it's effect is local in network game). As for the projectile's direction, it's velocity vector can be used instead. Besides, 1.96 have to use setPosbut not setPosASL commands.

Introduction Artillery support using rocket as well. The author thus explored the motion equation of rocket in OFP. The simulation "shotRocket" and "shotMissile" sharing same law, as "shotBullet" and "shotShell" do. The guided "shotMissile" has its own ability tracking target, with the help of maneuvrability, but this is out of the author's personal interest and current ability range, and remain to readers. Unless otherwise specified, the "rocket" in the following always includes "shotMissile" as well, but guiding won't be discussed. Totally speaking, parameters initTime, thrustTime, thrust & sideAirFriction are introduced here. Besides maneuvrability, the simulationStep & maxSpeed aren't researched either. To be honest, the author didn't find out how they affect rocket, and they maybe are for "shotMissile", too, because only the AT3, the father class of all guided missile in original CONFIG, has a 0.01 simulationStep . As for maxSpeed , no matter it is 10,000 or only 10, the author didn't observed it limited the rocket's velocity. And those parameters for bullet/shell, i.e., airFriction & coefGravity, and the model file including its shape or mass, will do nothing to rocket. The method the author analysis the air friction is measuring the equilibrium speed in different parameters. At equilibrium the acceleration of air friction is equal to thrust or gravity. Thrust has been verified by @sarogahtyp in https://forums.bohemia.net/forums/topic/189449-solved-simulate-rocket-flight-airfriction-correction-thrust-in-cfgammo-is-equal-to-acceleration/?tab=comments#comment-3001914 that is acceleration as well and in m/s². According to known thrust or gravity as acceleration and measured equilibrium velocity, the author is able to dope out the formula. More narrowly, the author discovered that the ratio acceleration/sideAirFriction gives an unique equilibrium velocity. From fundamental physical knowledge, the air friction should be the function of velocity, and since the ratio acceleration/sideAirFriction decides the equilibrium velocity, the sideAirFriction has been decoupled from the formula: it must be simply a factor in the whole formula, meaning the formula should be here c means sideAirFriction. Then basing on measured ratio a/c and velocity v, and luckily the mapping f is polynomial, the author explicitly gives the expression of f. Again, by the formula, the ODEs of motion can be given. Chapter 1 Motion Equations Previous exploration about ballistic of bullet/shell is recommended to have a look first, if you haven't read it yet. In this article some concepts mentioned there won't be explained in detail. The very first thing to be declare is that there are 2 mode for rocket's flying, depending on whether the rocket ammo (object of class CfgAmmo) has a nonzero thrustTime (yeah, the thrustTime but not the thrust, although the common sense prefer the latter). In spite of rarely being used, the case thrustTime=0 will be introduce first, for it's simpler, and can help readers building basic comprehension. thrustTime = 0 In this case, the mapping f is Here, the v means the the length of velocity vector . The trajectory of rocket in this case is similar to bullet/shell. The main part of air friction is the term 0.001× v², which is just double of shelll's formula (remember? The default airFriction for shell is -0.0005) unless the velocity too high or too low. Analogously, applying RK4 method we can have a numerical solution. (Regrefully, though, the velocity in this mode will be affected by the difference between rocket's velocity and 3D-direction. Numerical solution ignoring this will have error of tens meters. This remain to be solved.) Here list some facts of rocket. They're important and worth knowing. Gravity. As mentioned above, the ratio acceleration/sideAirFriction decides the equilibrium velocity. On the contrary, the equilibrium velocity locally decides an unique acceleration/sideAirFriction. In gravitational direction without thrust, the only acceleration are provided by gravity and air friction. Having measured many different sideAirFriction including 0 (free falling movement), we can gain a more precise gravitational acceleration than 9.8. The fitting value is 9.8066~9.8068. 3D-direction. The direction vector of bullet/shell and rocket with nonzero thrustTime is constant. But for 0 thrustTime rocket, the direction is variable. It'll incline to its current velocity vector, but mostly don't equal to the velocity. The direction here, i.e., for bullet/shell or 0 thrustTime rocket, won't affect the trajectory (for those whose direction too much different from velocity, trajectory will be slightly affect until direction close enough to the velocity vector). But direction is important to nonzero thrustTime rocket and guided missile. The thrust is always parallel to the direction vector, and for guided missile, the change of direction probably is a good (or even unique) indicator of the parameter maneuvrability. The 3D-direction of ammo is equal to the direction of weapon when being shot. In 2.01 ArmA:R the command vectorDir will return the 3D-direction, but no way in 1.99/1.96 to know z-direction. Thus 2.01 ArmA:R is recommended when exploring guided missile. Time to Live. A surprising conclusion is the life time of 0 thrustTime rocket is infinite, until it collide something. This is interesting and can be applyed for long range shoot, better than shell (whose life time is longest but still limited no more than 20 seconds, unless its timeToLive parameter is modified). Initial Velocity. Although the initSpeed is magazines' parameter, it doesn't decide the initial velocity of shot rocket. All rocket shot by weapon have a constant speed 20m/s (or say 72km/h, which is the return value of Speed command in km/h). The elevation of initial velocity is about +2.5° than weapon's (and thus ammo's). This is a special correction for rocket. However it's hard to obtain exactly value, because no way to remove the gravity for rocket like exploring bullet/shell, and thus can't gain unaffected velocity vector. Luckily this won't affect too much since the initial velocity is poor 20m/s and can be ignored when either thrust or thrustTime not too small. As for 0 thrustTime case here, the 20m/s initial velocity without any thrust certainly can't be applied in OFP, and editors must assign another velocity by setVelocity command and thus needn't to concern this unknown correction. The Gravity and 3D-direction here is useful for bullet/shell as well. The author used to thought global tracer effect must rely on 2.01 command setVectorDirAndUp, but this is unnecessary for shell's velocity is independent with the direction. As for Gravity, 9.8 or 9.8066 won't affect the trajectory too much. Even in long range shooting, the calculated distance of these 2 value have no more than 2 meters' difference. The only rocket in original OFP with 0 thrustTime is LGB (and bomb ammo of BISCamel plane's weapon). Common "rocket" don't apply this design. However its infinite life time and shell-similar air friction is good for artillery supporting. Since its initial velocity (and 3D-direction) must be assigned (unless you wish to use the useless 20m/s) and it hasn't thrust period, editor can completely know initial states of the 0 thrustTime rocket, and calculate precise enough trajectory and range via numerical method. thrustTime > 0 This is general case in OFP. It has its own law. Consider a plane spanned by the 3D-direction of the rocket and the direction of gravity. Such a plane is unique, except for when rocket is parallel to gravity, which can be ignored as trivial situation. We claim that the motion is separated into horizontal part and vertical part, and they are independent. As displayed in figure, we call the 3D-direction of rocket "H" and the vertical direction "V". The θ means the elevation of rocket. And there're some other rules: Thrust is parallel to H direction (don't forget direction is constant when thrustTime>0). Gravity should be separated into 2 directions for they're independent. The (air friction in H direction) is still but decided not by the length of any longer but only . The (air friction in V direction) is which is decided by only. And coefficient in this formula is much bigger than ()'s, thus velocity in V direction won't be too high due to large friction. It seems more complex in this case, because we have to devide the motion into 2 directions. But actually the problem is simpler, especially because of the indenpendence between 2 direction. Using rotation matrix we can easily convert between x-y and H-V coordinate. And the indenpendent air friction in 2 directions even allow us solve the ODE because the indefinite integral can be expressed by elementary functions (the integrand is a rational function). However the solution is implicit and what we need explicitly is the (the inverse function) here, which is a non-elementary function (equation is transcendental for ), and we still have to rely on numerical method. (By the way, it is because of f is polynomial that the author can simply obtain its explicit expression with exact coefficients. For more complex f it'll be hard to know what it's expression is, but actually we don't have to. As mentioned in bullet/shell case, the system has a unique solution when A is independent with time. Since we mostly have to use numerical method to calculate the solution, we can get segmental fitted numerical function of f, and apply it in numerical method like RK4. Although the formulas here for rocket in OFP have been built precisely, this view is still useful when exploring something new.) Complete contents is included in a PDF and can be read/downloaded here.

It's necessary to declear that we can't always calculate 0-thrustTime rocket's trajectory ignoring the change of its 3D-direction. One can verify this by himself: adjust the maneuvrability of AA (stringer of soldier) up to 50 and see how it flying to the target. The AA using "LAW" model which don't fit too high maneuvrability, but some other models do. That is, the model will affect the directioin changing. Before the detail about direction changing being analysed, directly applying 0-thrustTime rocket and treat it similar to shell isn't recommended.

Alright. I'm unfamiliar with this mod thus have some misunderstand. Good videos. Very clear in displaying the module. Since the trajectory is calculable now, I'd like to introduce it into CTI. There is a TOS-1 from DKMM mod, and I'm looking for M270 unit for WEST side. All M270 for OFP I can found are two, one is in COC mod, and another very old one looks same as in COC. Both of them are rough, but if I can't get more I'll use them.

I search "MLRS" and find this topic. I wish to know the className of MLRS (or M270) vehicle in this mod. I can't find it in Mission Editor or in CONFIG files.

As a reference, I modified the M2A2 model of OFP:R (in CTI mod), reduce the height of its zamerny. Original zamerny is too high and tanks are easy to miss when shooting at M2A2, especially in moving.

This is invalid, at least for me. is valid. The reason is due to "port number" in my website (like ":8800"). After having removed it all addresses works fine. Thanks to the author.

It's hard for us to design a smart enemy AI in CTI (well someone may try to applying machine learning to train one :-p), thus since XR (i.e., that "irparaZ_RES2C3C8") or earlier version the enemy AI is set having 10 times of money than player. It'll be better not to open too many AI groups if not play CTI for long, and reduce the strength of resistance as well (default is LOW, but players nowadays prefer DOOM). Sites of CR have downed for long. I planned to write some documents about TZK and CTI, but I don't have too many time and vigor. I spent about 10 months to make TZK_2. I just can't stop to develop it in the beginning, and then facing a problem cost me 3 months to catch it. I finally finished Project TZK_2.12 2 weeks ago, and wrote a document of new features. But now I'm interested by the work of @hitman1987 again, and not sure whether I can finish my documents. https://drive.google.com/open?id=14bAdV5EP_MOkW0a1WSyJebLBaJp4JPTn Some simple commanding: MAP Click: CTI use MAP click to call many menus. Most of them can be open by other ways, but the dialog setting CO points (waypoints set by commander for AI groups) must be called in this way. Here list all map click functions. "ALT" and "SHIFT" means you should press them when you clicking. If you play TZK, You might have a look on some old documents I wrote for earlier version TZK_1.01 and TZK_1.10. Some setting options for AI are mentioned and still remained in latest version. https://drive.google.com/open?id=1cSruT9KuX73TDGT1cOu7wMNceSQvQfFY https://drive.google.com/open?id=1CsQk8B2LEL5HqFjbDuuguJSEvSCsJBcW

Hi. I'm the author of TZK mod of CTI. As an author, the reason I choose 2.01 is due to its more script commands' supporting. You may have a look on my topic, I post part of details about how 2.01 raise the mission design there. When you installing the 2.01 patch, select "Move to Res folder (half 1.99 compatibility)" option. This will move your 1.99 files into "RES" folder, which, you might have known, is a default mod for OFPR or ACWA to be loaded on it's start, and thus make you're still able to join 1.99 server after having upgraded to 2.01. The program of 2.01 game, i.e., ArmA Resistance, won't load the RES and use files it placed in BIN/DTA. If you wish to uninstall the 2.01, double click the "ARRemover.exe" set up by 2.01 patch to remove 2.01 and recover your 1.99. The OFPMonitor/ArmAMonitor is good at handling mods. I place mods with the game and use the Monitor to start the game or to join server. As far as I know, the base series of CTI are only MF and CR. Postfix means its mod or related name, as @zulu1 told. I made the TZK basing on crCTI1.0-irparaZ_RES2C3C8, but it'll be too long if I remain "irparaZ_RES2C3C8" in mission's name. I call my whole project "TZK" and use it as the name of MOD/MPMissions. You may have a look about the TZK version on the topic on forum, which can be seen on my signature preference or from the link above.

On this floor I'll introduce how 2.01 ArmA:Resistance improve the TZK design. mission.sqm Text of Leader Markers Creating Markers Town, GameEnd Triggers and Radio Channel Precisely reload the current magazine Precisely gain no empty magazines of a unit Precisely know whether a unit exhausted all available magazines of some weapons Know how many soldiers can a vehicle load Get the mass of a unit Design multiple launching position for a vehicle Obtain texture's path directly from "hiddenSelections[]" array to be continued...

Actually the command setViewDistance is valid in MP and does work in init.sqs. Maybe you should check whether there're other sentences including the setViewDistance, which reset your manual setting.

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 Side createGroup setGroupID animate saveStatus to be continued...

Shooting Target Command: Marker Displaying: