Jump to content

CTI player IF

Member
  • Content Count

    64
  • Joined

  • Last visited

  • Medals

Community Reputation

25 Excellent

About CTI player IF

  • Rank
    Corporal

Recent Profile Visitors

824 profile views
  1. CTI player IF

    Fwatch Request List

    So I still hope if there can be some trick to make OFP load 2 bytes as what CHN agend had done many years ago in version no later than 1.75 using buffer...
  2. CTI player IF

    Fwatch Request List

    I've read your article and watched your video. But the problem is I need OFP recognize 2 bytes to know which character to display since there're thousands of characters. Is that still possible aplying only OFP original fxy design?
  3. CTI player IF

    Fwatch Request List

    I have a request about language for Chinese. Chinese characters need 2 bytes for expression while other languages supported by OFP (except Korean) require simply 1 byte. Common method in dta/fonts doesn't support Chinese. In early version of OFP (no later than 1.75) there's a bug in OFP EXE and Chinese agent used a trick basing on that bug. They manage to load a big texture (15.1MB, 2256x2352) using buffer. That big texture contains all Chinese characters. I wonder whether it's possible to realize similar trick in Fwatch, using buffer trick or something else. Regards, IF
  4. CTI player IF

    TZK CTI MOD/MPMissions

    I don't know. One of our player have this problem too, with his 2.01 none-official. However not any other player meet this problem. I think this may due to server setting or 2.01 features. Maybe you can ask 2.01 programmers.
  5. CTI player IF

    Discover and Identify

    Supplement on 1000 accuracy: The 1000 accuracy is not necessary when applying on non-aircraft vehicle. The reason I use 1000 accuracy is, which is mentioned in the article, that 1000 accuracy can make AI ignore the "model" attribute when deciding whether to use MG to shoot at aircraft or not. When editing a vehicle without considering if it'll be attacked by AI MG, the 1000 accuracy is unnecessary. Besides, the "armor" value play main role in affecting vehicle being attacked by AI with MG. One can verify this by checking the original BIN\CONFIG. The total health point (HP) of a object is decided by the product: (armor * armorStructural). M2staticMG is a unique vehicle with 10 armorStructural . The reason its armorStructural so high probably is aiming to reduce the armor value to make soldiers using rifle to attack it. And players may have noticed that AI sometimes will use MG to attack T55/M60 but never T72/T80. One can test assign T80's armorto 1% (7) and armorStructural to 100 times (200) and see whether AI MG will shoot at T80.
  6. CTI player IF

    Discover and Identify

    An example applying this trick on side attribute. The small MH6 helicopter in video applied this trick. Such a helicopter won't be attacked by tunguska before it get close enough. It's recognized as "civilian vehicle" by tunguska when far away. As a contrast, BIS UH60/Ch47 will be attack immediately at that distance. This helicopter has an abstract base class whose accuracy is 0.3 and side is civilian side, a father class whose accuracy is 3.5 and side west, its class itself is accuracy 1000. It is the father class 3.5 accuracy and base class civilian side that consist of this trick. Such a trick had been applied by BI in the second last mission of "resistance" campaign, using those "fakeC" soldiers.
  7. 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
  8. CTI player IF

    Sights are off

    is the position of "viewGunner" in memory LOD centered with konec/usti hlaven?
  9. 10769 = 1 + 16 + 10*256 + 2*4096 https://community.bistudio.com/wiki/CfgVehicles_Config_Reference#weaponSlots
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. 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.
  15. I define the sound in addon not in mission. My scripts for reference:
×