[SOLVED][1.7.10] question about preventing entity "despawning"

[jabelar]

I put "despawning" in quotes because I think my problem isn't true despawning as I'll explain below.

 

I have a custom eagle entity which is working quite well -- it can fly up to a soaring height, then soar around high in the air, dive to attack prey, find perches and even be tamed.

 

However, one problem I'm having I can't seem to figure out. I think it has to do with de-spawning.

 

Basically if the eagle is far away it disappears. I believe this is standard de-spawn behavior. I don't want this for two reasons -- due to the eagle already being high up it seems to disappear frequently (I think because the distance is greater due to it being in the air) and also don't want it to despawn when tamed.

 

So I thought it would be as simple as overrideing the canDespawn() method, checking for being tamed and distance and only calling super method if I'm willing to allow despawn.

 

It still seemed to despawn though, so I tried to print console statements in the canDespawn() method but that spammed the console because it is checked every tick. So instead I overrode the setDead() method and just put in a console statement there and found something interesting -- the setDead() was only being called on the client when the entity was disappearing. I thought that was odd, because I expect setting dead would originate on server. It also causes real problems because the server continues to send packets for that entity which now can't be found on the client.

 

Furthermore it was interesting that it was being called at all because I had the canDespawn() returning false.

 

So basically it seems that the setDead() method is being called on the client by something other than the despawn code. Any theories on why the client would setDead() on its own while the server continues to think entity is alive and no despawn check called?

 

To further investigate I overrode the setDead() to not call super method -- i.e never set dead. When that happens, if the eagle is far away it suddenly stops in mid-air, then if I get closer a duplicate appears that is flying where it should be!

 

All this seems to indicate that client is setting dead when the player is at some distance from the player, but server doesn't agree and keeps entity alive.

 

I'm probably missing something fundamental -- but I really thought that simply overriding canDespawn() would be sufficient. I also tried overrideing the AllowDespawn event to give result.DENY but the entity still got set dead.

[jabelar]

Yeah, that was it. I forgot about the tracking distance in the registration. I had it at 80 which wouldn't even cover the soaring height...

[coolAlias]

You can also call 'func_110163_bv()' in your entity constructor to make it persistent. In 1.8, this is aptly named 'enablePersistence()'.

[jabelar]

You can also call 'func_110163_bv()' in your entity constructor to make it persistent. In 1.8, this is aptly named 'enablePersistence()'.

 

That's interesting, thanks.

 

However my problem actually wasn't despawning. I think despawning is server side deciding to cull unneeded entities based on distance from player and age, etc. However the client also seems to use the tracking range parameter in the entity registration to independently (not through despawn methods) set the entity to dead, just on the client side.

 

In other words, I think the entity is still existing on the server but was just killed on the server. When you get close enough (within tracking range I guess), the client seems to create a new entity to track the one that the server had kept.

 

It kinda makes sense, but was a surprise to me.

 

Basically the trace was like this:

- constructs successfully on both server and client when spawned with egg.

- packets happily sync the entity AI state on the client as long as you stay close

- server checks despawn every tick as evidenced by event and canDespawn() method both being called. client doesn't do any despawn check.

- if you get far (which wasn't that far in my case due to high posY of the entity) the entity is setDead() only on client side, without going through the despawn event or canDespawn() method.

- packet system starts complaining that it can't find the entity I was sending info about.

- when I get close to the (now invisible) entity it re-appears on client.

- if I prevent the client from setting dead, instead of it going invisible it just stops in place, and when I get close it spawns a second entity which acts normally (but original is still "stuck" in place).

- setting the tracking range really large (800000) fixed all this.

[Draco18s]

That's called "view distance culling."

[jabelar]

That's called "view distance culling."

 

Yes, and it also seems to be to reduce network traffic as well since it is also a "tracking" distance. I had previously thought that despawning was used for view distance culling as well, but found that they are separate.

 

I think it is interesting that the client actually kills the entity when it does view distance culling though. I think most video games simply don't render it but would still keep it alive (but suspended). As mentioned the way the client actually kills the entity causes me some grief because the server keeps sending my custom packets assuming it is still there (since the entity is still alive on the server).

 

Oh well, now I know.