My volume/mass equation : where is the flaw ?
-
Hi there,
In my mod, I want everything to be as close as reality as possible.
So, I decided to make use of the EquipMass plugin, and define a ‘credible’ mass/volume equation, to fit in my ‘credible’ ship system.Here is my logic :
-
in my mod, a light fighter is mass = 500 (~)
A light fighter has a cargo = 0.08 x mass, here 40.
A light fighter is a solo craft, there’s not enough room for a passenger.
A human being is ~75kg, is composed 80% of water. Let’s say 100% for simplicity. Volumic mass of water is 1Kg/L.
So, 1 unity of mass could be 1 Kg and 1 unity of volume could be 1000cm3, it’s credible. -
So, we could consider, for water, 1 unity of mass = 1 unity of volume. Easy.
-
A VIP : volume = 75, mass = 75. Easy, cannot enter in my fighter, perfect.
-
A prisoner : volume = 100, mass = 100 (25Kg of metal is enough to keep him away from the pilot
). Easy. -
1 unity of gold : volume = 1, mass = 19.3 (gold volumic mass is 19.3g/cm3). I can take 40 vol of gold in my fighter, but it will weight a lot, and will be difficul to handle. Perfect.
…. and so on… I will have to invent some volumic masses for commodities like scrap metal, components, etc.
I just tested my theory with a VIP, water and gold in my fighter, and the handling differences seem credible with what I imagine it could be in reality.
Final result is, I want the handling of the ships dependant of the cargo nature, because everything just doesn’t weight the same for the same volume. It could add a lot to the role play, if each commodity/equipment has its own influence on ship handling.
I already have engines unmoutable/buyable, 6 class of engines restricted to 6 types of ships (F, HF, VHF, FR, HFR, VHFR), thanks to Adoxa’s engclass and shipclass plugins.
What do you think about it ? Where is the flaw in my reasoning ?
-
-
if you use the equipmass plugin and you want ship masses to be as low as that, for realistic flight you’d need them to have either ridiculously low cargo holds (which is well fine for fighters, for they aren’t supposed to carry cargo) or extremely low masses of all the types of commodities.
there is another attempt to it though. let’s say the ship doesn’t have 40m³ of cargo space, but it may carry additional 40kg of cargo (a bit low IMO, but that’s just to demonstrate). so one unit of water takes up one unit of ‘cargo space’ yet it is not 1m³ but 1l (=0.001m³).
so your ship has astronomical free space but “your ship’s handbook says, that it may only carry 40kg besides the pilot for the engine not to overheat” or so.in any way, consider, that modern fighting aircraft have a mass of around 10t and not 0.5t. you are better prepared giving all the forces new higher values and the ship masses, too, than recalculating all the commodities to have a realistic relation. recently I released a tool that could help you get the force values that are exactly as realistic as you’d want them to be.
-
Hi Gisteron, thanks for your input.
I just tried to experiment with your tool, but I have unexpected results.Here are the settings for my test light fighter :
G-Force = 8
ship mass = 10000
Speeds :
Engine (max_force) = 150
Strafing (strafe_force) = 32
Thruster (max_force) = 200Your tool gives me :
Forces :
Engine (max_force) = 784800
Strafing (strafe_force) = 167392
Thruster (max_force) = 261550
Eng/Thru drag (linear_drag) = 5231
Angular values :
steering_torque = 927,617191, 4185,5999, 951,272627
angular_drag = 5232, 5232, 5232
rotation_inertia = 10000, 10000, 10000With these settings, my fighter turns on itself way too quickly and is near to impossible to stop (too much steering_torque ?), and there doesn’t seem to be a speed limit anymore : it continues to accelerate forever (which I think is close to reality, but not desirable here)
Here are my corresponding inis entrys, I may have done a mistake somewhere :
shiparch.ini
[Ship] ids_name = 458943 ids_info = 468943 ids_info1 = 478943 ids_info2 = 468958 ids_info3 = 488943 nickname = bsg_blackviper LODranges = 0, 8000, 12000, 100000 ship_class = 0 type = FIGHTER DA_archetype = ships\BSG\blackviper\Blackviper.cmp material_library = SHIPS\BSG\Blackviper\Blackviper.mat cockpit = cockpits\kusari\k_elite.ini mass = 10000.000000 hold_size = 40 nanobot_limit = 45 shield_battery_limit = 45 linear_drag = 1.000000 fuse = intermed_damage_smallship01, 0.000000, 650 fuse = intermed_damage_smallship02, 0.000000, 325 fuse = intermed_damage_smallship03, 0.000000, 217 max_bank_angle = 65 camera_offset = 10, 44 camera_angular_acceleration = 0.050000 camera_horizontal_turn_angle = 20 camera_vertical_turn_up_angle = 5 camera_vertical_turn_down_angle = 30 camera_turn_look_ahead_slerp_amount = 1.000000 explosion_arch = explosion_li_fighter surface_hit_effects = 0, small_hull_hit_light01, small_hull_hit_light02, small_hull_hit_light03 surface_hit_effects = 150, small_hull_hit_medium01, small_hull_hit_medium02, small_hull_hit_medium03 surface_hit_effects = 300, small_hull_hit_heavy01, small_hull_hit_heavy02, small_hull_hit_heavy03 steering_torque = 927,617191, 4185,5999, 951,272627 angular_drag = 5232, 5232, 5232 rotation_inertia = 10000, 10000, 10000 nudge_force = 3000000.000000 strafe_force = 167392 strafe_power_usage = 40 mission_property = can_use_berths HP_tractor_source = HpTractor_Source num_exhaust_nozzles = 3 hit_pts = 3000 shield_link = HpMount hp_type = hp_fighter_engine_special_3, HpEngine01 hp_type = hp_fighter_engine_special_2, HpEngine01 hp_type = hp_fighter_engine_special_1, HpEngine01 hp_type = hp_gun_special_9, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_8, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_7, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_6, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_5, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_4, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_3, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_2, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_1, HpWeapon01, HpWeapon02 hp_type = hp_gun_special_10, HpWeapon01, HpWeapon02 hp_type = hp_torpedo_special_2, HpTorpedo01, HpTorpedo02 hp_type = hp_torpedo_special_1, HpTorpedo01, HpTorpedo02 hp_type = hp_thruster, HpThruster01 hp_type = hp_mine_dropper, HpMine01 hp_type = hp_countermeasure_dropper, HpCM01engine_equip.ini
[Engine] nickname = admin_lf_engine ids_name = 459025 ids_info = 0 hp_type = hp_fighter_engine_special_1 volume = 0.000000 mass = 10 max_force = 784800 linear_drag = 5231 power_usage = 0 reverse_fraction = 0.200000 flame_effect = gf_li_smallengine02_fire trail_effect = gf_li_smallengine02_trail cruise_disrupt_effect = gf_li_cruisedisruption trail_effect_player = gf_li_smallengine02_playtrail cruise_charge_time = 1 cruise_power_usage = 150 character_start_sound = engine_li_fighter_start character_loop_sound = engine_li_fighter_loop character_pitch_range = -50, 25 rumble_sound = rumble_h_fighter rumble_atten_range = -5, 0 rumble_pitch_range = -15, 25 engine_kill_sound = engine_li_fighter_kill cruise_start_sound = engine_li_cruise_start cruise_loop_sound = engine_li_cruise_loop cruise_stop_sound = engine_li_cruise_stop cruise_disrupt_sound = cruise_disrupt cruise_backfire_sound = cruise_backfire indestructible = true outside_cone_attenuation = -3 inside_sound_cone = 60 outside_sound_cone = 180 cruise_speed = 1500 material_library = equipment\models\hardware.matst_equip.ini
[Thruster] nickname = ge_s_thruster_01 ids_name = 263737 ids_info = 264737 DA_archetype = equipment\models\st\ku_thruster.3db material_library = equipment\models\ku_equip.mat HP_child = HpConnect hit_pts = 1000 explosion_resistance = 0.500000 debris_type = debris_normal parent_impulse = 20 child_impulse = 80 volume = 0.000000 mass = 10 max_force = 261550 linear_drag = 5231 particles = gf_ge_s_thruster_01 hp_particles = hpthrust power_usage = 165 lootable = true separation_explosion = sever_debris LODranges = 0, 20What I want exactly to achieve is :
- realistic handling based on total mass (hull+equip+cargo) with realistic volume/mass commodities (as I said, impossible to take a passenger in a light fighter, but still be able to take a little cargo)
- more inertia than in vanilla, but not too much (your calculations seem a bit too much)
My best results, for the moment, are with StarTrader’s calculations :
FIGHTER, 0 (light fighter)
mass = 500-900
hold_size = 0.08 * mass
bots, bat = 0.09 * mass
hit_pts = 6 * mass
angular_drag = mass * 30, mass * 30, mass * 70
steering_torque = 1.6 * angular_drag (± 10%)
rotation_inertia = 0.15 * angular_drag
nudge_force = 300 * mass
strafe_force = 2 * nudge_forceBut there’s not too much inertia (I need just a little more), and hull mass is not really credible, even if I consider it to be the mass without components (engine, guns, tractor, radar)…
And more important, I still didn’t find a reliable calculation for engines/thrusters max_force.
Sacrificing hull mass credibility is an option, but I’d prefer to avoid it…Would you give us the calculations your tool does behind the scene, to see the mass/drag coeff you are using, and the other coeff also ?
-
one mistake i see immediately is that you added a linear_drag line to the thruster. everything else should work fine. for the fast motion, this is likely related to the fact that the cockpit offset from C(0|0|0) is quite low on some axis. with a maximal G-acceleration of 8 you get pretty high values there in this case. you may try to multiply your inputs there by a factor or to use angular values you get from a different G-Force entry. if it is a code error I made I could figure so if you provide me the offset entries, please
btw, from my reverse calculations (using rounded values) you should have a pitch and roll maximal speed of 10-11 degrees per second. your yaw should be about 46 degrees per second. both is relatively slow compared to original FL fighter rotations.there should not be any linear acceleration issue however for the sum of the linear drag values of ship and engine should set the maximum velocities…
the calculations my tool makes are actually the same the FL engine does afterwards when calculating the vectors (I must admit, I had problems combining simultaneous angular and linear acceleration, so i separated them at last. from trial it appears though, that FL does so, too, despite it is different in the real world). if needed i can provide them via pm or post them up on the tool’s thread.
edit: after checking the values’ validity and your code there doesn’t seem any mistake that would lead to the results you have… i doubt it having so much effect but try indeed to get rid of the linear drag line in your thruster… i’m not sure whether ship mass is a float or an integer, so maybe the decimal digits there are wrong either (unlikely though…).
-
Hi RimShot
It was a very good shot, you were right about dot and floating points. We have a bad habit here to usually use floats instead of points, so it didn’t shock me. Many thanks.@ Gisteron
So, I could test your settings, other than a ‘camera drift’ and a low rotational speed small issues, your calculations seem really good for near-newtonian physics.
For the linear_drag entry in a thruster, I tried it because your tool says “Engin/Thru Drag (linear_drag)”, so at the end I thought it may be a unused vanilla option for thrusters. In reality with or without it doesn’t seem to make a difference, I didn’t try with equipdrag plugin.I’m going to investigate more into this, thank you for this usefull tool.
-
Ok, I could play with it more :
- your steering_torque seems way too low for every ship and every mass I tried. I found a workaround formula for it, so this is not really a problem (angular_drag * rad/s is perfect).
- IMO the rotation inertia is too high for a comfortable gameplay : it is really hard to just point the ship in the good direction, not even talking about flying in that same direction ^^ I feel it like an ‘imprecise piloting’, even with a very light fighter. I’m talking about the rotation inertia, not the ship’s inertia (which is excellent)
- the last, huge problem, is that each ship must have it’s own engine, as the engine and ship parameters are interdependant in your calculation (engine’s linear_drag and max_force depends of the ship mass). I kills the idea of swapping engines…
Other than that, the feeling is very nice. That is a really good tool. I reversed your calculations (except steering_torque) to understand your formula, and it’s very smart. I just don’t understand how earth gravity (9.81m/s) could apply in a galaxy far, far away
About the subject : does the concept of G-force really apply in space ? Is it not linked in a way with gravity and/or because we’re not in a vaccum on earth ?
-
actually, G-Force is not gravitational force, but a unit of acceleration other than 1m/s. I used it for it is commonly prefered by amateur aircraft acceleration property stats. thus its independant from earth actually.
from the formula of the steering_torque in fact the relation is as you described. this is how i figured, how fast your ship is supposed to turn with the values you gave. however, instead of asking for a wished turn rate input, I asked for the acceleration the pilot is supposed to feel (that’s where the cockpit offset comes into use), for any rotation, even unaccelerated rotation, is an accelerated movement. so the rotations are tendentially slow, like they are in real world fighter craft, too (the pilot could just not handle them to be essentially faster). you can ofc ignore realism for the sake of easier or funner gameplay. that’s where we all have to balance at a point.
the rotation inertia btw is supposed to maintain the same acceleration of the pilot on his circular path as the one of the ship on its linear path.oh, and the handling ‘problems’ are a question of getting used to them and the NPC’s have just the same ones provided their values are made the same way. this tool is indeed not supposed to give good values for new ships but to rebalance motion patterns of all ships entirely.
strange the tool gave you floats with ‘,’ instead of ‘.’. I’ll look into this…
-
No, I wouldn’t. Sure there will be differences in the inputs people would make because they have slightly different ideas of what is realistc and what not. I wouldn’t want the program to be judged after that which I think is may be fitting the ships.
There is no solution everyone would agree with, that’s why I just gave a tool to build one’s own, not one ‘ideal’ solution like it was done before. -
I gave this a lot of consideration several years ago, and of course the weights (mass) and volumes are unbalanced.
For example, I took the McDonnell-Douglas Phantom twin-seat interceptor fighter, which would be a Heavy Fighter class:
Wikipedia says: “Despite the imposing dimensions and a maximum takeoff weight of over 60,000 lb (27,000 kg), the F-4 has a top speed of Mach 2.23 and an initial climb rate of over 41,000 ft/min (210 m/s). The F-4’s nine external hardpoints have a capability of up to 18,650 pounds (8,480 kg) of weapons, including air-to-air and air-to-ground missiles, and unguided, guided, and nuclear bombs. Like other interceptors of its day, the F-4 was designed without an internal cannon but later models incorporated an M61 Vulcan rotary cannon.”
For speed: Mach 1= 340m/sec, so Mach 2.2 = 748m/sec.
I think it would be easy to incorporate these into the game but would take some time, because the engine power needs to be increased too of course.
Any comments?
-
StarTrader:
On the German Wikipedia article about the McDonnell F-4 there are technical data of the F-4B and F-4E. The F-4E’s are complete and it has an acceleration force (engine’s max_force) of 2 × 51.80 kN (103600) and with afterburner (thruster’s max_force) one of 2 × 79.65 kN (159300). That would be a linear_drag of the 1 ship unit and additional 211.967914 in the engine (the max speed would be reachable only with afterburner then).Problems:
-These speeds are inproportionally high to the small system size given in FL.
-The maximal acceleration of 7.241 m/s² (calculated with a mass of 22000kg, being a badly estimated compromise between empty mass and maximal mass) is way too low for FL’s typical arcade combat style thus the plane would rather be a new class or a gunship even, rather than the fighters which are supposed to be much faster. -
“disproportionately” high.
Yes but I thought we are all reasonably clever guys and would know that we have to scale everything down, no? Do I need to spell out everything? Oy Vay, My life!!
-
StarTrader wrote:
“disproportionately” high.Yes but I thought we are all reasonably clever guys and would know that we have to scale everything down, no? Do I need to spell out everything? Oy Vay, My life!!
Or the other way, scale up systems…
I’d be very interested to see how you make your calculations, as I’m actually trying to find mine.
I’ve a (rather simple and small) excel sheet for this with “variables” for your 2 types of settings. Maybe you could help to make it better ? I just uploaded it and made it collaborative, if you wish :https://docs.google.com/spreadsheet/ccc?key=0AmEeSUau01IJdFF0TW8zYmtzbmQwc2hORnB6VXhZTHc
I really like the idea of having some strong calculations method for handling, I think this is a must for good balancing
-
I remember those you gave earlier in this thread. I have been using them too, and they turned out to be balanced with the other ships. Wasn’t it StarTrader btw, who initially made them up?
The calculations I do are rather similar to the second table in your link that is supposed to be close to Newtonian with two exceptions:- in FL the speed unit is not km/h but m/s (which is no difference to the formulae actually).
- in my calculations I do not enter how fast I want the ships to turn and this has following reason.
When the ship turns, the pilot experiences an accelerated motion with the acceleration a = v² / r (rotation speed = v / r = sqrt(a * r ) / r)
Thus the acceleration I predefine for linear motions is being used for the pilot motion when turning, too. This way I do not have the option to make rotations too fast or too slow compared to linear acceleration for the parameter asked is the cockpit offset and the acceleration that already applies to linear motion, too.I could provide you a pseudo source code with the exact equations via PM or a Skype conversation, if you like. Unless there is bigger interest in the algorithms behind it, I suppose it shall be enough up here, that it is functional.
-
Gisteron, i’d be very interested to see your equations, many thanks (i’m not using Skype, so PM would be the way to go).
You are right, the first table is StarTraders method, the second one is yours, tweaked a little.
Each method has pros and cons, IMO :- the two methods have good handling
- your method doesn’t allow to swap engines but is really mass-driven (drag is dependant of the mass)
- StarTraders is less precise in term of calculations and hulls need a mass scale-down but allows engines swapping.
I’m trying to make a mix between the two :
- good reactions in term of masses and acceleration (your G-force calculation is very smart)
- possibility to swap engines (maybe add a variable drag to the ship and keep a constant drag on the engine ? I don’t think it will work)
As you said, I tweaked your calculation a little : I didn’t like the steering_torque so I reintroduced the deg/s factor, but it’s a problem of personal taste, not your your tool’s fault
I tried to introduce a ‘inertial damper’ factor too (rotation related), but it is not working very well yet… -
There is the fact that rotation speed is not just a speed but result in pilot acceleration. I considered that for my steering torques, that’s why they are not easy to get used to; however my method includes the acceleration as a relevant factor to both while earlier we were viewing angular and linear motion as separate and the centripetal accelerations our pilots felt were different from linear accelerations.
For engines are affecting only the linear motions you can define all ships of the same class to have the same mass and acceleration. This way all these ships could swap engines. This is, for instance, how I solved it (though to me it was a simplification of the process, I never was interested in swapping engines).I’ll give you some relations once I get into them again (i.e. ‘asap’^^).
