Offset requests - ship spinning & docking speed

No.

If it’s less than 10% you will get the wagging on autopilot.

If it’s more than 20% the ship will spin like a top.

It is not perfect between these two values but a lot better.

The problem is also compounded by the inertia values in the sur file- I haven’t investigated those to find the effect.

There is also an elasticity parameter in contents.ini that will affect collision rebounds, but again I’ve not done limit investigations on that either.

Don’t forget the FL physics engine was not fine-tuned, it’s unfinished. It was not tested with large ships because DA didn’t put any in. Now we put in big ships we have hit these problems.

Maybe adoxa can find a tweak?

Yes I know about that autopilot problem, but if you just put the first value of rotatin inertia to 1% of the first angular drag value it works good without fast spinning.
10% is to much!

What do you mean, the 1st value (X) only?

And the others to what?

The ship is just spinning around it’s X-axis. So you just have to change the X-value of rotation_inertia to 1% of the angular_drag x-value.

Y and Z axis are not necessary to be changed.

Gravedig

Time to rehash this. While the current patch method works, you really lose the the proper “capship” feel while turning (ie. huge massive hulking feeling while trying to get your ship to move). Has anyone looked into this any further?

Yeah, drives me nuts too. Adoxa. Wink. Wink.

Bump

Wut, fox!?

FriendlyFire wrote:
Wut, fox!?

!

I have some vague memory that Argh solved this… But he gave all the ships totally different stats, so I wouldn’t know if his solution could be implemented in just about every mod.

Besides, you would have to find his toolkit, version 1.2 iirc… In 1.3 he went over the top and had removed all light equipments because they caused bugs.

Anyway, the trick, iirc, was to make those ships incredibly heavy, and adjust all other stats to also keep them pilotable. But I was never really interested in that part of the game, so I don’t remember much, and could even be wrong too.

He was a pioneer in many things, Argh… I still use [my adaption of] his xml based modding method.

I thought kosacid fixed it (see SpinProtection).

F!R wrote:
….
The latest is the one, causing lag together with these plugins.
The rev. 196 dated 18.10.2012 by adoxa works fine 4 me
(together with those plugins).

I don’t think this will work very good with the FlHook versions
beyond the 196.

And for the v.196 I d recommend to use the
recompiled plugins from this thread:
2.0.0 Plugins/KosAcid Projects/Plugin Ports

Btw

• would be cool, if someone would recompile those once more,
  to meet the latest FlHook version.
  

even if you get a decent anti-spin plugin… I’d still highly recommend Startrader’s formula for overall ship value excellence.

It’s good to know, WHY things do things i was dubious having modded for a while (heavy emphasis on ships) by the time i finally took a look it didn’t just make sense, i kicked myself for not having that formula in my head for all those years.

It does go a long way to stopping spinning in big ships upon collision… but meh… if someone rams you with the osiris… your gonna move… hehe i’d feel cheated if i didn’t.

Except ST’s formula (and all similar formulae) lock your ships to a very narrow range of handling feel. It’s way too limitative in general and still doesn’t stop ship spinning in practice.

So I’m going to kind of resurrect this thread because I managed to get more data on Freelancer’s collision handling.

Unfortunately, I don’t have anything conclusive as of now, but I did figure out a chain of function calls that seem to be handling collisions.

The most interesting function is at 0x628fa40 in common.dll. I can’t tell what the function does in its entirety, but I do know that towards the end, it sets a vector of CollisionEvent objects in a hidden PhySys object. Those CollisionEvents are what is eventually read by the game to send SPObjCollision events to the server.

Walking up the call stack reveals another function at 0x628c410 which appears to be handling collisions in a more direct fashion (for instance, there’s a direct reference to MIN_TIME_BETWEEN_COLLISIONS), but a lot of what it is doing is unfortunately moving around member values which I can’t trace down.

The hidden PhySys object can be obtained by peeking at PhySys::GetCollisions’s source. The DWORD at 0x63fc09c seems to always contain the object, even though there’s actually a case in the code where another value is used.

Relatedly, GetCollisions requires an integer as its first parameter and the value must be very specific in order for it to work. As it turns out, that value is directly returned by the function at 0x554e90, which may be called as a uint(void) function.

Finally, I have partially reversed the CollisionEvent struct:

struct CollisionEvent
{
	CObject* a; // This is the damaged object in my limited tests
	CObject* b; // This is the "other" object
	uint iDunno1[2];
	Vector position;
	float fDunno2[3];
	Vector velocity;
};

Now, what isn’t done is actually fixing the collisions proper. I’m still not sure where the math is performed, but I’d hope that somewhere in the call stack we can at least hook the strength of the bounce to tone it down - I’d much rather see NPCs fly through the ship than bounce them around.

Anyone feel like taking a crack?

The most interesting function is at 0x628fa40 in common.dll.

This function appends a CollisionEvent to this vector of CollisionEvents (arg1 is [c]this.end()[/c], arg2 is [c]1[/c], arg3 is the [c]CollisionEvent*[/c] to append). Perhaps that means you could hook this function, see if the objects are capital ship and fighter, and then either ignore the collision altogether, or reduce the velocity (or, at a guess, the rotation that might be the unknown floats).

Relatedly, GetCollisions requires an integer as its first parameter and the value must be very specific in order for it to work. As it turns out, that value is directly returned by the function at 0x554e90, which may be called as a uint(void) function.

It’s the [c]ID_String[/c] of the current system.

I’m not sure what the floats are, but they’re always 0.707, -0.707, 0 from what I’ve seen.

The problem is that I’m pretty sure the collision’s velocity/position effect is already applied by the time the CollisionEvent is set, so I doubt intercepting it would be enough.

If the numbers are correct, then in looks like a normalized vector (0.707²~=0.5). Could be the collision normal for example. But this is just a guess, the numbers jumped at me because after a while you see the typical values and your “vector” (if it even is a sequence) would make perfectly sense then as it has the length of one.