Skip to content

Conversation

@Cekis
Copy link
Contributor

@Cekis Cekis commented Jan 25, 2022

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).

Cekis and others added 30 commits October 21, 2021 17:45
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!
Copy link
Contributor

@AlecH92 AlecH92 left a 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.

@Cekis Cekis requested a review from apathyboy January 26, 2022 18:51
@Cekis
Copy link
Contributor Author

Cekis commented Jan 26, 2022

@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;
Copy link
Member

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

Copy link
Contributor Author

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>
Copy link
Member

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 > > >
Copy link
Member

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 );
Copy link
Member

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)

Copy link
Contributor Author

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
Copy link
Member

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

Copy link
Contributor Author

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
{
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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.
Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.


class FastRandomGenerator
{
public:
Copy link
Member

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);
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

@Cekis Cekis left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants