Turning Zone wide mob spawning into shard-only visible per client

[Shin Noir]

Howdy,
If a dev more familiar wanted to give me their thoughts on the difficulty (or a suggestion of how to tackle this), it's hugely appreciated:

I'm messing with a server called TheoryQuest. Inside it, I'm planning to remove Track for all classes (including Ranger). This opens up the ability for not spawning every mob in a zone as EQ normally does.

Pros: You can't use MQ to see every mob up.
Pros: Less load on the client since less mobs on zone.
Cons: Running through a zone means more packets need to be sent to the client to inform what mobs are up.
Cons: Dev time

How tough would it be to make EQEMU not provide all spawns to a zone at load in, and instead load mobs as you get near to them? Is this a huge undertaking, and I may not want to bother with it? Any shortcuts I can maybe take?

That's about it, thanks for taking the time to read my post.

[lerxst2112]

The concept of a "perception bubble" is not terribly complex for a simple implementation assuming the client knows about entities in a circular region around itself. It can get quite a bit more complicated if you exclude information based on stuff like line of sight, z-height, etc. but there's generally not a ton of benefit to doing that.

The problem you might run into is the client. Usually there's some cooperation needed between client and server to make sure they agree on things like number of entities and having the client be able to request more information from the server if for instance it gets a movement update for an entity it doesn't know about. The client can also be a bit proactive about despawning entities that are out of range without the server specifically telling it to.

I haven't used ShowEQ or MQ2 on a live server for a while, so they may already have a system that does this. It always seemed like the next logical step to combat ShowEQ during the time where they were actively trying to stop it.

[Shin Noir]

The concept of a "perception bubble" is not terribly complex for a simple implementation assuming the client knows about entities in a circular region around itself. It can get quite a bit more complicated if you exclude information based on stuff like line of sight, z-height, etc. but there's generally not a ton of benefit to doing that.

The problem you might run into is the client. Usually there's some cooperation needed between client and server to make sure they agree on things like number of entities and having the client be able to request more information from the server if for instance it gets a movement update for an entity it doesn't know about. The client can also be a bit proactive about despawning entities that are out of range without the server specifically telling it to.

I haven't used ShowEQ or MQ2 on a live server for a while, so they may already have a system that does this. It always seemed like the next logical step to combat ShowEQ during the time where they were actively trying to stop it.

I normally use MQ, it seems if you aren't near an entity the update packets of where the entity is located (if it's moving) is looser, e.g. you may only get an update packet every 12-24s instead of instantly, I've never seen an entity not sent to the cilent..

I have a rough idea of how to implement this, and yeah, not trying to depop the non-LOS or anything complicated like that, more just trying to stop cross-zone targetting and knowledge. Probably like a ~1k radius (or a reasonable view distance in an open field number) of spawned entities..

if it's too complicated, I may just drop the idea. But it'd be nice to lessen the benefits of MQ.

[Drajor]

http://www.eqemulator.org/forums/showthread.php?t=26389 May interest you.

[Uleat]

I ran across a long-lost posting about this when I was scouring the forums some time ago...

I can't remember if it was here, peqtgc, or some other website..but, if I manage to run across the link, I'll post it.


EDIT: Ok..this is just freaky... I'm leaving this post here just for the hilarity of it. (Missed it by..that much!)

[Zaela_S]

Could possibly run into some odd situations when one client is aware of a mob and another isn't. Not sure if it would be serious, but one way or another clients will be receiving data (via /assist or whatever) for entity IDs of mobs they don't know about. Don't want to think about XTargets ;p

[lerxst2112]

They way I've seen it handled in other games is for all members of a group/raid to share visibility data.

[Drajor]

There are bunch of edge cases I can think and there's probably many more. It will be no trivial thing to get it working IMO. Lol @ Uleat!

[Shin Noir]

Thanks everyone who gave input about this topic, I appreciate any time spent thinking or giving suggestions about it.

From what I can conclude, seems it likely will be a difficult change to set up, especially due to no clear cut route to execute (as it is against the client's design principle).

Since it isn't a huge priority, I'll likely not put too much resources in it at this time.