No, that’s more likely to be the partial connection ddos technique that was particularly popular some time ago.

In my case, no account shows up as online and any listing comes up empty, yet when a new player connects they get assigned a client ID of 33 (since the player cap was 32).

Man, this is good news. I have had many issues of late with my Yahoo accounts. I bet I’ve changed passwords a dozen times now and I’m still getting locked out of my accounts. I don’t know which is which anymore. The CEO is getting her ass royally chewed for this issue, as well. I hope they fire her ass and get someone in there that can take care of business, soon. My FB account has almost been completely emptied of all my life friends and I can’t even log in half the time without going through checks yet, someone else can, it appears.

So I have conclusions (partial, anyway):

CreatePhantom didn’t trigger any exception, so I don’t think the error originates from that.

The root cause of the issue remains NaN positions and/or orientations. The way it happened this time around was a lot more tricky though, hence why it took me so long to find it. The rotation quaternion the client sent back after jumping was all NaNs because the rotation matrix was slightly denormalized, causing the conversion to fail. However, the quaternion was “sanitized” somewhere along the chain and became all zeros, so it didn’t get caught by the SPObjUpdate patch I added (it checks for NaNs only), but a zero quaternion is still an invalid rotation matrix, so when converting it back it became full of NaNs again and would crash the server on some occasions.

I’ve tracked down and fixed the quaternion conversion (I can’t really help with rotation matrices becoming slightly denormalized, that’s just normal) on the client, but I’ve also added another check to SPObjUpdate in FLHook which requires the quaternion to be mostly normalized, so it’ll catch erroneous values like this in the future.

Oops. :oops: Now it’s updated.

Still a work in progress, we’re knocking down elements of it as we can get to it. The collisions themselves still need a bit more work, but they’re far more consistent now and we can reliably determine who gets damaged and how much. Ramming is a legit strategy now.

Thanks guys. In any game you were apt to find one “Boba Fet’s Slave ship” was a notorious example of the phenomenon of the aim point being outside ship and you’re having to strafing or “spray and pray” shooting.

Sounds like it’d be related to beams somehow then. I’ll keep that in mind, thanks a lot man.

Once the teleport has happened the game seems unable to recover. Since other teleports work fine, I have doubts it’s a timing issue.

Also, the code is definitely in GetCenterOfMass, not in any of those other functions. Look at the offsets, BaseWatcher::set_pointer not 0x40e8 bytes long. The call stack I get works its way back up through various updating functions, starting in CShip::update.

The only oddity is that if you go even before CShip::update, there are calls to readfile.dll. I’m not sure why file reads would happen there (maybe it’s loading the system and failing?) or why a file read would call the ship’s update function.

After a bit of integration work, it seems to be working exactly as expected! All shield hits now trigger HkCb_GeneralDmg and I’ve committed the changes to the SVN for anyone who’d like to have that functionality as well. As usual, adoxa, you save me 🙂

Now all I need to figure out is the damage’s source so I can trace back the munition archetype.

EDIT: From what I can tell, it would appear that the damage has already been applied by the time 6CEA740 or its equivalent hull function are called, so in order to find the projectile that did the damage I’d probably need to trace back the munitions earlier. Player beam hits (I only really care about beams) can be traced using MunitionCollision events, but NPC beam hits are harder (I’m guessing they’d be found somewhere in PhySys::GenerateCollisions(CBeam*)) and matching the beams with the GeneralDmg call would be quite tricky.

Thank you very much, as per usual 🙂

For future reference, this problem only arises if the solar’s type is JUMP_GATE. I’ve tested with STATION, PLANET and SATELLITE and they all behave as expected, but JUMP_GATE randomly works 5% of the time and that’s it.

Trick. For the Server I used the imports, sorting them by name, combining with an existing list I had made ages ago (when I first did the disassembly), then sorting back by address. For the Client I searched for where it created the packet definition, combined them into a single line, added the strings from PacketDump.cpp, then resorted.

Kept having issues with it so I dug again and I finally found it: offset 0x5416c0 contains a function of the signature IObjRW* (uint id, uint zero). Call it with the id and zero in the second parameter to get the IObjRW (which can just be cast to IObjInspectImpl) or null if there’s nothing associated.

We’ve finally figured it out. It happens when a permutation is defined in an encounter INI but doesn’t actually exist (say, you have 10 blocks but 11 permutations).

It could perhaps be a bad pilot_job in an [EncounterFormation].

And I thought the issue is -95€

Just to give an update: I am currently learning for my exams and thus couldn’t do much. I have finished the theory (amongst other things cubic bezier curves for path and I got a simple way to calculate the length of the curve, which you need) and am still confident, that it will work. I will post a video of it as soon as I got it working. But feel free to test it yourselves, if you got the time for it.