Cannot help identify the one from the cover, but that SVG subtitle I’m rather certain is the system font from the PS3 that was also used in the Sam Raimi Spider-Man trilogy, except here it’s not italicized. Have a look:

http://www.1001fonts.com/homoarakhn-font.html?text=the universe of possibility&size=54

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.

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.

adoxa wrote:

I noticed at a velocity of about 1200 m/s and higher effects like space dust no longer render.

I expanded Manhattan’s atmosphere dust and changed cruise speed to 2500 m/s and that still seemed to be rendered.

Hmm, weird, the regular motion dust disappears completely. Maybe it is something in the ale after all, I shall compare it thusly with the atmosphere dust. Thanks for now…

[jump shake hack]

So many thanks! Still baffled how you do it but aren’t we lucky to have you goes off to bother someone else with his happiness

Good evening, old friends and perhaps soon-to-be new ones.

So, since I last saw this thread it has about tripled in length, and from what I gather some of the wiki page is out of date although there seems to be an effort of gathering and recovering all the offsets found in the recent years.
The particular one I am looking for seems to either not been found or not to be recoverable by search parameters I managed to intuit, so here goes.

I noticed at a velocity of about 1200 m/s and higher effects like space dust no longer render. I thought this was a matter of the ale, so I went in there and started coding away. Increasing emitter size, making effect alpha and size time-independent seemed, while otherwise making expected changes, not to break through what hitherto seemed to be an emergent limit. So my modder-senses tell me it must be hardcoded given that parameter any of the ini code seems to refer to is responsible.
Does anybody know this offset? And if it hasn’t been found, would someone versed with the appropriate tools and know-how kindly have a look for it?
And while we’re at it, what is responsible for the shaking during a system jump? it happens in both the target and the origin system irrespective of the properties of the tunnel. Is there perhaps a multiplier for that?
Many thanks!

StarTrader wrote:

Does it slow down your game?

Probably. But on Jeider’s computer it still shows 50+ fps, so I think it’ll be good enough for some of our lower middle class machines.
The shape isn’t too fancy, but this sort of goes to show that the idea of spamming vanilla models into enormous constructs that have more in common with pixel art than with large Discovery-esque bases has its potential…

1. What’s that?
2. Again, what do you mean?
3. You mean as in solid bars? Check the limit breaking list on our wiki, grab a hex editor and do it yourself. You’ll probably want to change a few other things along with it, so it won’t be your only time using the editor or the little skill you gain

I don’t know what about the common.dll would have to be changed in order for either of those changes to work (mainly since I can’t identify what you mean by #1 and #2).

As for changing the bar colour with the stats as input parameter - that’d require a client plugin. AFAIK its not a code built into the engine, but since the colour is a variable its probably not a big deal to make a function to bypass it and put out a value of its own.

All changes required for OSP are also available. IIRC there is a dedicated tutorial but at the very least you’ll be able to find all the required information on our wiki and come back when its not enough.

Point is: Don’t try and have others do your work. When it comes to understanding the engine and making changes to the program, some will surely help out, but when the thing in question are a few offsets you can change yourself - do it yourself. We’ll help you understand everything you have trouble with. We just won’t write your mod in your stead.

Good effort!

Ich habs eig schon gerochen, dass da irgendwas in solcher Richtung kommt. Wär ja nicht das erste mal dass jemand laut seine Supermod ankündigt und die dabei ärmlich aus anderen zusammengekratzt ist.

Hätte interesse an der ds9 bar… An sich ganz gut, dafür, dass du Milkshape benutzt hast. Ich würd an ne fortgeschrittene alternative umsteigen, wie blender oder sogar sketchup. die sind oft resourceneffizienter, tolerieren mehr komplexität, und oft einfacher zu bedienen - mal von den verschnellernden instrumenten zu schweigen. Aber das sieht schon nach mehr aus als was ich fertigbringen könnte mit meinem derzeitigen un-talent xD

I’m building something that may be called a vanilla Trek-ification but its on deep hiatus currently and it isn’t in any way designed to be a Trek based mod, apart from visuals (which has its balancing challenges). As for beam weapons… well, you gotta compromise there, that’s true. But that’s the advantage one can have when not building something that resembles canon Star Trek and thus rationalising away all the issues. I suppose they could be implemented but that would totally ruin the spirit of fighting the limitations of an outdated game for its own sake

Will some parameters be configurable through an interface or configuration file?

You can also upload stuff to our Download database, I’m sure most of the modders of the older mods dont care.

I’d still ask though, if possible (i.e. if the author is known and cares to respond if reached through his old contact data), just for the sake of fairness, politeness, protocol and good manners.

Goading? As in having them use the search function so that there is a reason to keep it at all? Guilty as charged

Though really, we’ve been there and we got this far and not everyone who happens to get to work on a mod is in fact merely a “modder”, and we’ve seen that before, too. Seriously, we’ve been there, we got this far, so why couldn’t anyone else who happens to work with games anyway? Besides, the ambition is less in an uber-mod or let alone a decent player base but really in getting to know what it takes and how it is like to work on a game in the space-sim genre. If you ask me, Freelancer is a very good start and regardless of just how far they get with the FL mod, they’ll quite likely get what they’re looking for just through the process of trying. You wouldn’t expect anything less, would you?

Its not that noone has released a game yet, y’know… I think we’re talking to people, who know fairly well what it takes and what to expect and who also learnt at some point to deal with frustration, eventhough I dare postulating that one-man modding teams use to get frustrated much, much more, than a proper game developing company, that does the engine from scratch and thus knows it pretty well and has team members dedicated to specific areas so there is a certain development speed, quality and success to be accepted as realistic, even if not expected or anticipated.

I don’t mean to sound overly enthusiastic, but just scanning over the latest posts in here I get an impression of that our community is tired and in fact somewhat cynical. Its not even constructive criticism here where we’d be pointing out likely obstacles, but just a general notion of “you guys even know what you’re talking about?”. Gentlemen, please. Be nice.

I use the ms3d exporter after preparing the model in advance in my default modeling program and it turns out just as intended. Granted, it is tedious though…

Are we talking about models from the respective games or models based on visuals in those games? In either way, it would be very strange, not to say suspicious, if indeed there were no restrictions on use and no credits required.

Just to comment on the new FW picture: I know those light types as volumetric lights and it looked precisely as one would expect it to (unless i’ve missed a corner where there is some glitch). Specularity, too, must not be on this image, since the starship is backlit. Every possible angle that could give a light spec on its surface is avoided in this shot resulting in it being pretty dark as most things should be that you would expect to encounter in space.

I’m happy they haven’t though. Its that confirmation of appreciation for the game in the public. Always a nice thing to read, wouldn’t you say?

You guys want some promoting images?^^ Most of my work was with vanilla FL models, but I wouldn’t limit myself to that. Besides, updated graphics might have me try to replicate them and thus help me practice; that is aside from the promoting effect it may or may not have for your mod, of course.

Because this is common knowledge that has been found and recited over and over and I wouldn’t want to have myself been thought of as that guy who answers anything trivial because of nothing else to do.

Besides, while embarassing, it is partially also satisfactory to watch equally uninformed newcomers giving non-answers that lead nowhere close to the solution. It reminds me of my early days - only that I had serious language barriers preventing me from reviewing the old knowledge and thus forcing me to a forum that had a rather scarce modding database.