Assuming we convert the SecondsInGame as decimal or hexadecimal, because converting the JoinTimestamp into real seconds would result in an enormous number.
Just to let you guys know a day has 84,600 seconds. Since this started in 1970, that’s that’s 55 years! Converting all those seconds into our normal counting system might be a waste of memory, even if not now, as time goes on, the number just gets bigger. A conversion has to happen in my opinion into a more memory effective counting system. Like slim’s base ten counting guide.
Yeah…re-reading I don’t understand what I was trying to say. I think what I meant was that originally I thought that since that’s 55 years of seconds (1.734e+9), so that it might be too big to fit in the character limit for properties so we’d not be able to calculate. That’s why I was saying we might have to use slim’s base ten counting to calculate while in a more effective term of counting.
Which do you think is more efficient - hexadecimal subtracting or decimal subtracting? Hex subtracting would save the need to convert the id into decimal, but will need a system to subtract a b c d e f g, but decimal subtraction calls for turning id into a decimal, but then re-encoding it into a hex value after game ends
Either way you have to do a conversion, and I think it’d be a lot easier if we just converted everything to decimal at the start, did all the subtraction and addition we needed, then converted everything back to hexadecimal at the end.
Blackhole alt moment.
anyways since im clueless as to what part of the id yall are talking about now it seems we figured out only a part of it is a unix timestamp and from part of my research is that the rest could be in game values most likely not acct related since it dosent stay the same which gives us a clue to what values it could mean but not enough to the entire thingy yet
