Jump to content

CTI player IF

  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

21 Excellent

About CTI player IF

  • Rank
    Lance Corporal

Recent Profile Visitors

531 profile views
  1. CTI player IF

    TZK CTI MOD/MPMissions

    Modified (1.99 ACWA) Missions Basing on TZK Design and Linking to Other Mods I once designed missions basing on TZK mission design but using units assigned by crCTI0.93_kaoS@MF mission, which uses mfcti.pbo and modified rmfcti.pbo. Such a project isn't hard but trivial. Main part works are to edit the matrix of units, structures and equipments. Besides, since many players still play 1.99 ACWA but TZK relying on 2.01 ArmA:Resistance, I have to adjust mission design to make these missions able to work in 1.99. A side product of this is some analogue method of 2.01 commands. New script commands of 2.01 are so convenient and useful that I never thought about designing their 1.99 analogue. However in making this version I have to face difficulties downgrading designs applied 2.01 commands. Part of them can find analogues, which might be useful to other 1.99 editors. For example, 2.01 command GetVehicle(Sub)Param(Array) is for obtain parameters of specific vehicle class defined in CONFIG. In 1.99 we can use camCreate to make a temporary vehicle, and camCreate some logic objects then move it into the vehicle, to know whether it hasDriver/Gunner/Commander and how many soldiers it can transport. But this method can't be applied on weapons. It's possible to restore some weapons' data in script in this case. Also, I tried to link TZK design with @totalYugoWar mod. By now there's only 1 mission for trial. MFCTI AddOns TZK_Objects.pbo <- Critical TZK AddOn. Page of totalYugoWar mod on OFP info 2.0 4.0.3 Series TZK MPMissions
  2. CTI player IF

    Sights are off

    is the position of "viewGunner" in memory LOD centered with konec/usti hlaven?
  3. 10769 = 1 + 16 + 10*256 + 2*4096 https://community.bistudio.com/wiki/CfgVehicles_Config_Reference#weaponSlots
  4. CTI player IF

    Ballistic of Bullet/Shell in OFP

    Not verified for bullet, but shell's power won't decrease due to long range shooting.
  5. CTI player IF

    Directly Artillery Module (of shotShell)

    Target Object The target object should have actual model. Game Logic, Trigger and Invisible Heli H don't have model and are thus improper. Self-defined target model should consist of 3 parts: Resolution LOD, Geometry LOD and Memory LOD. In Resolution LOD we can use "data\clear_empty.paa" to make it invisible. In Geometry LOD we can set vertices' z-coordinate few meters less than 0 to make it stay below the land. In memory LOD we can define the "zamerny" selection to make AI aiming it more precisely, but the more important function is the object can be better detected if we define vertices far from the center in Memory LOD, which won't have visible and colliding significance but will make AI spot it much more easier. Another related example is "gun-recoil" animation applied in some tanks of AddOns. In OFP there's no "transparent" but only "rotation" type of animate, thus the "gun-recoil" is realized using long axis whose center is away from model in memory LOD. Such a design will make the tank easier to be detected comparing with BIS tanks. More precisely, these tanks will be detected in the distance few hundreds meters more than BIS tanks. This design applying to target object will make vehicles able to reveal the target within viewDistance. In the out of viewDistance case, it requires other units belonging to same group of vehicles to help spotting the target. And it's important as well to keep the target "alive". In 2.01 ArmA:Resistance one can apply "allowDammage false" command to make it invincible, and in 1.99/1.96 we need to use scrpits keep on set its damage 0. Readers might have noticed that in OFP destroyed objects won't appear in 2-target list, and actually destroyed objects can't provide precise "target" for AI to aiming at. Target Assigning A convenient method assigning target position is via onMapSingleClick. It'll be visible-friendly if prepare some markers as well, in 2.01 the "createMarker" is supported and thus markers can be dynamically created in-game, but in 1.99/1.96 we must place markers in mission.sqm. In my sketchy artillery module the "dispersion" is supported as well. The center position is provided by target object/marker, and a script-local target object is created and place randomly near the center position. Local target's position will change as analogue of "dispersion" and will be removed when script ends. (Fired) Event Handler As introduced in the first floor, the initial data of shell is required, and a corrected data is then calculated and should be applied on the shell to reset its data. As far as I know, the only method catching the shell is the Fired EventHandler. Editor may try to add the EventHandler on the beginning of the script, and remove it in the end. However, in OFP the index of EH dynamically added/removed in-game is clumsy. If we remove No.3 EH, then all EH whose index more than 3 will minus 1, namely EHs can be treated as elements of a Dynamic Array and the index coincide to the element index, which is changeable in-game and will lose control if several scripts execute the "removeEventHandler" command. Thus the EH should better be designed as immediately-discard one, like AT4 launcher. My method is: Use "addEventHandler" to add an empty EH to obtain its return value, the index. Immediately remove the EH. Immediately add actual executing Fired EH whose index is same as just obtained one. Such index is contained in the code of this EH. In the beginning of the EH script the EH will be removed at once. The "fire" command will be executed right after the "addEventHandler" command. Such a design make "removeEventHandler" command appear only in Fired EH script but not main artillery module controlling script. Editor thus don't have to worry about problems caused by plural artillery scripts. However there're still a defect. Although the "fire" is executed right after "addEventHandler" command, vehicle won't shoot in some cases, which still remain possibility of EH index errors. The EH will catch the shell, obtain initial data and do some calculation. Below is its content, for reference. The "RK4_Range.sqf" accept vx, vy and different in height to calculate the range (meters). Fire command The format of this command is <vehicle> fire <muzzle>. This command will work once the vehicle does have assigned muzzle, but it won't "shoot" if it hasn't gunner or the muzzle isn't loaded, and will "shoot" immediately once has gunner and muzzle has loaded. More important, this command isn't cancelable, and if the condition improper on the moment when the code is executed, AI gunner will aim at the minimum elevation until having "shoot". Thus the main artillery script should manage the delay of "fire" command. The reload time is decided by reloadTime of MODE and reloadTimeMagazine of MUZZLE, and is affected by the skill of gunner as well. In 1.96/1.99 we can only assign some constant in script or as global variable defined by mod or mission. In 2.01 it's possible for us to know more about weapon/magazine parameters, but still no commands to know whether a muzzle is "loaded". Maybe such functions have been supported by FWatch, not verified.
  6. In this topic I will display a simple design of Artillery Module. The "directly" in the topic means the artillery support is created by vehicles' directly shooting and the trajectory of shell strictly follows OFP original rule (namely airFriction is -0.0005*v^2 and gravity is 9.80665m/s^2). The "shotShell" in the topic means the CfgAmmo objects applied in this module have same "simulation" value: "shotShell". The (physical) rule (simulated in OFP) of "shotShell" is simple and totally known by now (August 17th, 2020), while rules of "shotRocket" or "shotMissile" are more complex and still remain unknown parts. See for more information. By motion equations one can solve the final range basing on initial data (direction and length of velocity vector and difference in height. The topography should be taken into consider when necessary, remain to readers), but the ODEs don't have elementary function solution, and I failed to build an appriximately one. The problem is "Cauchy Problem", we solve the final data basing on initial ones. And it's hard to solve conversely problem, like that we've known the range and difference in height between shooting position and the being attacked position, it's hard for us to solve the initial velocity, especially when we're still lacking of analysis solution of the ODEs. (Actually we can solve converse problem as an "Cauchy Problem" as well. If we know the final velocity and position, we can take converse velocity as initial velocity, and solve the ODEs whose form is totally same as while the coefficient shoult take "minus airfriction", namely if airFirction is -0.0005, the coefficient in converse problem should be +0.0005. However, mostly the final velocity is unknown. We might wish to solve the initial velocity basing on known range, which, however, provides only position information but not velocity.) I thus applied the numerical method in 2 aspects: 1. Use RK4 (Runge-Kutta-4-order) method to solve the ODEs and obtain final position/velocity. The time step is set as 0.05. This value is accuracy-and-efficiency-balanced one, with few meters' error. If set 0.1 then error will reach more than 10 meters with only half time cost, and set 0.01 can obtain precise result with no more than 1 meter error, but cost 5 times computation. 2. The relationship between elevation difference and range difference is locally linear (see figure below, which is a graduation of a initSpeed 180m/s weapon on elevation 15°~30°), and "Newton method" can thus be applied. Given Proper initSpeed and elevation, one can obtain precise enough range with no more than 4 meters' error by at most 5 iterations. The Proper elevation is provided by OFP vehicles in my Artillery Module. Roughly speaking, I designed a model for "target" object, and ask AI vehicles aiming at it. OFP will provide a predicted elevation when aiming, this elevation is precise only when initSpeed high and distance low, but it's enough as a "initial value" in iterating. The "Newton method" calculates the range basing on this initial elevation, and plus 1° (or -1° , depending on whether the range is less or more than actual distance between the vehicle and target. Mostly the range given by initial elevation is less) then calculates another range. Due to the locally linear relationship, a new elevation can be calculated by these 2 elevations and ranges, following a new range obtained again by RK4, which ends the first iteration. The terminate condition can be either that error no more than a threhold (like 4 meters) or having iterated 5 times (5 times is enough if initSpeed and elevation is proper, at least in OFP for shotShell). The error is defined as the absolute value of difference between iterated range and actual range. 3 videos displaying its effects: See more details below.
  7. CTI player IF

    TZK CTI MOD/MPMissions

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

    Some notes about model editing

    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.
  9. I define the sound in addon not in mission. My scripts for reference:
  10. But vehicle without any crew can say sounds defined in CfgSounds...
  11. I've managed to complete that (phisical) artillery module in CTI. A video for displaying.
  12. CTI player IF

    Some notes about model editing

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

    Some notes about model editing

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

    Some notes about model editing

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

    Some notes about model editing

    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.