CTI player IF

On starting dedicated server, the message "Dedicated server created" appears but "Server identity created" does not. How to solve this problem?

And use game engine to "new" in MP game it'll display "creating client" for a while then fail too

https://youtu.be/yQo_A2cOIFU

Hello everyone, in this video, I will introduce the RTS style interaction design in my TZK CTI mission, version 4.0.6.33. Old TZK players may recall that TZK enhanced the CRCTI commanding system by extending setting items and introducing a "concurrent order design" that could send orders to a specific unit or type to interrupt their group order and execute concurrent orders. However, this design was non-intuitive and inconvenient. To address this issue, we have referred to the interaction design of RTS games, where units can be selected easily by their position, type, or "group," defined by the player manually and activated by a hotkey. OFP uses a group to manage units, and AI units with a dead leader won't react to any script command until the leader respawns. Traditional CTI applies this as a natural classification of units. It would be useful if the commander could select units by their type or position, but concurrent order could only act on those units belonging to one group. In other words, group, type, and position should be at the same level, but in concurrent order design, the group concept takes priority. The current RTS style interaction design solves this problem by imitating real RTS games. If a unit is ordered by the RTS system, it will obtain a "RTS status" and ignore the group order and execute the RTS order. A unit with "RTS status" will never react to group orders. He'll stop if the order is finished and waiting for the next RTS order, unless the commander explicitly cancels his RTS status. This is similar in RTS games. If a grouped unit is selected by a hotkey and then ordered, he will follow the group unit, but the player can still select the unit and give him new orders. Since traditional OFP uses group order system for commanding, TZK allows units to return to group order if the RTS status is cleared. In the video, we see that clicking on the map twice can determine a rectangle. OFP does not support dragging operations in the map, but we can use clicking. This rectangle is for selection. On the rectangle determined, all units in this rectangle will be marked as "selected." To select units, we press Alt to switch to this clicking mode and click twice. If we select some units, press Alt and Shift, and click on the map, the clicked position will be marked by a flashing marker, and a dialog will appear. This dialog is the core interface in TZK RTS interaction. On the left are "RTS order" buttons. The "Move" button will order units to move to the marker, which is the simplest and most important function in RTS. The "Board" button will order units to move to the marker first, then search for transports and board. When clicked, a submenu will appear for the commander to select the transport type. This submenu is a multiple-choice and sorted descending by priority. Artillery can be much easier to command by RTS order now. There are two buttons: "shoot area" and "move and shoot." The former will ask units to fire in place, and the latter will order units to move to the marker first, then shoot. When clicked, a submenu will appear. The first column determines the types reacting to the order, the second column determines the types using the big angle, and the third column determines the initial speed. With these two orders, it will be very convenient to control artillery. For example, let's define a server art area. Now let's select some art units and order them. As we can see, the selected units are executing art orders now. Howitzers are assigned using a big angle while other types aren't. On the bottom are "RTS trigger" buttons. These buttons will activate immediate behaviors while orders will last long. By now, there are disband, eject, disenmark, and switch transport status. In the future, other immediate behaviors will be added here as well, such as switch tank sabot/heat and turn on/off plane afterburner. On the bottom-left are "type" buttons. These buttons allow you to select specific types in selected units. This area's buttons will refresh if you selected a type or clicked on "return." On the bottom-right are "dialog" buttons. These buttons allow you to switch to other dialogs. There are many new dialogs in the current RTS style interactions: RTS, Area, Point, WayPoint. Different dialogs will appear by default in different cases. If we select some units, the default dialog is RTS. If we draw an area without any selected units, the default dialog is Area. In other cases, the default dialog is Waypoint by now. The commander can switch to other dialogs via these buttons. If we select some units, the RTS dialog is available. If we draw an area, the Area dialog is available. Point and Waypoint dialog is always available since the dialog is activated by map click, and the clicked position thus always exists. So, that was a simple introduction to the RTS dialog. Let's take a closer look at how the Area dialog works. The easiest way to call the Area dialog is to draw an area without selecting any units. In such cases, pressing Alt and Shift and clicking on the map will bring up the Area dialog. The direction of the drawn area can be adjusted using the slider, and you can input the direction value directly as well. This area can be assigned as a server or player art area. Furthermore, two points can uniquely determine a segment, and in the current design, this diagonal is managed in the Area dialog. We can use this segment to order an engineer vehicle, including MHQ, to build obstructions. For instance, let's buy an engineer vehicle and draw a line on the map. Now, call the Area dialog and click on the obstruction button, select the tank trap type, and confirm. The scripts will travel the segment, check whether the current position is close enough to any engineer vehicle, and build the obstruction if all conditions are met. If no engineer vehicles are nearby, the script will skip the current position and continue traveling. The Waypoint dialog is the same as the old one. As for the Point dialog, it can quickly wall off the MHQ, build base defense MGs, and build structures. This dialog is quite simple and does not have any unique features compared to the Waypoint dialog. Perhaps combining these two dialogs into one would be a better choice. This RTS interaction design only requires the 2.01 Arma Resistance engine. The critical script commands used are publicExec, NetworkID, and UnitById. One of the [4RTech] developers once said that these commands are unstable, but practice has proved their stability. With these commands, each client can broadcast locally selected units to the server. In the Cold War Assault engine, we don't have a good method to broadcast many units in a short time. Broadcasting position information may be an alternative. In summary, the RTS style interaction design in TZK CTI mission version 4.0.6.33 improves upon the non-intuitive and inconvenient concurrent order design by introducing the concept of RTS status and imitating the interaction design of RTS games. The core interface includes "RTS order," "RTS trigger," "type," and "dialog" buttons, enabling the commander to easily select and command units in various situations. The selection can be done by position, type, or group, and the RTS order allows for movement, boarding, and artillery commands. The RTS trigger allows for immediate behaviors, and the type and dialog buttons provide additional customization options. Overall, this design enhances the gameplay experience and makes commanding units in TZK CTI mission more efficient and intuitive. That's all for the introduction. I will continue to develop the RTS interaction and the entire TZK project. Players can expect more in the future.

I'm not sure whether Azimut in mission editor really uses a slider but it looks like it does. So how to realize such effect?

About NetworkID In Command Reference.rtf it says this command's return value can be applied in publicExec directly. However this is incompleted. The NetworkID returns an array: [string, number]. The second element is a number which is monotonically increasing. If the server hosts many games this value will become large, and a large number can't be formatted directly by format command (large number will be formatted in form of scientific notation like "1.23e+10"). Script designer shall separate the number into 2 parts, format them and join the string. Besides, since number in OFP is single precision floating-point number, it can express integer precisely only when the interge no more than 2^24 = 16777216. If server hosts long and NetworkID reach this limit the publicExec and NetWorkID will be invalid on some objects. Server hoster shall restart the server in this case. Above is a video displaying new RTS style commanding in my TZK-CTI. This design applies NetWorkID and publicExec script commands to inform server those units selected in my local client. Take care: OFP can't handle too long string. If use one string to generate the publicExec 's parameter when selecting so many units in video the game will crash immediately. Please separate your string and apply publicExec in many times. In the video object's networkID is displayed in left-upper corner. If this value get close to the limit, one should inform the server hoster to restart the server. Below is an introduction of that RTS style interaction:

Make all AI units' skill using 1 but not the value defined in mission.sqm

Hi thanks. I obtained a document file which lists these commands.

How to use those "VBS_" commands in 2.01? I haven't seen any documents about them.

(Latest version: 4.0.3.01) Hello everyone. This is a mod and missions about CTI, naming TZK, which is developed basing on crCTI (ver 1.0) of XR missions, the irparaZ-@RES2C3C8. I optimized the design of CTI basing on personal comprehension about CTI, added many practical functions (e.g. "join" system, which allow players passing their members to other groups, and "Artillery Module", etc) and fixed discovered bugs. Since TZK_2.00, inspired by the "SE", a modified mission version basing on TZK_1.10, the author added some units and upgrade items. And since TZK_2.12 the 2.01 Arma:Resistance is applied, which allows the author to design some MP-stable visual effects, edit strings, precisely check units ammunition, design radio channel as an enhancement of the action list, etc. There're some designs not widely accept by players. For example, many EU ppls complained that in TZK AA are too strong and the game is "world of tank", but CHN ppls are mostly opposite, they think plane too strong. And many other ppls who don't often play mod-required CTI but prefer vanilla game. Idecoupled mostly scripts and EventHandlers from the mod and move them into MPMissions in version 2.12, and this can reduce the difficulty transplanting TZK design into vanilla game. Since TZK_4.0.0 I designed the modified TZK mission for mod mfcti and totalYugoWar, which remain mostly TZK mission design but link to units of mfcti/Yugo mod. Those missions are for 1.99 ACWA and don't require 2.01 ArmA:R. And they require an extra TZK critical addon: TZK_Objects.pbo, because TZK still remain many application of UserActions, which must be edited in the addon. UserActions (UA, for short) has radius and condition parameters although it doesn't pass the "caller", thus mostly it works better than addAction. Mostly EventHandlers can be found in "Common\InitVehicle.sqs", and in those "EH" or "Effect" subfolders. I recommend editors to place EH in mission scripts but not in AddOns except for there're many removeEventHandler in the mission script. In OFP the index managing of EH is bad, and in this case we should better place many EH in the definition of the object class but not add them in-game. TZK applied 2.01 Arma Resistance by [4RTech], many settings require new engine and don't fit 1.99 ACWA. 2.01 Arma Resistance by [4RTech] is very useful for CTI. Details will be posted below when the author have free time. If someone wish to modify TZK for 1.99 ACWA, those missions for mfcti/Yugo are recommend since, as mentioned above, they're for 1.99 ACWA and thus modified to remove 2.01 commands. (Actually, if [4RTech] make addAction so functional as listed in BIKI, I'll be glad to decouple UserActions and recover the addAction. The addAction and addEventHandler is applied well in XR mission, which thus owning good independence and requiring a light MOD. But addAction is really insufficient.) Download: Project TZK on github. A document of 2.12 new features. 4.0.0 introductions (in this topic).

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...

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?

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

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.

The author summerized this when exploring the reason MG not attacking some helicopter in personal MOD, resistance tank displaying green name for east vehicles, and units like M1A2 and Leo2A6 displaying M1A1 name when just being created. The parameter "accuracy" is mainly discussed. See completed file at link below. https://drive.google.com/file/d/1DLkNhQSbOfjh5gnmu9rKZ9hgelDNp1CA/view?usp=sharing

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.

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.

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

is the position of "viewGunner" in memory LOD centered with konec/usti hlaven?

10769 = 1 + 16 + 10*256 + 2*4096 https://community.bistudio.com/wiki/CfgVehicles_Config_Reference#weaponSlots

Introduction and Acknowledgment It is the player @hitman1987 and his work on the mod @Reforger that inspire the author with the idea about equation of motion in OFP. $hitman sent the author messages introducing his purpose and achievement in January, including his result of realistic ballistics, which relates to the main content of this topic. On last Saturday, April 18th, 2020, the author happened to have a thought about how projectiles fly in OFP after having read some CONFIG files of @Reforger. The @Reforger also displays some weapons with graduations to the author. It is the first time that the author come into contact with this kinda design. The author wish to add "Artillery Support" in CTI, not in the form of "creating shells by scripts" but by directly shooting. This requiring both trajectory's calculation and graduations displaying, and the products in @Reforger delightfully meets the author's needs. The author builds correct motion equations of "shotBullet" and "shotShell" and gives precise numerical solution (alright, numerical solution is given by RK4 formula). Furthermore with the help of the precise numerical solution, the author directly calculates and draws the graduations for specific weapons and vehicles (the main part affecting the trajectory is InitSpeed of magazines, and the length and the initial angle of the gun affect a small part as well). They're planned to be introduced into TZK in next version. The author summarizes this topic for $hitman, @Reforger and other OFPers. Chapter 1 Equations and Solution There is an annotation in@Reforger of the airFriction, which is a parameter of CfgAmmo objects and isn't explicitly given by BIN\CONFIG of 1.96/1.99. The annotation says //e.g. a projectile with a muzzle velocity of 1640 m/s which slows down 94 m/s/s (i.e. by 94 m/s in the first second) has an airFriction of: -94/16402 ~= 0.0000035. The 16402 of course should be 1640² and the author was thus inspired that in OFP the friction is thus probably obeying The author once explored the relationship between trajectory and mass of bullet's model when trying to design the global tracer effect. The result is mass don't affect trajectory of those bullets whose simulation is "shotBullet" and "shotShell". Thus the should degenerate to , and the coef c might be just the airFriction. Consider the Parabolic Motion with gravity. The equation of motion should be here the means the unit vector in the direction. We divide the vector into horizontal and vertical, and take the up and right as positive direction. Note that the acceleration is the derivative of velocity to time, we gain 2 equations: This is ODEs of and , but it hasn't analytical solution. Although it is only first-order, it's nonlinear. Luckly this simple system has a unique solution for f is independent with time. Having calculated its numerical solution, the author compared it with the distance of an actual bullet shot in OFP with a same initial data as equations', and verified that the coef -c (don't miss the negative sign) is exactly the airFriction, and the gravity in OFP is 9.8 (according to subsequent exploration on the ballistic of rocket, the gravity in OFP probably be 9.8066. But simply applying 9.8 won't cause too much error). There is another implicit parameter coefGravity of CfgAmmo objects. It is just the multiple of g and its default value is 1. No more parameters and terms in the equations imitating wind or other physical quantities. It's possible for editors to define coefGravity for specific ammo or all ammo (by modifying the "Default" object of CfgAmmo) in 1.96/1.99. The airFriction, however, can't be modified in 1.96/1.99. Its default value is -0.0005. The 2.01 ArmA:R explicitly defines both of coefGravity and airFriction in its CONFIG, and editors can thus modify airFriction as well. The author tried modifying their value and check whether the distance is still equal to the calculated one. It is safe to define coefGravity from 0 to 100, but a -0.01 value airFriction can cause 10 meters' error of a 380m range ammo. Editors are recommended not to set too big value for airFriction. To be honest, since the equations don't have analytical solution, OFP must use numerical method as well. The author guess the time difference in OFP probably related to the FPS, which will be inaccurate for high airFriction. 0 coefGravity can be applied for some laser weapons, and for some ammo detecting the direction of weapon (the bullet we catch by Fired-EventHandler, with a nonzero coefGravity , has fallen and thus can't represent the direction exactly). One more to attention: the airFriction should be a negative value. Not verified, but the positive value probably will be treated as 0 (of course, the air fricton won't help accelerating your bullet). About compatibility: it's safe to add new parameter coefGravity for specific ammo in 1.99/1.96, even though it isn't explicitly defined in BIN\CONFIG. The airFriction can't be modified in 1.99/1.96 and must use -0.0005 (one can define airFriction in config but it won't work). Both of them can be modified in 2.01, but be aware that [4RTech] has explicitly defined airFriction and coefGravity in the "Default" object of CfgAmmo of their BIN\CONFIG, editor must not miss airFriction and coefGravity in the BIN\CONFIG of their own mod (this often happen when editors applying their mod direct on 2.01, without modifying their BIN\CONFIG). Otherwise 2.01 game will crash, if using a mod with undefined airFriction and coefGravity BIN\CONFIG, and shooting an ammo with defined airFriction and coefGravity . Complete contents is included in a PDF and can be read/downloaded here. A video displaying its effects of Mortar and Howitzer. In @Reforger players can experience its grenade launcher, the first vehicle that the author has ever seen of this design, and experience some other properties like realistic ballistics, sights zeroing switch, etc.

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

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.

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.

And corresponding CONFIG editing as well. Will keep on updating for long...