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.
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.
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.
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.
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.
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.
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.
something for later but BindableNetworkId should be able to be replaced with BindableInt64 I think
There was a problem hiding this comment.
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.
didn't we talk about crc being weirdly sometimes signed and sometimes unsigned
There was a problem hiding this comment.
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.
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.
We should probably config value this
| @@ -16,18 +16,18 @@ class FastRandomGenerator | |||
| { | |||
| public: | |||
There was a problem hiding this comment.
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.
VChatAPI is deprecated, isn't it? can we just delete whatever cancer this is
There was a problem hiding this comment.
Deprecated? What's being used in replacement? Discord? Would be an effort to remove it properly.
There was a problem hiding this comment.
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.
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).