[DiscordArchive] though if it's just 300 soldiers, couldn't you just random them around across the 32 bits you alread
[DiscordArchive] though if it's just 300 soldiers, couldn't you just random them around across the 32 bits you alread
Original source
I realistically see a thousand or so across all of EK and Kali
I remember seeing something about using JSon formats to store arrays in mysql so I wouldn't have to store too many of the same GUIDs for a variety of keys, I wonder if that's more efficient than using bitfields purely in the database.
rektbyfaith
07-18-2022, 08:27 PM #21Archived author: whatwere • Posted: 2022-07-18T20:27:04.904000+00:00
Original source
I realistically see a thousand or so across all of EK and Kali
I remember seeing something about using JSon formats to store arrays in mysql so I wouldn't have to store too many of the same GUIDs for a variety of keys, I wonder if that's more efficient than using bitfields purely in the database.
Original source
that's the same consideration as doing it in memory, it's only worthwhile if you only expect your players to use a very small minority of the resources. If they use a majority of them, key/value stores is just more memory
rektbyfaith
07-18-2022, 08:31 PM #22Archived author: <o> • Posted: 2022-07-18T20:31:01.422000+00:00
Original source
that's the same consideration as doing it in memory, it's only worthwhile if you only expect your players to use a very small minority of the resources. If they use a majority of them, key/value stores is just more memory
Original source
the characters row itself is about 300 bytes to memory, but a single character takes up far more memory in practice, a few kb at least because of all the other fluff. Meanwhile, 1000 bits in a blob is 30 bytes
rektbyfaith
07-18-2022, 08:34 PM #23Archived author: <o> • Posted: 2022-07-18T20:34:03.596000+00:00
Original source
the characters row itself is about 300 bytes to memory, but a single character takes up far more memory in practice, a few kb at least because of all the other fluff. Meanwhile, 1000 bits in a blob is 30 bytes
Original source
for 10 million players, that's just 300mb
rektbyfaith
07-18-2022, 08:35 PM #24Archived author: <o> • Posted: 2022-07-18T20:35:06.394000+00:00
Original source
for 10 million players, that's just 300mb
Original source
Thinking back on it, I can reduce it to an std::map for players, and a single uint for non-players (gobjects, creatures) and just put them in the same phase if the players map[gobject template id] isn't false.
Actually two maps might be smarter, one for things which are revealed by default and one for things that are not revealed by default. I lose a lot of hypothetical functionality and make the scripts more linear but I can make due without it design wise.
rektbyfaith
07-18-2022, 08:45 PM #25Archived author: whatwere • Posted: 2022-07-18T20:45:51.477000+00:00
Original source
Thinking back on it, I can reduce it to an std::map for players, and a single uint for non-players (gobjects, creatures) and just put them in the same phase if the players map[gobject template id] isn't false.
Actually two maps might be smarter, one for things which are revealed by default and one for things that are not revealed by default. I lose a lot of hypothetical functionality and make the scripts more linear but I can make due without it design wise.
Original source
you don't need to replace the visibility system itself with your map extension, just extend it instead
rektbyfaith
07-18-2022, 08:49 PM #26Archived author: <o> • Posted: 2022-07-18T20:49:12.657000+00:00
Original source
you don't need to replace the visibility system itself with your map extension, just extend it instead
Original source
if you use key/value lookups for all visibility updates, you'll seriously degrade server performance
rektbyfaith
07-18-2022, 08:50 PM #27Archived author: <o> • Posted: 2022-07-18T20:50:16.663000+00:00
Original source
if you use key/value lookups for all visibility updates, you'll seriously degrade server performance