The discussion on IRC about this http://irc.minetest.net/minetest-hub/2019-01-03#i_5472569 started with:

benrob0329 has an idea for world portals in Lua

Is the only use case you have in mind portals? Note special portal effects can be done in many ways without this feature. How about creating a mesh with faces only on one side, then let backface culling do what you described on IRC? That can be done now.
How is your request related to portal appearence?
I'd like to see some actually useful use cases stated.

Could use it for:
An insanity mod where the player starts seeing things nobody else can see
An invisibility mod that lets staff see invisible players EDIT: Assuming the feature will be added to players objects too

I know random uses can be thought up, but it needs to have a need, and be significantly useful, those don't seem to be. Insanity can be done in many ways already, and one player seeing things can be done with particles. It has nothing to do with invisible players, players aren't entities.

Anyway, particles are visible per-player so they might be able to do what you want.

I get the feeling the feature would be a lot of work to create as it changes how entities are sent to clients. So it needs a lot of justification.

benrob 0329 it seems you have a specific use in mind for this, please could you state it? 'it would be nice' suggests no actual uses have been thought of.

• Hallucinations
• Teleportation Transitions
• World Portals
• @Jordach 's Title Screen in Solar Plains
• Mobs/Entities That Are Only Visible With A Special Item
• Clues That Are Only Revealed To Some Players
• Navigational Help For Specific Players
• An Area Effect Around Certain Players
• Per Player Sign Text

Similar per-player feature request: #5996 (nametags)

Sounds are already per-player, HUDs too. A nice start would be per-player particle spawners- oh wait, that exists too!
Most of the use-cases listed above can be implemented with already existing features. What's left over are per-player entities. I do not mention "visible" here because they may only be sent to players who can actually see them for 1) speed reasons 2) eliminating benefits of edited clients.

A use case I once considered was invisible enemies that you can only see if you equip a special item.

benrob0329, what needs/usecases were you thinking of before i asked for usecases? What needs/usecases made you open the request?
What do you absolutely need that cannot be done reasonably another way?

I'm trying to separate out usecases only thought up after i asked for them in a desperate attempt to justify the feature, which are therefore probably not actual needs you have. You seem to be trying too hard to justify this.
For example Ezhh has mentioned something she thought up previously, that's valid.

Why would world portals be dependent on per-player entity visibility?

Why is a game title screen relevant? That's also very low priority, you don't even know if Jordach needs this feature for that or could do it another way.
A title screen is 2D so can be done using a particle.

Most of your usecases can be done using stationary particles which are already per-player.
I'm getting an impression you need to make more effort to work within the current abilities of MT.
This request feels like #6996 , something specialist and low priority that you can probably already do another way.

The IRC discussion that led to this suggests an impulsive idea which made you open an issue before you actually spent some time modding and seeing if you can do it another way.
We have a huge number of requests and they need to carefully considered before opening, not opened casually as a result of a momentary vague idea.

Having written that, the feature may actually turn out to be useful and justified, but your request is lacking substance and stated need. It's too vague and casual.

benrob0329, what needs/usecases were you thinking of before i asked for usecases? What needs/usecases made you open the request?

• Making teleportation transitions (e.g. fading between two areas, even roughly)
• World Portals via duplicating a small portion of the area with entities

These are problems I've been trying to solve for some time now, for a mod I've technically been in the process of rewriting for some time (off and on over time).

Why is a game title screen relevant? That's also very low priority, you don't even know if Jordach needs this feature for that or could do it another way.
A title screen is 2D so can be done using a particle.

How can a 2D texture that will be visible for an arbitrary amount of time be done using a particle? Outside of respawning it every so often (which is a bit hacky to be honest). The point is that it's an already existing piece of content that could be enhanced by this (by only being visible to the player who needs to see it.

Particles cannot use 3D models, and cannot change textures arbitrarily, or be animated properly. They are generally very limited for the sorts of things people have been saying they would use this for.

Thanks. Those 2 are very specialist usecases so those seem low priority. Most modders would just use a simple effect for a portal as in the 'nether' mod. So those usecases have little relevance for others.

fading between two areas

Are you intending to place entities representing the destination around the player one by one?
If so, how about copying the player's surroundings to an used volume above y = 31000, teleporting the player there, then replacing the nodes one by one with nodes of the destination, then teleporting to the destination? It would be less intensive than using entities to represent nodes.

World Portals via duplicating a small portion of the area with entities

Maybe open a thread on the forum for ideas on how to do these 2 things another way, if indeed possible? Representing world with entities is quite possibly not a good approach.

Actually, a title sceen could probably be done better using a custom HUD element, particles might indeed be a bit hacky.

cannot change textures arbitrarily

Neither can entities.

I'm not saying particles can cover every usecase, i've never said that, i'm just pointing out most of the usecases you listed can be done with particles or other existng methods, as SmallJoker wrote.

I didn't think about teleporting the player to another place, however this does present the problem of having to fake other player's in the vicinity.

Entities can change the texture from code though, which is immensely useful for effects. Its a matter of opinion, but a well done effect (even if not particularly fancy) can make the apparent polish of a game or mod improve a ton.

@paramat Either way, you've acknowledged the use case I identify is genuine. I've simply never opened a request for it because I knew it would be low priority compared to many other more vital things, and would personally rather dev time goes elsewhere at the moment. Now that it is open, it should probably be left open (I'd suggest flagged low priority) for possible future discussion and figuring out exactly what would be needed from such a feature.

benrob0329 by the way, i'm sorry to have been so strict during this, and sorry i got the wrong impression about how well considered the request was.

Found this thread while ideating an equivalent for the "Vanish No Packet" Minecraft server plugin. I consider this an important additional use case.

In essence, this feature could allow privileged individuals (i.e. admins) to go completely invisible to other clients, with no network or world info about them being sent.

This would allow admins to observe potential cheaters without any possibility that the cheater can know they're being watched -- and thus turning off or hiding their cheats.

Implementation-wise, it would be nice if the flagging system was configurable i.e.

• The entity can be flagged as visible with exceptions (with a visiblity blocklist)
• The entity can be flagged as invisible with exceptions (with a visibility allowlist)

Made some experimental progress in a local branch: CivtestGame@6f6f80a

I noticed that attached entities appear where the invisible player would spawn, so I suppose I need to find a way to propagate the invisibility to those, too... probably not necessary as long as the wield plugin can query the player visibility state.

In essence, this feature could allow privileged individuals (i.e. admins) to go completely invisible to other clients, with no network or world info about them being sent.
This would allow admins to observe potential cheaters without any possibility that the cheater can know they're being watched -- and thus turning off or hiding their cheats.

This seems unrelated.
Firstly, players are not entites (Lua defined objects).
Also, this feature request is for 'per-player'. For your usecase all you need is a way for the admin to be invisible to all players, which might already be possible, or there is an unmerged PR.

Doesn't matter if players are not luaentities, both get sent across the wire in the same fashion, at least as far as this functionality cares. My impl uses ObjectProperties as the shared mechanism for including/excluding visibility.

Two birds, one stone. There's only a trivial difference (including implementation) between the cases of "show player/entity for player(s)" and "hide player/entity for player(s)" -- we solve all use cases by allowing both.

There's nothing in my search that led me to believe packet-level visibility exclusion is possible in an unmodified MT server. The only meaningful lead was this thread.

Can this be revisited? I'm happy to write the code as I expect it to be somewhat trivial
I want to be able to show entities that are meaningful on a per-player basis. One example is when showing bounding boxes (worldedit, protector, areas). Another example is my Blink mod showing a marker at the destination so a player can see where he/she will tp to. Alternatively, particles would suffice in both of these cases if I could manipulate them like I do entities (rotation etc)

Can this be revisited? I'm happy to write the code as I expect it to be somewhat trivial

I would be at least interested in this from not only the view point of per player entities, but also to send the packets for that entity specifically per player (use case tracers, etc, only wanting the player who shot to see them for example) and with a lot of players in the same area it would cut down on the network traffic needed

This has been requested years ago. Is it "wont fix"? or are there plans to implement it?

You might be able to somewhat badly implement this by sending different dynamic textures to different clients.

Yes, this is a dirty hack.

I want to point out another real-world need: In a mod I'm writing I've been thinking of spawning an entity to show an indication of how a block would be rotated when interacted with, depending on which side, edge, or corner the player is looking at. That is, I would like to show an axis and a arrow rotating around that axis. It wouldn't make a lot of sense if other players saw this hint that is only intended for one player.

edit: This is no longer just an idea, but actually a functional mod:

My thoughts:

• This should not be limited to visibility, but rather modders should be able to control whether an entity gets sent to other players at all. This is crucial both to deal properly with cheat clients and to limit network traffic. Also, it would open up nice possibilities where for example you could send an entity blocking an entrance to one player, but not to the others, creating a "barrier" for that player (I would need to check thoroughly, but I think this would not create any problems?).
• Stuffing this in object properties would work, but would probably end up pretty dirty and somewhat inefficient. This should be a separate set_observers method; other APIs that come to mind would be something like add_observer and remove_observer methods for managing observers.
• Care needs to be taken: When an observer is removed or added, that observer needs to be informed; when the engine sends CAOs in a radius, it needs to filter; we should probably preserve entities that are "visible to everyone" as a fast path. Furthermore, the parent of an attached object should always have a superset of the observers of its children.