Whatever became of it? It was supposedly in the works before getting abandoned and while lurking seems to reveal some references to it there isn’t much else.
My aim is to create a “Wynncraft-like” MMO running SpongeForge, but not being able to manipulate entity visibility in reference to players is a big hurdle in achieving that. I’m sure there’s a chance I’m completely off and it’s somewhere in the API, but so far I’m clueless.
So a little context. This is the issue being referred to im guessing
It was designed to take a player and make them look like hunan (allowing custom names and custom skins) but it was not designed to hide players from anothers view. It was often referenced to requests for per player entity view as it was very much connected (laying down the land essentially).
It was however cancelled for being way to ambitious for the time, however this was back in api 7.
Since then api 8 for all the mc’s was planned and then released. While entity per client view is still missing from api 8, there is now VanishState which allows for extra options on Vanish. So maybe over time.
If i was you i would create a issue on github for it, shows demand for it. I do already have a issue for it, but it was for api 7 and was lost to time.
I see. So would you advise that I just create an issue identical to the one that was made before? I admittedly don’t have much knowledge of the terminology so I’d hope that creating the issue would be able to communicate the need for it without mislabeling the functionality like I just did here.
The one i created was asking for more, as it was asking for all entities and tile entities to be fudged.
By asking for just player only is a much more bytesized meal for someone to take on. What shows a real want for something is talk about a given subject and/or a obvious demand for it such by giving a thumbs up on a github issue board.
That being said, i cant guarantee someone will pick it up
The real core problem is writing an API and implementing it to be something maintainable. I’d say keeping the API breadth small so that one could feasibly say “I want to be able to change the data for entities with relation to a viewer” wouldn’t be too big.