Add Creation/LastLogin IP/DateTime

[LtRipley36706]

No description provided.

[Mag-nus]

See my comments in this PR regarding storing IP addresses in a database: #1471

[Mag-nus]

I would also make the following adjustments
email_Address should be nullable since it's a string.

create/last login IP should be the varbinary as suggested in the other PR, as well as nullable.

isBanned should be not nullable, default 0.

should ban_Reason also be stored in this table?

it might make sense to pull the ban columns out of account and maybe put them in a ban table and foreign link it to account.

[TheKnobGoblin]

See my comments in this PR regarding storing IP addresses in a database: #1471

I strongly disagree with storing the IP fields in VARBINARY. I've never seen it used that way and it majorly over complicates things. VARCHAR works perfectly fine for any IP address and it's used to store an IP 99% of the time for servers.

[Mag-nus]

VARCHAR can be more convenient in certain scenarios, sure. If you want human readable values when you browse the table in a tool such as phpMyAdmin or MySQL Workbench, VARCHAR offers you this over VARBINARY(16)

However, VARBINARY(16) is the standard for storing ip addresses. It is more efficient for both storage and comparisons. VARBINARY(16) supports both IPV4 and IPV6 addresses. If we only want to store IPV4, then INT is the ideal column type. We can always change the column from INT to VARBINARY(16) in the future (if needed) and retain the existing values. I prefer using VARBINARY(16) though because it's the modern standard for ip storage.

What is the use case where you would prefer these values stored as VARCHAR?

[TheKnobGoblin]

The use case is that it makes both storing and reading the IP address easier. The performance gain from VARBINARY is negligible and makes the IP address unreadable when you want to simply look at the account table and see which IP belongs to which account.

I think it's silly to block this PR because it's not modern enough for you. Keeping things simple is the best approach, especially for a community driven open source emulator project.

[Mag-nus]

I'm not blocking it, just offering suggestions.

I have some more comments, i'll bring them up in the development channel in ACE.

[Mag-nus]

I approve but Ripley should also review/approve.

[LtRipley36706]

I think this current state will meet both needs well. @TheKnobGoblin do the added fields that automatically convert to readable varchars work for you?