[c]bool[/c]'s are bytes, which get padded to align the next member (i.e. [c]struct { bool b; int i;} [/c] is typically stored as [c]struct { bool b; char pad[3]; int i;}[/c]. Likewise, 0x3ca is just padding after the short.

0x34c (uiShipArchID) is actually [c]bool cheated[/c], I think; 0x320 (iCyclicRedundancyCheck) is actually iWorth (when you land on a base, to detect cheating when you exit).

0x324 is a copy of uiShipArchetype (cheat detection).

0x344 seems to be a count of how many times the character has been saved (per login).

0x3c0 is initialized to 0, but does not seem to be used.

0x3c4 is [c]float difficulty[/c] (initialized to 1; restricted to 0 to 2).

0x3d0 seems to be your player number (i.e. the one-based [c]Players[/c] index).

0x3dc is some kind of trade request counter.

0x3e8 is the id of the ship that was created.

0x3f4 is the id of the base you entered (this is the one that is tested for some Req functions); 0x410 is the base just exited.

0x414 is the unsaved but loaded [c]starting_ring[/c], whatever that is.

OK, thanks, i will look for an error in our formation definitions. Thanks for the hints. If not i need to get deeper into debugging and set breakpoints at some addresses. Maybe i could track which of the formations is corrupt.

Well that’s a special case 😄

I am having a lot of entries that are coming from

// Hook for crash at 0xEB4B5 (confirmed) FARPROC fpHook = (FARPROC) HkCb_CrashProc6F8B330Naked; ReadProcMem ((char*) hModContentAC + 0x11C970, &fpCrashProc6F8B330Old, 4); WriteProcMem ((char*) hModContentAC + 0x11C970, &fpHook, 4); WriteProcMem ((char*) hModContentAC + 0x11CA00, &fpHook, 4);

Any idea about what that is about and what the argument refers to? Not sure if its critical, but get the log message a lot and could not narrow it down yet.

Just one possible idea of ​​the problem, Player Control :
KillDisconnectingPlayers = no

I’ve only got it to work via clienthook some long time ago (I force the player to undock). I’ve seen some new beam functions in cannons code, but don’t know for what exactly they are. Maybe you can test them out.

Edit: massdriver wrote what I meant. Had to leave while I was writing the post and finished it later 😉

No idea, if I debug with IDA I never get such exceptions. Did you give the debugger all privileges? Maybe it isn’t allowed to read that memory area.

I’d say it depends on the context. Usually those utility functions are really lightweight, so its basically sth like this:

call get_ship_id mov var, eax

get_ship_id:

mov eax, [this_ptr + 0x12345] ret

So yeah, you might save some instructions but all in all this is sth I would consider as insignificant compared to some other stuff that is going on in FLHook.

The client doesn’t load server.dll during MP, so if you load it yourself, it’s just going to have a player count of 0 and all the calls will fail.

look into values like “mass”, “thrust_force”, and “nudge_force”. just imagine the units to be not custom but taken from the real world like meters are; and a solution may become apparent.

of course, this thought maybe futile if freelancer physics are designed to have flaws like these. for my part i find it more appropriate to test first if and how far freelancer is designed bad enough before asking for magical additional codework solutions which would only affect players in MP.

Ok so it must not be an NPC - but it can? Anyway a position of any object is tried to retrieve and finally a basewatcher tries to check whatever.

Can this be reason of a memory leak at another point? Or anyway to track down what BaseWatcher is watching via the Watchable struct?

Players.GetMaxPlayerCount() should return the player count of current active players. If you want you can test the number it returns. Since it is old code, I assume it has been tested a number of times, but you never know.

The bug you wrote about has something to do with fuse kills. At least that’s what I noticed in our mod. Since there is no player who killed the player the code assumes memory garbage for the killer ID (smth. like that). I completely rewrote the killing detection and it is now based on who did the most damage in the last seconds (actually it’s a bit more complicated). I remember getting the actual damage done by a player was quite tough to get.

Found another issue which might lead to wrong autobuy. If a ship has no batts/bots defined it can happen that the autobuy buys nearly 4 billion items 🙂

here the code:

foreach(lstCargo, CARGO_INFO, it) { AUTOBUY_CARTITEM aci; if((*it).iArchID == iNanobotsID) { aci.iArchID = iNanobotsID; aci.iCount = ship->iMaxNanobots - (*it).iCount; aci.wscDescription = L"Nanobots"; lstCart.push_back(aci); bNanobotsFound = true; } else if((*it).iArchID == iShieldBatsID){ aci.iArchID = iShieldBatsID; aci.iCount = ship->iMaxShieldBats - (*it).iCount; aci.wscDescription = L"Shield Batteries"; lstCart.push_back(aci); bShieldBattsFound = true; } }

Should be changed to:

foreach (lstCargo, CARGO_INFO, it) { AUTOBUY_CARTITEM aci; if (((*it).iArchID == iNanobotsID) && (ship->iMaxNanobots > 0)) { aci.iArchID = iNanobotsID; aci.iCount = ship->iMaxNanobots - (*it).iCount; aci.wscDescription = L"Nanobots"; lstCart.push_back (aci); bNanobotsFound = true; } else if (((*it).iArchID == iShieldBatsID) && (ship->iMaxShieldBats > 0)) { aci.iArchID = iShieldBatsID; aci.iCount = ship->iMaxShieldBats - (*it).iCount; aci.wscDescription = L"Shield Batteries"; lstCart.push_back (aci); bShieldBattsFound = true; } } if ((!bNanobotsFound) && (ship->iMaxNanobots > 0)) { // no nanos found -> add all AUTOBUY_CARTITEM aci; aci.iArchID = iNanobotsID; aci.iCount = ship->iMaxNanobots; aci.wscDescription = L"Nanobots"; lstCart.push_back (aci); } if ((!bShieldBattsFound) && (ship->iMaxShieldBats > 0)) { // no batts found -> add all AUTOBUY_CARTITEM aci; aci.iArchID = iShieldBatsID; aci.iCount = ship->iMaxShieldBats; aci.wscDescription = L"Shield Batteries"; lstCart.push_back (aci); } }

Yeah thats it. Have used it and everything is fine again.

BUT i would kindly understand what is the difference. Is there a setting i need to activate or is it simply impossible to generate a working dll with VS2055?

Thanks Cannon!

Yeah i expect that the server requires this function call. I believe internally something like the following happens:

If player buys the equipment
disable the button
run through the buy routines (that would be ReqAddItem)
if everything is ok enable the button again
further stuff….

I have a workaround for this - but thought this workaround could be useless if it directly could be avoided to add the item. Even if i set the count and mount variable to 0/false the item is added - what is a bit strange.

It is just wondering me - because the PluginVersion also returns prior the server.reqadditem routine. And i am asking myself if this never has been an issue before?

At least thats the first function that my breakpoints interrupt the code from its execution - so i thought its well used as first 😉

If the EquipDescList reference from the function call would point to the item/equipment that is currently in use then it could save needless traversing through the cargo. W0dka pointed out to use the iterators of EquipDescListItem - but the question would be if the item that is currently in use can be retrieved by it wiithout running through all objects.

I will see if i can find something out with these iterators. For now i think traversing the cargo hold is a reasonable way to get what i am looking for - although if its a workaround^^
Thanks so far all that left a hint here.

DwnUndr wrote:

‘how do you get the amount of cargo in your hold to INCREASE over time?’

Dang Tribbles! 🙂

:lol: 👏 My first though too.

Now the trouble Tribbles cause would be harder to implement than a simple cargo increase… Maybe have other cargo or even equipment jettisoned or so…

useful info, thanks for sharing