-
Notifications
You must be signed in to change notification settings - Fork 52
Merge in 64 bit types branch to master #23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
… Server package overrun
Mega thanks to Apathy for his help in making the 64 bit version happen. Without his knowledge and super-special ability to act as a mega sounding board. Thanks for letting me ramble and lose my mind!
AlecH92
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I skipped over the new Crypto library files.
|
@AlecH92 Cool... yes, most of the line changes are from adding the updated Crypto++ Lib. Thanks for looking it over! |
| if(!found) { | ||
| DEBUG_REPORT_LOG(true, ("Tried to remove a connection server that wasn't in our list.\n")); | ||
| } | ||
| m_clusterStatusChanged = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i mean ok but why
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the DEBUG_REPORT_LOG() doesn't "use" the found var so the compiler thinks it's a wasted value. Doing this "uses" the found var and therefore shuts up the compiler.
| #define BASE_LINUX_TYPES_H | ||
|
|
||
| #include <sys/bitypes.h> | ||
| //#include <sys/bitypes.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at some point we should probably refactor this so Types.h is always using the Types.h in sharedFoundation instead of maintaining multiple
| GenericValueTypeMessage < std::pair < std::pair < unsigned | ||
| long, unsigned | ||
| long > , std::pair < int, int32 > > > | ||
| GenericValueTypeMessage < std::pair < std::pair < uint32_t, uint32_t > , std::pair < int, int32 > > > |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we really ought to just deprecate feature bit messages all together they don't have any purpose anymore and were already purged from dsrc in 3.1
| { | ||
| // attempt to validate a CS Tool associated with this request. | ||
| CSToolConnection::validateCSTool( ( uint32 )userData, result, session ); | ||
| CSToolConnection::validateCSTool( ( uint64 )userData, result, session ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CSToolConnection::validateCSTool takes a uint32 as its first param and doesn't seem to be updated in this changeset so we're casting userData to uint64 but the method to handle it only takes a uint32 so we expanding this to a uint64 because...? (was CS Tool connection tested w/ this change?)
also this originates as void * so can't it just be an uintptr_t? (I'm not actually sure that's a question)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This likely needs updating a bit deeper. It's being cast as a uint64 because the calling method has userData as a void * type. Because of 64 bits, a void * becomes a 64 bit value. The calling method needs to be updated to not accept a void if at all possible and all callers of the calling method should also be updated. Great catch!
| DB::BindableInt32 cluster_id; //lint !e1925 // public data member | ||
| DB::BindableInt32 station_id; //lint !e1925 // public data member | ||
| DB::BindableString<127> character_name; //lint !e1925 // public data member | ||
| DB::BindableNetworkId character_id; //lint !e1925 // public data member |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something for later but BindableNetworkId should be able to be replaced with BindableInt64 I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It honestly could be - however, after looking at this closer, BindableNetworkId isn't a straight mirror of BindableInt64. There are manipulations done to it after receiving the value.
|
|
||
| std::string const &GameNetworkMessage::getCmdName(unsigned long cmdCrc) // static | ||
| std::string const &GameNetworkMessage::getCmdName(uint32_t cmdCrc) // static | ||
| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
didn't we talk about crc being weirdly sometimes signed and sometimes unsigned
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, however, this particular method used the unsigned version. Just keeping it as it is (unsigned) such that we don't break anything.
|
|
||
| uint32 const cs_freeFillPattern = 0xEFEFEFEF; // this should match MemoryManager's free fill pattern. | ||
| uint64_t const cs_freeFillPattern = 0xEFEFEFEFEFEFEFEF; // this should match MemoryManager's free fill pattern. | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ref to MemoryManager is probably(?) obsolete given the deprecation of MemoryManager
| // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | ||
|
|
||
| float const cs_schedulerTicksPerSecond = 1000.0f; // # schedule ticks per second. Frame rates will not be able to exceed this. | ||
| float const cs_schedulerTicksPerSecond = 2000.0f; // # schedule ticks per second. Frame rates will not be able to exceed this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably config value this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.
|
|
||
| class FastRandomGenerator | ||
| { | ||
| public: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this whole thing can probably be replaced with a std native lib since its not 1999 STLPort anymore
| stream[BYTE6] = (data>>40)&0xff; | ||
| stream[BYTE7] = (data>>48)&0xff; | ||
| stream[BYTE8] = (data>>56)&0xff; | ||
| return sizeof(int64); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VChatAPI is deprecated, isn't it? can we just delete whatever cancer this is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deprecated? What's being used in replacement? Discord? Would be an effort to remove it properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing is being used as its replacement we don't have the Vivox libs so there's no support for Voice Chat and even to re-add it with something like Discord we wouldn't use the VChatAPI wrapper afaik it'd just be through ChatServer handling.
Cekis
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes need to be made or in some cases just verified.
Ready to be reviewed. This work is mostly for a future 64 bit transition in the future, but all work has been made compatible with our 32 bit builds. Has been tested by QA as well (@langelusse).