PlayerData iOnlineID
-
Ahoy,
i am currently struggling with the PlayerData struct, especially the variable iOnlineID inside. I am witnessing a strange behaviour right now that the iOnlineID is always 0. No matter what i try or debug. I switch back the code where the online id is received by following code:
char *p1 = (char*)x_pstrPD; char *p2 = (char*)&Players; memcpy(&p2, p2, 4); return (uint)(((p1 - p2) / 0x418) + 1);and now get the correct player ID. Did anyone witness the same thing? I have no clue why it stopped working and am sure it did work correct a few weeks back as i was testing too. This struct hasent been changes since quite some time, but somehow traverse_active gives different results than before. Also the pointer to the CAccount is also not filled correctly.
Dunno maybe its also just because i debug release code… But then again i did that quite some time now and havent witnessed it before.
-
Seems i have found it…
As far as i can tell it has something to do with FF edits about the EquipDescList stuff. I am assuming the structs are now from a different size and as those are used in the PlayerData the variables are now shifted to other memory locations and do not represent what they should represent.Something along this. When i reverse that the iOnlineID is working again same as the rest of the PlayerData struct.
-
This is strange because I use iOnlineID extensively and have not noticed this behavior.
What’s your build setup?
-
What do you mean with build setup?
I am using currently VS2005 and took the latest changes from SVN.I tested now several stuff and compared the files again. As soon as i include the changes regarding EquipDescList and Vector i have a corrupt PlayerData struct in the debugger. When i reverse that to the previous layout then everything works.
I am not sure what i do wrong. Maybe i am missing something. Any ideas for what else i should look?
-
Yeah, so, the new build is running in VS2013. I’m not sure whether VS2008 works, and I’m pretty sure VS2005 won’t work.
I’ve kept the VS2008 solution files around for legacy reasons but I’m no longer checking whether something breaks with them. The 2013 solution SHOULD work in 2013 Express, if it doesn’t let me know what’s wrong with it.
-
Well, let’s see:
#include <stdio.h>#include <list>int main( int argc, char* argv[] ) { std::list <int>test; printf("%u\n", sizeof(test)); return 0; }</int></list></stdio.h>VC6, 2003 & 2010: 12
2008 SP1: 28Presumably 2005 is also using the 28 value, ergo you can’t directly use std::list with that compiler.
-
Yeah, that’s what I figured.
Not a single idea why 2005 and 2008 have a different std::list size, though. You can always conditionally test for those versions with the _MSC_VER macro and replace all std::list references with just three uints or something.
-
Huor wrote:
ah ok, typically M$.Comments like this piss me off. Nothing to do with “M$” (which playing a game that wouldn’t have existed without them is rather laughable). I’ll bet you that gcc and Clang (or llvm or whatever compiler you’re a fanboi of) have also had STL structs change in size and signature across versions. Remember, the C++ spec gives NO guarantees as to binary compatibility. What we’re doing falls under undetermined behavior.
On the topic at hand, as I said feel free to use the newest revisions but do conditional defines, that’d work as well and you can commit those to the SVN for compatibility.
-
i dont have a problem with what you have suggested FF, nor even that you have changed the layout - hell no. I am confident that i can live with the previous definition. I am not even mad that it happens. I was just wondering and would not have assumed that the size the STL containers do change just by using different versions of the library. Good to know, always something to learn
I am just a bit disappointed, cause its not the only thing that they do change and which is not compatible anymore and which is not apparent (you dont get a warning nor do i ever have read a kind of release note where they do protocol that they changed sizes and whatnot of their libraries). So why is it not M$? I use a product from them, their libraries.
PS: there is no need for me to define different versions based on _MSC_VER not as long as i am using VS2005. So i use the previous definition of EquipDescList and EquipDescVector and all is good.
PPS: I am not mad at anyone of you - just if you felt i am. No i am not! -
Again, they don’t release that information because you’re not supposed to be using it. Using it is bad design. It’s a terrible idea. The only reason we have to care is because we’re using a private API as though it were public, with binaries compiled over 10 years ago. No public API ever uses the STL for precisely that reason.
Also, using “M$” is a derogatory acronym, if you hadn’t figured that part out. I find using that childish and unwarranted.
-
I use it cause its a shortcut - that is well known - without putting anymore weight into it. Not more not less. No idea what you interpret into it.
People can get mad because of odds and ends. Sigh. I will remember that and just for the good tone - write Microsoft - in future - so no one is pissed off.
-
Just to comment here on using the STL with FL, we really should not use the stock MS versions but rather use our own implementations that are FL binary compatible. I did this partially for FL-style maps (which did not match VC6, VC7 or any other STL library version) here:
Maybe it’s fine for lists with the VC8 or higher versions, but we shouldnt really trust that because who knows if the FL devs just wrote their own implementations.
-
If the MSVC STL works, I wouldn’t recommend making our own. Wasted effort and more prone to errors.
This of course is assuming thorough testing of the STL objects in question.
-
Well that’s a special case
