[Solved] RenderLayer not rendering on multiplayer

[Cadiboo]

2 hours ago, V0idWa1k3r said:

It would be easiest to do with a one-line stream

Pseudo-code:

ForgeRegistries.ITEMS.valueCollection().stream().filter(i -> i.getRegistryName().getDomain().equals(MYMODID)).foreach(i -> ModelRegistry.setCustomModelResourceLocation(...))

https://gist.github.com/Cadiboo/3f5cdb785affc069af2fa5fdf2d70358

[Oscarita25]

i did overhaul my capabilities and stuff and made the packets update the capabilities when their values changed but the problem of the problem of other players not seeing the model still persists .. am i sending the packet wrong again? 

 

the parrot (placeholder model) should be displaying for the other player too

 

 

here the repo again : https://github.com/Oscarita25/BNHA
 

this is in my capability : 

 

	@Override
	public void synchronize() {
		if(this.player instanceof EntityPlayerMP){
			BNHA.NETWORK.sendTo(new MessageModel(this.model), (EntityPlayerMP) this.player);
			BNHA.NETWORK.sendToAllTracking(new MessageModel(this.model), (EntityPlayerMP) this.player);
		}				
	}

 

it is being called always when the value updates in the ModelID class ... 

 

[Oscarita25]

On 5/30/2019 at 6:52 PM, diesieben07 said:

It is doubtful you own this domain.

fair point
 

 

On 5/30/2019 at 6:52 PM, diesieben07 said:

Please don't. Nobody cares.

get it deleted 

¯\_(ツ)_/¯

 

On 5/30/2019 at 6:52 PM, diesieben07 said:

Do not use registerModEntity. Especially not in init. Entities should be registered using RegistryEvent.Register<EntityEntry>. Use EntityEntryBuilder to create your EntityEntry.

like this?

 

On 5/30/2019 at 6:52 PM, diesieben07 said:

You don't need all those factory classes. Use constructor references.

yeah fixed that

 

On 5/30/2019 at 6:52 PM, diesieben07 said:

You don't need an interface and an implementing class for all of your capabilities. You can just use a plain class. You only need an interface and a class if you plan to expose this capability via an API for other mods to use. In that case the interface would go into your API, while the implementation would remain private in your mod implementation.

i wont actually change that

On 5/30/2019 at 6:52 PM, diesieben07 said:

As for your actual issue: Have you actually tried debugging this? Is your layer rendering being called and just fails? Is it not being called at all? What are the values of the capability on the client where it's not rendered?

trial and error 2 clients 1 server started ... the model is only being rendered on the client player that has the model as for "real" debugging with breakpoints and stuff i didn't

 

Edited June 1, 2019 by Oscarita25
published to early (accidently hit enter)

[Oscarita25]

On 5/30/2019 at 6:52 PM, diesieben07 said:

Minecraft here

aren't those packets clien't side and the code will only be executed on the recieving side or did i get there something wrong?

[Oscarita25]

Just now, diesieben07 said:

It's not about code being executed, it is about classes being loaded. And your message handler classes will be loaded on the server, too.

... right ... i will change that but why does this not crash the server at all then?

should i get the model id cap different in the layer class? 
i mean >here<

[Oscarita25]

On 6/1/2019 at 6:16 PM, diesieben07 said:

It's not about code being executed, it is about classes being loaded. And your message handler classes will be loaded on the server, too.

i just noticed why it does work the way i do it because the class EntityPlayerSP is never loaded and the class Minecraft should be on the server too right?

Because i only reference the EntityPlayerSP with Minecraft.getMinecraft().player;

Edited June 14, 2019 by Oscarita25

[Oscarita25]

58 minutes ago, diesieben07 said:

Both EntityPlayerSP and Minecraft are client-only classes.

ok odd enough that this works

so i have to use ctx.getServerHandler.player even for client?

 

(sorry i am very slow at learning "complicated" stuff)
and itself getting it work somehow isn't the issue but getting it send to players tracking the client .-.

Edited June 14, 2019 by Oscarita25

[Oscarita25]

1 minute ago, diesieben07 said:

What?

i dont know if that is a bug or so but itself the packets work only on the client side for me if i do not do something like

Minecraft mc = Minecraft.getMinecraft();

if i use Minecraft.getMinecraft(); directly for it will not crash on the server just found that out by trying and i think thats not what it is supposed to do ?

this works even if i do not use the SidedProxy:

 

	    @Override
	    public IMessage onMessage(MM message, MessageContext ctx) {	
	    		Minecraft.getMinecraft().addScheduledTask(() -> {
	    			
	    			Minecraft.getMinecraft().player.getCapability(Capabilities.modelid, null).setModelID(message.model);
	        
	        	});
	    	
	            
	        return null;
	    }

and this is quite wierd

however this will crash the server:
 

	    @Override
	    public IMessage onMessage(MM message, MessageContext ctx) {
	    	Minecraft mc = Minecraft.getMinecraft();
	    		mc.addScheduledTask(() -> {
	    			
	    			Minecraft.getMinecraft().player.getCapability(Capabilities.modelid, null).setModelID(message.model);
	        
	        	});
	    	
	            
	        return null;
	    }

 

 

37 minutes ago, Oscarita25 said:

but getting it send to players tracking the client .-.

just meant that the other clients won't get the modelID from the client that has the modelID
(do i have to send 2 packets for that? something like this: client with model id -> packet -> Server -> returning packet -> other client)?

[Oscarita25]

11 minutes ago, diesieben07 said:

Sometimes you get lucky at it works out. But do not rely on it. Access to client-only classes must be encapsulated.

 

seems like it

 

 

11 minutes ago, diesieben07 said:

The server has control over the data. It sends it to all necessary clients. In this case the following applies:

1.  In PlayerLoggedInEvent, PlayerRespawnEvent and PlayerChangedDimensionEvent send the data of the player in the event to that player only.
2. In PlayerEvent.StartTracking check if PlayerEvent.StartTracking#getTarget is a player and if so send the data of PlayerEvent.StartTracking#target to PlayerEvent.StartTracking#getEntityPlayer.
3.  Whenever the data changes, sent it to all players tracking the player who's data changed (SimpleNetworkWrapper#sendToAllTracking(IMessage, Entity)) and also the player themselves.

okay will do that now

[Oscarita25]

okay but that didn't work (don't know why i am doing really everything correct..) 

but i did found a way around i looked at how The Parrot renderer does this its just storing most of the information in the DataManager of the player
so i tried that and it worked perfectly 


i registered it in the capability and set it when i syncronize my capability

(just so you get the idea of what i did:)

    private static final DataParameter<Integer> MODEL_ID = EntityDataManager.<Integer>createKey(EntityPlayer.class, DataSerializers.VARINT);

// when i register my Capability
		player.getDataManager().register(MODEL_ID, Integer.valueOf(0));


//when i sync my Capability
		player.getDataManager().set(MODEL_ID, Integer.valueOf(this.model));


//getter method for this
	@Override
	public int getModelDATA() {
		return ((Integer)player.getDataManager().get(MODEL_ID)).intValue();

	}

is this a vaild way to do this or can this cause bugs etc.?

[Cadiboo]

Don't use the (un)boxing stuff. Your IDE should be telling you not to do this. Other than that its fine. The DataManager is how vanilla syncs data, it works pretty well for basic data.

[Oscarita25]

2 minutes ago, Cadiboo said:

Don't use the (un)boxing stuff.

what exactly do you mean by "(un)boxing stuff" i don't quite follow you there

Edited June 19, 2019 by Oscarita25

[Oscarita25]

11 minutes ago, diesieben07 said:

Do not duplicate data! Either have a field storing your model or the data parameter. Not both.

 

ok will do that
 

12 minutes ago, diesieben07 said:

https://docs.oracle.com/javase/tutorial/java/data/autoboxing.html

thanks did fix that 


till now this works like a charm i pretty happy with the result