My volume/mass equation : where is the flaw ?
-
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’^^).
-
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.
