Terasology: Host Items at (0,0,0)

Created on 14 Nov 2016  路  7Comments  路  Source: MovingBlocks/Terasology

What you were trying to do:
I was investigating physics on a client.

What actually happened:
While working on said physics (and items going through the ground), I saw an entity really low in the ground (with the client). After getting there, I saw it was an axe that I tried to collect and couldn't. I changed the item on the host to a torch to also go down and investigate, and now the client saw a torch (host doesn't see anything)

How to reproduce:

  1. Join a local server (not headless) with a client.
  2. Go to (0,0,0).
  3. Observe the host wielded item.

Details:
I only had Core+CheatsForAll active

Architecture Bug Multiplayer

Most helpful comment

I found the reason for this:

As soon as a player picks up an item, the host removes some components from the item and adds the entity reference to the authority inventory. The location component is removed, but not the mesh component. The linkItemsSomething method in the FirstPersonClientSystem then adds a location again. That's why the block is displayed at (0, 0, 0).

I'll keep investigating why the client system adds a location to a server entity and how to avoid this. That should fix the problem.

EDIT:
The servers "client" (local player) adds the location component that's the reason why the block is rendered.

All 7 comments

I'd be interested in working on this.

As far as I can tell the wielded items are not visible to other players at the moment?

So the host wielded item is incorrectly replicated to the clients.

I found the reason for this:

As soon as a player picks up an item, the host removes some components from the item and adds the entity reference to the authority inventory. The location component is removed, but not the mesh component. The linkItemsSomething method in the FirstPersonClientSystem then adds a location again. That's why the block is displayed at (0, 0, 0).

I'll keep investigating why the client system adds a location to a server entity and how to avoid this. That should fix the problem.

EDIT:
The servers "client" (local player) adds the location component that's the reason why the block is rendered.

Re-opening this as reverted by #2806 - see it for details. In short this ended up causing some other problems, although it still may be a viable fix. The Components filtered may just need some adjustment, but it will need some more thorough testing to make sure it is a clean fix :-)

May also be of interest to @iojw or even @xrtariq2594 since it is about networking and may somewhat relate to similar oddities about synchronized entity state (like the crash on trying to upgrade a wood workstation in NeoTTA)

Hi @Tropid! Hoping you're still around and might be interested in looking at the added challenges within this fix :-)

Screenie to help explain the issue for those having a hard time visualizing it (like me at first):

2017-03-05 00_14_01-terasology - c__dev_terasology_git_terasology - engine - _engine_src_main

That was some time ago, but as far as I remember this is what I did:

Previous State:

  • An entity which can be picked up will be added to the inventory of the player
  • Depending on whether it is selected in the toolbar it will be shown or hidden by adding/removing the MeshComponent (not quite sure, maybe it's also the RenderComponent)
  • Somehow the location component was removed on the clients (or only added on the host? I can't remember)
  • Overall it was rather complex and difficult to understand in my opinion

Therefore I applied the following changes:

  • When an item is picked up it is added to the inventory like before
  • Additionally a client-only copy of it will be created which is responsible for client-side display
  • Components which are not needed for display will be removed from the copy (this includes the components which are responsible for emitting light, see #2788)
  • When the item is selected the client-side entity will be attached to the player and shown to the client only

I suggest following changes, which I will submit as a PR soon (I'm sorry I can't spend a lot of my time as I'm currently writing my master's thesis):

  • Same approach as before, but instead of only keeping the components responsible for rendering (whitelist), I will only remove the unneeded components (blacklist)
  • This applies to:

    • NetworkComponent: Prohibit replication of client-side entity

    • RigidBodyComponent: Prohibit held item dropping to the ground after selection

I still prefer copying the held item, as I think it makes reasoning about it a lot easier. Otherwise the entity in the inventory is the same entity which is shown to the player and there are a lot of different things affecting the behavior.

Maybe PR #2789 is also interesting in this context, as it overhauls the inventory system.

Thanks for the response @Tropid ! I was wondering if switching to a blacklist might help, just didn't have the time to try it out. Would be happy to see a follow-up PR :-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Kubuxu picture Kubuxu  路  4Comments

stefaniamak picture stefaniamak  路  5Comments

Qwertygiy picture Qwertygiy  路  6Comments

Cervator picture Cervator  路  3Comments

chriscamacho picture chriscamacho  路  3Comments