My volume/mass equation : where is the flaw ?
-
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’^^).
-
Many thanks Gisteron, you can modify ‘asap’ with ‘when you have will and time’, there’s no emergency, really
Edit : new link :
https://docs.google.com/spreadsheet/ccc?key=0AmEeSUau01IJdHJseW1PbTFja3NQbThyNU9JU3c5bmc -
I don’t think I was the first, but I did make one because I wanted to understand how it worked.
I used an Excel sheet for my calculations too, but only because I get around Excel more easily.
The nice thing about that was that I could quickly and easily just copy and paste the parameters into shiparch.ini.
One bad thing of course was that all similar mass ships ended up handling the same, and this was obvious in the game, and became boring.
So I introduced another variable factor which randomly (or manually, when I preferred), changed the handling by altering the X, Y, & Z steering torque by +15%, +10%, +5%, 0%, -5%, -10% and -15%. Much more interesting, varied handling, and ships are less “granular” too.
Good work.
-
I used StarTrader’s formulae, too, at some point. And I also worked with Excel (though I had to exchange the decimal separator each time for here in Germany it is a comma, too), even developing my equations.
ColdFire, you mentioned there was something wrong about the torques and that’s right. When reordering the code I realized there was a mistake I did for the accelerations used to calculate the torques were not translated to m/s² but kept at g. The next update will fix this bug. -
Many thanks Gisteron, I’ll try the new version as soon as I will modify my shiparch :)… There’s quite a lot of work each time I change the calculation method ^^
The last try I did (the last page of the sheet) is a theoric mix of your two methods, I didn’t had the time to test it yet.
Edit: Ok, I tested it, and after a nudge_force correction, it seems working nicely.Startrader, if I understand correctly, you applied a coeff factor to the steering_torque, right ?
I allready tried the same, and it’s working well. I’ll reintroduce this kind of “modifiers” at the end, when the calculation will be right for my taste.I’m using excel too because it’s simpler this way, I could change everything with ease, and that is needed at this stage. And I like being able to produce simple graphics to see the errors I made.
At the end, I think it could be a web-based php/sql tool with automatic ship scripting. Another story.On a side note, last night I discovered (with a mistake I made) that a little linear_drag on the hull is not a bad thing. I had a linear_drag = 17 on the hull and a linear_drag = 599 on the engine, and handling was really good (the kind of handling you can see for cylons fighters, in Battlestar Galactica : very agile and quick u-turns but with a heavy feeling).
I didn’t know why the feeling was so good on this ship before I noticed this (I find strange that a so small amount of linear_drag on the hull could change the handling so radically. Ship’s mass was 750 at this time, so hull’s drag was ~= mass / 45).So I had an idea for the swappable engines :
maybe is it possible to keep the same (static) linear_drag for every type of similar engines (light fighter, heavy fighter, etc….) and apply the variable part of linear_drag to the engine ? It’s only a variation of the wild idea I had the night before, but I think it could be worth the try.What do you think about it ?
-
individual torques are provided with individual radiuses, so that’s not a problem with my method (now, as the torque calculations are fixed).
a word on the linear_drag:
while the linear_drag on the engine is a necessity for the program not to have to deal with divisions by 0 (infinitely high velocities, as relativistic masses and improbability of light speed is not considered in the FL phys engine), linear_drag on the ship affects its behavior with engines killed more markably. if it is kept at 1 you can reach the maximal speed you expect from your thruster so if you change this, you have higher decelerations and lowered maximal speeds in dogfight.a word on the nudge_force:
the nudge_force is the force a ship translates to dynamic objects on collision. knowing the mass of the other object one could estimate the change of the flight vector. that’s how it happens with too high values we get from elder formulae, that when a player flown battleship hits you just a little bit you may be strafing away at ridiculously high velocities (for your mass may be as low as 100kg) which, provided you have the weak vanilla engine, can be decelerated and set back to normal over a longer time. so nudge_force can very well be the same on all ships or dependant on their maximal angular velocity. making this value depend on the mass exclusively would result in weird and disbalanced collision reactions. -
about the nudge_force :
it has also something to do with docking capabilities. A too low nudge_force breaks the docking sequence.
In Startrader’s calculation, I read nudge_force = mass * 3
In mine, nudge_force = max_force ( = mass * 9.81 * Gforce) but mass = ~ 10x Startrader’s, and docking seems ok. I didn’t test some collision as I wasn’t aware of this force translation in collisions (and my COLLISION_DAMAGE_FACTOR = 10000, so I don’t really have collision issues with fighters :D) .I also understand that nudge_force has something to do with object avoidance (like in asteroids fields), but I fail to see the mechanic behind it.
-
more essential for object avoidance is the actual strafing capabilities and flight speed.
I figured that the nudge force to be three times the mass is at least not true for the vanilla game (example: li_fighter - mass = 100; nudge_force = 300000 = mass * 300); and docking issues such as strafing away with velocities not given through the other forces and drags are still there.
However, we have to consider how surrealistic the vanilla game is. The equation of nudge_force = mass * acceleration is also wrong for the li_fighter’s (engine) acceleration is 48000N / 100kg = 480m/s^2 = ~ 48.9G and not 300m/s^2 which would explain the nudge_force with your formula.conclusions:
a) - The relation may be not as proportional as you get it with a simple multiplication.
b) - nudge_force does affect flight capabilities.
c) - How nudge_force affects collision, collision detection and where this force affects the ship and/or distinct objects is not clear yet.This basically is why I did not include nudge_force into my calculations. I would if I knew the exact effect and I will once I do know or have discovered.
Bad, with the methods we have (manually flying in FL and seeing what happens), trial and error are our only ally and reliability of that is questionable. -
Well it is good fun experimenting when we have the time, and a great feeling when things come to light and we understand them better.
But Real Life has taken over for me for the past many months, so I’ve not been able to contribute much.
I’m still making new surs and cmps now and then as we have Schmackbolzen and P1p3r’s and Adoxa’s tools, but I can’t spend much time on those either.
At the end it’s a free-time hobby, and we would waste our time on other things if it wasn’t FL.
