Terasology: A held light source in multiplayer does not appear for other players

[Cervator]

What you were trying to do

Test unrelated stuff in multiplayer. Since the game started in the dark I had both connected players (to a local headless server) hold torches to see things. I was expecting player 1 would then have an easy time seeing player 2 with a held torch

What actually happened

The held torch for the player other than the local client did not give off any light. A placed torch from the other player would light up fine, just a held torch would only yield light on the local client.

Same situation with a server/client + client only

How to reproduce

• Run two instances of the game
• Join together in multiplayer
• Note the absence of light in the environment when the other player is holding a torch

Theory

The logic behind held items have been a hot topic for some time with regular changes, especially related to entity replication over the network in multiplayer. Since the held item on a client is only visible on that client probably at some point that was made too local and no longer replicates fully if at all. Probably this isn't actually rendering related, the light isn't being rendered because the engine doesn't know it is supposed to be there (for other clients)

This is also wrong in another way as past proof of concept code (see #2115 and #2133) needs some entity information that might at first glance seem local, but could be used to visually display extras on another visible player in multiplayer, like posing the head of the model in the direction the player is facing or indeed show the item they are wielding attached to their model

Search for classes with the word Held in the name for the related code and consider doing the same in the issue tracker, especially for closed issues, to see what other changes have been made over time :-) Be especially mindful of having a player log off and back on repeatedly to verify all is still well, and check out location 0,0,0 in the world as past held item issues have resulted in an orphan item appearing there. Test both headless + 2 players and hosting player + client player.

See https://metaterasology.github.io/docs/developing/networkMultiplayer/networkMultiplayer.html for some related documentation

While I think this could be a good first issue in some cases be warned that it may take a bit more research and testing than most beginner friendly issues, and a computer able to at least run two game clients at the same time :-)

Edit: Screenshot

[dorasun]

A friend and I tested this on the unstable multiplayer server (we were both testing on MacOS, 10.11.6 and 10.12.5) and we noticed that, as you mentioned, you can't see any items anyone else is holding. We took a look at the two files with the word 'held' in them (ChangeHeldItemRequest.java and BuilderHeldItemAuthoritySystem.java), as you suggested, but aren't seeing any way to edit the actual models. If you don't mind, could you point us in the direction of the user model? I did a search on IntelliJ and got too many results for just 'model', and I'm not sure what the correct term is.

[Cervator]

Hey again @dorasun :-)

Here are some more details - most importantly there are two related topics in play here:

1) Visually showing an item held by another player in multiplayer - this is a substantial challenge, with lots of research needed with the linked issues above included
2) Correctly showing the effect of a held item in multiplayer. The subtle difference there is that in the case of holding a torch I believe the scenario used to be that by holding a torch (or any item that is a light source) the player entity itself would end up with a LightComponent meaning essentially the player model itself would light up the surroundings

The 2nd item is far simpler to approach than the 1st. Imagine that the mere act of holding a torch is making the holding player itself into a light source, rather than it being the physical held torch itself that's causing the light.

In other words with full completion of the 1st item you would end up with the following two entities:

1) The entity of the item being held, complete with its visual appearance, position and rotation relevant to the player holding it, any light source or other effects coming off it (like particles etc). Other players could see this item rendered fully in the world.
2) The entity of the player itself, separate from the held item. This entity wouldn't give off light at all, nor other effects that would come from the held item. It would simply represent the player's body itself.

As nice as it would be to get the 1st item completed we've so far cheated by simply saying "If the player is holding a torch, make the player a light source"

What I think happened is that the logic for dealing with the held item (entity) has changed from time to time between being replicated to the server (so it in theory could be seen by others) or being purely a local phenomenon that you only consider on the client.

When the data was replicated to the server we would sometimes end up with the independent item "getting stuck" in various places in the world, like at 0,0,0

• The most recent fix: just make the logic purely local (probably, I'm guessing)
• The bug: oops, now the fact that a player is holding a torch isn't having any impact on the light level when viewed by other players.
• Likely fix: review past efforts to see how this used to work, find a way to make it work again without ending up with that independent item showing up orphaned somewhere in the world. Like simply attaching a LightComponent to the player itself when wielding an item that provides light, then taking it off again when no longer holding such an item

Hopefully that helps. Although at some point maybe we'll end up having spent more effort "cheating" with a simple intermediary solution rather than just make the full option 1 work :-)

Up to you if you want to try it the "easy" way or the "hard" way!

[dave2s]

Hello everyone,

I am happy to announce that I've made some progress regarding this issue. I have a created a proof of concept fix for this issue, which includes remote players held items as well. I'll be creating a PR in the upcoming weeks, so If any one of you is still trying to wrap your head around this, it might be best to wait.

The way I went about this is I took @Josharias 's firstPersonClientSystem concept and forked it so it takes care of other players in a multiplayer session. This includes remote player mountpoint and transform components (with the difference of mountpoints being attached to remote character instead of local camera).

Every client then has a remote player system which handles all other clients in a multiplayer session,

• attaches mountpoints to them
• attaches held items to the mountpoints
• takes care of the transformations

update 24.4.2018: #3337 PR that fixes this issue

[Cervator]

Missed closing this earlier. Complete :-)