[DiscordArchive] What spell has the visual?
[DiscordArchive] What spell has the visual?
Original source
okay so the disclaimer of course, this is just my opinion so don't hold me to anything and I just finished a 13hr work shift so I'm not all there atm
It seems like what you want to do is split up and thread the object updates inside of the map update, while yes the containers themselves COULD theoretically support it you're not really thinking of the interactions between the objects themselves. Like, what happens if you cast a spell on a player on another "update" thread? How would you even handle that? Let alone the dozens if not hundreds of other types of potential interactions that can occur in an object update. You can add copious amounts of locking which would very much just end up even slower than the existing system. I also don't really like the idea of threading the threads, feels quite counterproductive. Among that, this codebase already severely struggles as is with thread safety, I can't even imagine what kind of dark nightmares that could occur by significantly increasing the threading complexity.
If it was up to me, the absolute furthest I would risk going with changing the current threading model would be either a) threading individual zones to a separate map context (therefore no potential cross map interactions) or b) flat out clone an entire map to create a layer system. Both of which are going to require fairly extensive reworks to dozens of systems to enable that safely. However, regardless, I would _strongly_ encourage just optimizing the existing code way before that and only reach that point upon hitting enough diminishing returns. I very much believe in improving of existing code with logical optimizations is safer, easier, and just ultimately the better solution rather than throwing threads on everything and dealing with the consequences. There are LOTS of very significant optimizations that are easily achievable. I think you'd be shocked at what is possible especially on a modern CPU. This is ultimately an early 2000s game after all
rektbyfaith
01-17-2025, 03:18 PM #21Archived author: Takenbacon • Posted: 2025-01-17T15:18:39.283000+00:00
Original source
okay so the disclaimer of course, this is just my opinion so don't hold me to anything and I just finished a 13hr work shift so I'm not all there atm
It seems like what you want to do is split up and thread the object updates inside of the map update, while yes the containers themselves COULD theoretically support it you're not really thinking of the interactions between the objects themselves. Like, what happens if you cast a spell on a player on another "update" thread? How would you even handle that? Let alone the dozens if not hundreds of other types of potential interactions that can occur in an object update. You can add copious amounts of locking which would very much just end up even slower than the existing system. I also don't really like the idea of threading the threads, feels quite counterproductive. Among that, this codebase already severely struggles as is with thread safety, I can't even imagine what kind of dark nightmares that could occur by significantly increasing the threading complexity.
If it was up to me, the absolute furthest I would risk going with changing the current threading model would be either a) threading individual zones to a separate map context (therefore no potential cross map interactions) or b) flat out clone an entire map to create a layer system. Both of which are going to require fairly extensive reworks to dozens of systems to enable that safely. However, regardless, I would _strongly_ encourage just optimizing the existing code way before that and only reach that point upon hitting enough diminishing returns. I very much believe in improving of existing code with logical optimizations is safer, easier, and just ultimately the better solution rather than throwing threads on everything and dealing with the consequences. There are LOTS of very significant optimizations that are easily achievable. I think you'd be shocked at what is possible especially on a modern CPU. This is ultimately an early 2000s game after all
Original source
I thought about the interactions between objects, which is why I came up with this two stages update. Here is an example where the dots represent players trying to cast a spell on another player. The scenario with the red dots shouldn't be possible, while the others should work fine.
![[Image: norace.png?ex=690c1b69&is=690ac9e9&hm=e1...9ebf5e420&]](https://cdn.discordapp.com/attachments/284323424032129024/1329840695908765829/norace.png?ex=690c1b69&is=690ac9e9&hm=e194fe90c0a5cfd7fc8920605e7caae601c0991a492f5a0721643899ebf5e420&)
rektbyfaith
01-17-2025, 03:52 PM #22Archived author: walkline • Posted: 2025-01-17T15:52:09.164000+00:00
Original source
I thought about the interactions between objects, which is why I came up with this two stages update. Here is an example where the dots represent players trying to cast a spell on another player. The scenario with the red dots shouldn't be possible, while the others should work fine.
Original source
Also, no additional locking required other then those two waits in pseudocode.
And in general, for me it doesn't look like ground-breaking change. And this logic can be hiden behind a config option.
rektbyfaith
01-17-2025, 03:54 PM #23Archived author: walkline • Posted: 2025-01-17T15:54:51.184000+00:00
Original source
Also, no additional locking required other then those two waits in pseudocode.
And in general, for me it doesn't look like ground-breaking change. And this logic can be hiden behind a config option.
1 Guest(s)
1 Guest(s)