urban turtle
The illusion entity contains UUIDs of other entities which are allowed to render it...
So if its in an illusion state it can choose who it can be rendered by
(next up is AI, shadow, sound, particles, etc. but the data handling and networking is done)
also works on players and since its using client side caching, at runtime uses entity networkIDs and stores the data as UUID when necessary, it should be persistent and somewhat performant :)
@ivory wedge iirc you wanted a ping?
i kinda gave up on canceling exisitng network packets. I just did it with custom packets to update the states and avoiding the rendering with that
ivory wedge
any reason the hitbox remains visible?
urban turtle
most likely because of the injection point...
Shouldnt be too difficult to fix... Entity Shadow is the same
also i think ill probably keep rendering the hitbox for players with the right permission levels
urban turtle
also looking into making a simple voice chat compat on that one...
craggy thistle
you see no pig because you think no pig. No thought no sight. True hearts find their path, and the pig is on that path
ebon fiber
The illusion entity contains UUIDs of other entities which are allowed to render...
Cool. Will illusions interact with the world (for instance pressure plates and such)?
That’s a problem I had with mine when I did something similar; I just had whether they should render be based on if the player had the right potion effect.
To be fair - it was still hilarious to get the “hallucinating” effect and have a bunch of hallucinated creepers spawn all over the place. I just didn’t fully release it since I couldn’t figure out how to make them not interact with anything.
urban turtle
sounds like some simple mixins 
but yeah, right now im on AI adjustments, so that illusions won't be tracked if the other entity isnt their target
ebon fiber
sounds like some simple mixins <:thonk:875068610459095101>
What sort of places would you recommend mixing into?
urban turtle
you would have to make out which blocks interact with entities without their active input.
Most of them are probably activated with Entity collisions.
So you can go up the inheritance chain to where the method is defined / used and avoid its call... something like Entity#checkBlockCollision's blockState.onEntityCollision(...)
i havent tried that yet but thats how i would approach it
urban turtle
ai target selection is done... i did try to mixin into ActiveTargetGoal predicates n stuff until i found out that there is already the canTarget method on LivingEntities 
ebon fiber
you would have to make out which blocks interact with entities without their act...
The problem is, the hallucinated entity still needs to have collisions. It can’t just fall through the floor. But, I also can’t guarantee that the collision checking method is side-effect-free.
urban turtle
AbstractBlock#onEntityCollision doesnt seem to handle solid block collision handling... it just handles the side effects like arrows on a button or entities burning in fire blocks
