Librelancer 2022.02
-
Worked a little more on the ALE engine. Progress is slow, but it’s progress none-the-less!
https://www.youtube.com/watch?v=eYWUgz-t1vQ
EDIT: how do you guys get the embed to work?
https://www.youtube.com/watch?v=eYWUgz-t1vQ -
New build in the OP!
-
Is there any way to rotate camera in the system view? I just see controls to move around.
And unfortunately when clicking on Gameplay Demo, the music of Liberty starts, but the game is stuck in a loop. No errors, only “no sur found” warnings.Edit: When moving around in LI01 the game also gets stuck when approaching Fort Bush or getting Manhatten in my view.
-
So… here is Thn! Or at least a buggy implementation of it. (As usual, click image to make it bigger).
This is yet to be committed due to how buggy it is, but this has allowed me to go through and remove practically all the bugs in my lighting implementation!There’s still bugs with IllumDetailMapMaterial, and FxRectAppearance in the Ale, but progress is progress.
-
The project now has a website - http://callumdev.github.io/Librelancer/ !
I’ll be posting screenshots and releases here from now on, as maintaining two different forum threads is a bit silly.Releases will be named in YYYY.MM format
The website is fully editable at - https://github.com/CallumDev/Librelancer/tree/gh-pages , so if you feel like adding information to the tutorials section, please do!
-
Version 2017.03 released. This is the first under the new release format.
-
Quite a few systems at the moment crash due to the Alchemy engine crapping out. I think you can get to Br02 though.
Will put remembering FL install location on the todo list.
-
Attempting to load the discovery mod: http://imgur.com/a/Dw4ez
Tons of crashes due to missing zones + CRC errors, but the stuff that loads is pretty. I even managed to crash radeonsi though I’m not sure how yet
-
Preview of some features coming up:
https://www.youtube.com/watch?v=gdF5Tf_b3do
- Atmosphere rendering
- Speed properly matching up with FL physics
- HUD things
- Multiple resolutions
(also any information on how FL physics works would be greatly appreciated)
-
Well, the physics in Freelancer are a lot like flying an airplane rather than a ship in space.
That means that every force has a counter force and that’s why you stop if you turn off your engine (not engine kill!).
So the standard physic equations for speed, distance and acceleration, etc. apply to FL.I’ve added some info regarding engines and thrusters to the wiki, so head over if you got any questions. I’ll write something on ship handling in the next weeks.
-
Thrusters! https://www.youtube.com/watch?v=qBlxLtTxXgo
- Ships now go at speed using values from INI
- Thruster drain is correct
- Turning is still incorrect (so much math)
- Still got camera and selection work to do
-
Working on FLBeamAppearance (click for full size)
-
Working on the Thn engine. Hopefully a small demo of being on-base will be available soon
-
https://www.youtube.com/watch?v=1RRxP4oQZZI
Glitchy New London THN aesthetic. (Click here, youtube embed still not working?)
-
Version 2017.10 is now released! (Check the first post for link)
-
Starship flight physics in Freelancer is pretty much Newtonian (barring rounding errors and of course the fact that masses don’t attract each other as they would in reality). The reason you stop when you throttle down is linear drag (compare to Stokes’ friction) and hardly a good model for atmospheric flight, really.
Anyway, when you kill your engine, the engine’s drag is not taken into account any longer, and so the only thing (literally) “dragging” you down anymore is your ship’s linear drag which tends to be rather small by comparison (in vanilla it’s 599 on the engine and 1 on the ship, if memory serves).
So if x( t ) is your location at time t, m your total mass, b( t ) your raw thrust force (be it from engine, or thruster, or indeed any other accelerating influence, like explosions can be, or the sum of any of the above) as a function of time t, v0 your velocity at t = 0, and d your linear drag (be it from engine, or ship, or the sum of both), then your velocity v( t ) as a function of time t is given as
v( t ) = v0 + ( b( t ) * t - d * x( t ) ) / m ,
<=> dx(t) / dt + d / m * x( t ) = v0 + b( t ) / m * t .
This is an inhomogenous linear first order differential equation with constant coefficients. An implementation of this sort of mechanics of course doesn’t require understanding the theory behind forms like these. Suffice it to say that our b is bounded (there is, after all, a maximum thrust for any accelerator in the game, and only a finite amount of them can be effective at once because computers have finite memory) and if we keep it constant at any value, then in the long run our speed approaches the familiar old thrust/drag ratio c = b / d as I will demonstrate now, along with what I mean by “the long run” and how it is a matter of the ratio j = d / m of drag and mass:
Assuming that your thrust b is constant, and that we start at the location x0 = 0, the exact analytic solution x( t ) to our motion equation is
x( t ) = c * t + ( c - v0 ) * ( exp( -j * t ) - 1 ) / j .Already we see j both scaling how far x deviates from a linear expression, as well as how quickly that linear expression is reapproached. x is also shifted by something proportional to the difference of thrust/drag and starting velocity. Let’s see how velocity behaves:
v( t ) = dx(t) / dt = c - ( c - v0 ) * exp( -j * t ) .
We could see it before, but now it’s a lot more obvious: At t = 0 our velocity is exactly v0. As t gets very big, the latter term vanishes almost completely, effectively only leaving behind The promised thrust/drag. We also see that j scales how quickly the latter term vanishes even more clearly now. We can now choose a speed w between v0 and c but not equal to c, and find out how long it takes for our ship’s speed to pass by it as it keeps approaching
t( w ) = ( log( c - v0 ) - log( c - w ) ) / j ,where ‘log’ denotes the natural logarithm.Now, of course, there are rounding errors due to the discretion of values inherent in digital computing systems. Not even space in vanilla Freelancer is truly continuous which is why we see our ship jitter ever more as we move further away from the system’s center. The formalism I presented is an idealized, mathematical, analytical model, and as we measure the actual motion we are bound to find slight errors and imprecisions, but this is, as far as I know, how Freelancer’s physics are at least supposed to behave.
-
I don’t understand most of what you said, but I’m pretty sure I based my physics off of an old post you wrote somewhere on some part of the internet that probably doesn’t exist anymore. It was a description of Freelancer’s physics and included simple formulas for calculating stuff that I implemented into my “Freelancer simulator.”
In terms of linear stuff, it seems to have worked perfectly and mimicked the quirks that happen when you set weird values in Freelancer. For example, plugging in vanilla values gave speeds and accelerations that seemed to line up 1:1 to Freelancer. Ditto for when I plugged in crazy values like what’s used in 88 Flak for its very weird take on Freelancer’s physics.
What tripped me up was how rotational forces work. I essentially made something up that if I recall correctly was the same ideas as translational, just applied to rotations. When in cockpit view, where you have more direct control of the ship, it seemed to line up very closely, but it was very slightly off in a way I don’t recall. Again, using both vanilla and Flak values, I got something that felt close enough that you’d need a stopwatch to really tell the difference.
Where it got weird though was in third person. I suspect that you aren’t actually flying your ship in third person, and instead the AI is flying it. I did tests in Freelancer and noticed that your turn rate is actually faster in third person when compared to the cockpit. My turn rates matched the cockpit turn rates, but not the third person ones. I suspect that when the ship banks in third person, the ship is now using a part of its pitch torque to turn. The combined power of the yaw torque and a slight pitch torque means it turns a bit faster.
That becomes a question of control though at that point, and not physics, but I thought it was very interesting.
Edit:
Yes, there are also a lot of particulars and quirks if you want to emulate Freelancer 1:1, especially when it comes to engine kill and cruise.
For engine kill, you switch to using only the ship’s inherent linear drag. The engine turns off, and when it turns off it also stops providing drag. However, if you use the thruster or strafe, the engine must turn back on so that you maintain your limited top speed. If you don’t turn it back on, then using the thruster you’ll be able to accelerate to whatever top speed is implied by your linear drag. Using vanilla values, it ends up being effectively unlimited because it’s only 1.
Cruise gets weird as well. Cruise has a set speed to reach, but it still uses forces to achieve those speeds. At least, I think it does. That’s how I wrote it anyway. I have to do some pre-emptive calculations, but I figure out how much thrust is required to reach cruise speed (300 in vanilla’s case) when the engine is on (so engine + ship drag). Then, when the cruise engines turn on, I ramped up this additional cruise engine force to slowly get to that pre-calculated value. If you just apply the cruise engine force instantaneously, then you don’t get the smooth ramp up to speed like you do in vanilla FL. You know how when you drop out of cruise you decelerate to your normal speed almost instantaneously? The same exact thing happens in reverse when you just apply the extra cruise engine thrust on its own.
