Librelancer 2022.02
-
I have played with ship engines and physics extensively, as you will be able to see in my mod, which I hope to release in the next months.
Those experiments gave me a good understanding of how Freelancer does this.
First of all, you can have more than one engine in Freelancer. If that is the case, Freelancer only uses the linear_drag from the first engine, but the force and power requirements are properly added by Freelancer.
Cruise mode:
Freelancer ramps up the force value of the first engine to reach the cruising_speed from constants.ini in cruise_accel_time from constants.ini. Aside from that, all other engines provide their max_force. If you run out of energy you will decelerate to a proportional value, e.g. if you generator can only supply one half of the required energy, you will slow down to the half of cruising_speed once your buffer is empty. If you want different drag values while in cruise, you may alter cruise_drag in constants.ini (default is 1)Engine kill: The force and linear_drag of the first engine are turned off, so only the ships linear drag is slowing you down in this mode. All other engines continue to provide force (not cool, but FL does it this way)
@Gisteron, I don’t think that FL’s calculations are that complex. I did a test run with a ship this week, but I haven’t found time to analyse it yet.
See also:
engine_equip.ini
constants.ini
shiparch.ini -
Gisteron’s analysis is all higher order equations which are completely pointless to use in an actual implementation of the game. You can reach parity just by iteratively simulating the ship’s handling each update using very simple linear equations.
velocity += front_vector * thrust_force * delta_t / mass; velocity -= velocity * linear_drag * delta_t / mass; position += velocity * delta_t; angular_velocity += steering_vector * steering_torque * delta_t; angular_velocity -= angular_velocity * angular_drag * delta_t; orientation *= RotationMatrixFromEulerAngles(angular_velocity * delta_t);Most values here are fairly self-explanatory. The front vector points towards the front of the ship. The steering vector is a 3-component vector indicating the amount of yaw, pitch and roll to apply (it’s directly determined from the mouse cursor’s direction and whether the roll key is pressed), varying from -1 to 1. [c]RotationMatrixFromEulerAngles[/c] is essentially just Freelancer’s [c]RotateMatrix[/c] which just calculates a rotation matrix using the appropriate coordinate system from Euler angles, you might need to adjust the coordinate order and convert to degrees from radians.
The only trick not mentioned above is that you don’t want your correction factor (the drag) to cause the ship to move in the other direction. This is just a simple clamp that can be done in various ways, I just do
if (sgn(velocity.x - drag.x) != sgn(velocity.x)) velocity.x = 0; else velocity.x -= drag.x; ```for both velocity and angular velocity, component-wise, where [c]sgn[/c] is the sign function. If you want added precision, you can run this whole calculation using double precision floating point values ([c]double[/c]) and you can also iteratively run it many times each update. Since Freelancer has a variable update time rather than a fixed one, I target an update every 1/120th of a second and calculate the update function as many times as necessary (e.g. if the update was called 1/60th of a second after the last one, I run the computations twice with the same inputs). This allows the calculation to be a lot smoother and probably accounts for the ~1% variation with Freelancer's values (which are comparatively extremely noisy) in testing. -
Is the drag reversing velocity sign something that happens due to discretion of time or rounding errors or the like? I ask because analytically that shouldn’t ever happen, but of course time intervals between computations are not infinitely small, and so if one takes v0 to be the velocity that was a finite time ago (say, a hardcoded fraction of a second, or a frame), I can see how such unwanted reversals might happen and one would need to clamp like that. Is that why they do?
As for angular motion, the parameters seem to be the same, except now you have one set of torque, inertia, and angular drag for each of your three rotational axis, as counterparts to thrust force, mass, and linear drag, respectively.
-
Yes, it’s why. It should be fairly obvious that discretization will introduce errors, the most pronounced of which is oscillations.
-
Here’s the current version of the ship control + steering. Still missing engine kill and cruise ramping though those shouldn’t be too difficult. The steering is almost there @FriendlyFire do you know if FL calculates a roll input when you’re only using mouse (and not the roll keys) ?. There’s also the auto-levelling of the ship that is a bit dodgy but it does level.
-
As far as I could tell, the game only produces roll when the roll key is pressed or the autopilot is engaged. I believe autoleveling will also use it, but I have autolevel disabled so I can’t say for certain.
-
So I took the time to evaluate my test and here are the results:
My test parameters were:
max_force = 10000
linear_drag = 10
mass = 250How I performed the test:
I put in reverse thrust until my speed was about -50. At that speed I engaged full thrust and started to gather the data once I went over 0 m/s. I recorded the whole test at constant 30FPS.I used ffmpeg to dump the videostream as pictures, put the displayed speed of every tenth picture in a table and plotted it.
The calculated speed line was generated by the following equation(v0 is the speed of the previous iteration):
v = v0+(max_force-v0linear_drag)/mass
so
a = (force-vlinear_drag)/massThe delta curve is just the difference of the other two curves, usually ~3 m/s.
-
Having fun starting to implement bases - here’s the current state of Planet New Berlin!
-
First attempt at docking:
https://www.youtube.com/watch?v=Oxyc7dTkhZY
It’s about 25% implemented at the moment. It only picks the first hardpoint (doesn’t follow HpDockA01,02 etc.) and there’s no collision avoidance. But progress is progress!
(Thanks to Why485 and Treewyrm for invaluable information)
-
https://www.youtube.com/watch?v=JSjwyvMDCjs
Docking part 2:
- Now follows the 02 and 01 hardpoints
- Cmp animated door that works with the physics engine.
-
Moved the website to a new domain
-
Working on the addition of a Forward+ rendering pipeline to the engine. This will allow for a lot more lights to be present at one time in a scene, point lights attached to the light sprites here as an example.
This feature requires an OpenGL 4.3 implementation, which limits it to Windows and Linux on modern graphics cards only (someone @apple fix your crap honestly). For now it’s not enabled 100% of the time due to some culling regressions which should soon be fixed.
Extensions to the data will be in the form of light parameters for light equipment, and light particles in ALE.
For those with iGPUs don’t fear this is toggleable and the traditional renderer is still available regardless (and runs at 60fps 1080p on my HD 515).
-
8-[……]
Perfect!
Now it is “atmosphere”
-
To make some of the work a bit more useable I’ve decided to begin work on an alternate Utf Editor powered by imgui and the Librelancer engine. Here’s a very early screenshot of what it can do.
-
Oh me so want!
Doin’ that download thang @ Librelancer now.
Darn download freezes at 89%. Will try later.
(10 to 1 it’s the flakey 4G here, don’t ask about my desktop internet connection. It got et’ by a backhoe)
-
Contributing to the existing, full featured UTF Editor wasn’t in the cards?
-
Unfortunately the existing engine code for Librelancer is completely tied to OpenGL 3.3, which in my experience plays really poorly with WinForms and not at all with WPF.
Even if the only unique feature which is ALE preview was to be integrated, it’d introduce a hard requirement on a GL 3 core context into Utf Editor which is something that I’d be unwilling to do seeing people still try to run it on XP and very old graphics hardware. Also I can’t run Utf Editor on Linux under wine, which is my main platform. Think of this more as a Linux-specific editor since windows users would definitely prefer native controls.
My parser code for everything is available though and you’re free to poke at anything for information. If I find something that would be really great for Utf Editor I’ll let you know and contribute that
-
Getting a dead-lock in attempts to reach asteroid fields. Occurs in both 2017.10 and Daily builds. Screen with procexp/threads: https://i.imgur.com/pglDWeH.png. Not sure what exactly to report.
Offtop, a small question regarding such: https://i.imgur.com/K9qws20.png
( I’m just attempting to render )
The background was painted to the alpha channel of grass, otherwise I wouldn’t see the grass through the glass. What’s causing that: incorrect blending settings or an order of rendering? Because if this is an order’s fault… well, pass, I’ll just start learning Depth Peeling immediately.
