Jump to content

Edit History

Please note that revisions older than 365 days are pruned and will no longer show here
zztong

zztong

26 minutes ago, vbnet3d said:

My impression, and this is a bit rough, is that it runs all the volumes in the current chunk, during each Tick() cycle.

--

For perspective - 50-100 distance checks is still pretty trivial for most systems

 

I see. These volume checks, they would be per-player, right? If so, then 8 players means 50 becomes 400? Perhaps not that bad if players are moving around together. Then maybe you can mark a volume and avoid processing it again, somehow... err, that sounds problematic though I'm not sure why. (Probably because players rarely stick together by distances that would be relevant in this case.)

 

I'm trying to imagine a "worst case" ... 8 players, each driving a 4x4 at top speed through their own city's downtown district. They're all changing chunks quickly and there's a large number of volumes per chunk. Obviously, some servers allow more than 8 players, but uhhh, yeh.

 

Then, IIRC, there's a limit to the number of sleepers the game can have at any one time. I think hitting that shuts down sleeper spawns. If that's true, then oddly enough, maybe it could also be a signal to shut down the evaluation of some kinds of zombie volumes, or maybe that's bad...?

 

Quote

I have considered optimizing by only running the logic every other Tick(), but it seems to me that the actual spawn logic is actually what hits performance rather than the checks.

 

Would it help if, after you determined distance and found a volume to be far away, that you flagged it to "skip" some number of ticks before being evaluated again? Like, if it's 100 blocks away, skip the next 3 ticks, but if it's 50 blocks away just skip the next one.

zztong

zztong

25 minutes ago, vbnet3d said:

My impression, and this is a bit rough, is that it runs all the volumes in the current chunk, during each Tick() cycle.

--

For perspective - 50-100 distance checks is still pretty trivial for most systems

 

I see. These volume checks, they would be per-player, right? If so, then 8 players means 50 becomes 400? Perhaps not that bad if players are moving around together. Then maybe you can mark a volume and avoid processing it again, somehow... err, that sounds problematic though I'm not sure why. (Probably because players rarely stick together by distances that would be relevant in this case.)

 

I'm trying to imagine a "worst case" ... 8 players, each driving a 4x4 at top speed through their own city's downtown district. They're all changing chunks quickly and there's a large number of volumes per chunk. Obviously, some servers allow more than 8 players, but uhhh, yeh.

 

Then, IIRC, there's a limit to the number of sleepers the game can have at any one time. I think hitting that shuts down sleeper spawns. If that's true, then oddly enough, maybe it could also be a signal to shut down the evaluation of some kinds of zombie volumes, or maybe that's bad...?

zztong

zztong

24 minutes ago, vbnet3d said:

My impression, and this is a bit rough, is that it runs all the volumes in the current chunk, during each Tick() cycle.

--

For perspective - 50-100 distance checks is still pretty trivial for most systems

 

I see. These volume checks, they would be per-player, right? If so, then 8 players means 50 becomes 400? Perhaps not that bad if players are moving around together. Then maybe you can mark a volume and avoid processing it again, somehow... err, that sounds problematic though I'm not sure why.

 

I'm trying to imagine a "worst case" ... 8 players, each driving a 4x4 at top speed through their own city's downtown district. They're all changing chunks quickly and there's a large number of volumes per chunk. Obviously, some servers allow more than 8 players, but uhhh, yeh.

 

Then, IIRC, there's a limit to the number of sleepers the game can have at any one time. I think hitting that shuts down sleeper spawns. If that's true, then oddly enough, maybe it could also be a signal to shut down the evaluation of some kinds of zombie volumes, or maybe that's bad...?

zztong

zztong

22 minutes ago, vbnet3d said:

For perspective - 50-100 distance checks is still pretty trivial for most systems

 

I see. These volume checks, they would be per-player, right? If so, then 8 players means 50 becomes 400? Perhaps not that bad if players are moving around together. Then maybe you can mark a volume and avoid processing it again, somehow... err, that sounds problematic though I'm not sure why.

 

I'm trying to imagine a "worst case" ... 8 players, each driving a 4x4 at top speed through their own city's downtown district. They're all changing chunks quickly and there's a large number of volumes per chunk. Obviously, some servers allow more than 8 players, but uhhh, yeh.

 

Then, IIRC, there's a limit to the number of sleepers the game can have at any one time. I think hitting that shuts down sleeper spawns. If that's true, then oddly enough, maybe it could also be a signal to shut down the evaluation of some kinds of zombie volumes, or maybe that's bad...?

zztong

zztong

11 minutes ago, vbnet3d said:

For perspective - 50-100 distance checks is still pretty trivial for most systems

 

I see. These volume checks, they would be per-player, right? If so, then 8 players means 50 becomes 400? Perhaps not that bad if players are moving around together. Then maybe you can mark a volume and avoid processing it again, somehow... err, that sounds problematic though I'm not sure why.

 

I'm trying to imagine a "worst case" ... 8 players, each driving a 4x4 at top speed through their own city's downtown district. They're all changing chunks quickly and there's a large number of volumes per chunk. Obviously, some servers allow more than 8 players, but uhhh, yeh.

 

Then, IIRC, there's a limit to the number of sleepers the game can have at any one time. I think hitting that shuts down sleeper spawns. If that's true, then oddly enough, it could also be a signal to shut down the evaluation of some kinds of zombie volumes.

×
×
  • Create New...