[DiscordArchive] Oh, that's a nice list, thanks!
[DiscordArchive] Oh, that's a nice list, thanks!
Original source
Oh, that's a nice list, thanks!
The idea is to parallelize the updates for players and units on the map. But the rest would still be handled in a single thread, either before or after the players and units update
For example:
```
void Map::Update(diff)
{
// ... see prev example
// parallel processing below
for i in phase1PlayersLists.len():
this->continentUpdateWorkers->ScheduleUpdate(diff, phase1PlayersLists[i], phase1NonPlayersLists[i]);
this->continentUpdateWorkers->wait();
for i in phase2PlayersLists.len():
this->continentUpdateWorkers->ScheduleUpdate(diff, phase2PlayersLists[i], phase2NonPlayersLists[i]);
this->continentUpdateWorkers->wait();
// parallel processing ended
// update transports here
// update creatures respawn/pooling?
// other update related operations
}
```
There could be some issues, but maybe we can review them one by one?
So, let's take battlefield and zone scripts — indeed, I believe most scripts would need some locking. Thanks for pointing that out; I hadn't thought about them.
Pooling, I believe, would be handled in a single thread, right? Or would pooling updates be triggered by player actions during the map's player/session update? If so, that's another issue that needs to be addressed with synchronization.
Adding/removing objects: Can adding and removing happen during the object update loop? If so, again, locking would be necessary.
Groups, I guess, should be safe since they are handled outside of the map thread. However, they might require some changes when broadcasting player field updates in the map thread.
Spells... I can see an issue where a caster of a long-term aura might be in a parallel update zone from the woner, so that would need to be addressed as well. Anything else?
Transports would be handled outside of the player/unit updates, right?
rektbyfaith
01-17-2025, 07:16 PM #1Archived author: walkline • Posted: 2025-01-17T19:16:42.603000+00:00
Original source
Oh, that's a nice list, thanks!
The idea is to parallelize the updates for players and units on the map. But the rest would still be handled in a single thread, either before or after the players and units update
For example:
```
void Map::Update(diff)
{
// ... see prev example
// parallel processing below
for i in phase1PlayersLists.len():
this->continentUpdateWorkers->ScheduleUpdate(diff, phase1PlayersLists[i], phase1NonPlayersLists[i]);
this->continentUpdateWorkers->wait();
for i in phase2PlayersLists.len():
this->continentUpdateWorkers->ScheduleUpdate(diff, phase2PlayersLists[i], phase2NonPlayersLists[i]);
this->continentUpdateWorkers->wait();
// parallel processing ended
// update transports here
// update creatures respawn/pooling?
// other update related operations
}
```
There could be some issues, but maybe we can review them one by one?
So, let's take battlefield and zone scripts — indeed, I believe most scripts would need some locking. Thanks for pointing that out; I hadn't thought about them.
Pooling, I believe, would be handled in a single thread, right? Or would pooling updates be triggered by player actions during the map's player/session update? If so, that's another issue that needs to be addressed with synchronization.
Adding/removing objects: Can adding and removing happen during the object update loop? If so, again, locking would be necessary.
Groups, I guess, should be safe since they are handled outside of the map thread. However, they might require some changes when broadcasting player field updates in the map thread.
Spells... I can see an issue where a caster of a long-term aura might be in a parallel update zone from the woner, so that would need to be addressed as well. Anything else?
Transports would be handled outside of the player/unit updates, right?
Original source
So yeah, it doesn't look like the low-hanging fruit I thought it was.
I would say it's manageable, but enough for me to shelve this idea for a while.
Again, thanks for the feedback!
rektbyfaith
01-17-2025, 07:17 PM #2Archived author: walkline • Posted: 2025-01-17T19:17:09.017000+00:00
Original source
So yeah, it doesn't look like the low-hanging fruit I thought it was.
I would say it's manageable, but enough for me to shelve this idea for a while.
Again, thanks for the feedback!
Original source
Still in progress, the next update will include battlegrounds implementation with crossrealm support
rektbyfaith
01-17-2025, 07:20 PM #3Archived author: walkline • Posted: 2025-01-17T19:20:03.136000+00:00
Original source
Still in progress, the next update will include battlegrounds implementation with crossrealm support
Original source
Looking forward to that.
rektbyfaith
01-17-2025, 07:38 PM #4Archived author: Honey • Posted: 2025-01-17T19:38:27.379000+00:00
Original source
Looking forward to that.
Original source
I'd just started looking into how to do this, not realizing there was already work done on it. I'd be interested in testing it out. I ran into some issues adding it to my flake.nix, like it making a duplicate nixpkgs in my lock file. I'm still new to nixos so not sure why that's happened.
rektbyfaith
01-19-2025, 08:14 PM #5Archived author: descention • Posted: 2025-01-19T20:14:03.571000+00:00
Original source
I'd just started looking into how to do this, not realizing there was already work done on it. I'd be interested in testing it out. I ran into some issues adding it to my flake.nix, like it making a duplicate nixpkgs in my lock file. I'm still new to nixos so not sure why that's happened.
Original source
That’s normal, the nixpkgs it copied is the one with the flake
rektbyfaith
01-19-2025, 08:17 PM #6Archived author: numkem • Posted: 2025-01-19T20:17:02.075000+00:00
Original source
That’s normal, the nixpkgs it copied is the one with the flake
Original source
It’s probably not working as I wasn’t able to patch to use MySQL and not mariadb
rektbyfaith
01-19-2025, 08:17 PM #7Archived author: numkem • Posted: 2025-01-19T20:17:47.702000+00:00
Original source
It’s probably not working as I wasn’t able to patch to use MySQL and not mariadb
Original source
I don't think I'm getting that far. <#1330631382698823690>
rektbyfaith
01-19-2025, 08:26 PM #8Archived author: descention • Posted: 2025-01-19T20:26:19.736000+00:00
Original source
I don't think I'm getting that far. <#1330631382698823690>
1 Guest(s)
1 Guest(s)