Possibly the only thing that bugs me is:

 

final CapAttributeData INSTANCE = new CapAttributeData();

 

inside the CapAttributeProvider.class

 

so perhaps following someone elses code made me create a singleton?

Possibly the only thing that bugs me is:

 

final CapAttributeData INSTANCE = new CapAttributeData();

 

inside the CapAttributeProvider.class

 

so perhaps following someone elses code made me create a singleton?

That should be your Capability variable (probably set to null) .getDefaultInstance(). That exists correct?

I believe that is this?

 

	@CapabilityInject(CapAttributeData.class)
public static Capability<CapAttributeData> CAPABILITY = null;

public static void register()
{
	CapabilityManager.INSTANCE.register(CapAttributeData.class, new StorageHelper(), new DefaultInstanceFactory());
}

that's located in the "CapAttribute" class. If you wish to see all the code I have a link in my sig to the repo that I'm updating the code to for now. It's supposed to be public so hopefully it allows access. I use straight forward package names so hopefully easy to navigate through.

 

EDIT:

 

Yeah looks somewhere I have it set up incorrectly. I put some "test" code back in that I used when it was only on the player. Killing things now show that their stats are the players stats. Which is 100% incorrect.

 

Which is strange as when I had only two vars (two test ints) killing a mob would return 0, where my player version (killing added 1 to that var) increased normally and correctly. Leaving mobs to 0 as nothing increased their variable. But now it's all messed up once I add in the roll stats option?

 

EDIT2:

 

Tried to revert the code back, now it seems using the old way is the same issue, updating player attrs, kill something, reads players attrs back from the death event.

 

 

[22:03:40] [Client thread/INFO] [sTDOUT]: [htd.rot.events.FMLEventPlayerTick:playerTickEvent:35]: Strength=3 ::: client

[22:03:40] [Client thread/INFO] [sTDOUT]: [htd.rot.events.FMLEventPlayerTick:playerTickEvent:35]: Dexterity=2 ::: client

[22:03:40] [Client thread/INFO] [sTDOUT]: [htd.rot.events.FMLEventPlayerTick:playerTickEvent:35]: Intelligence=1 ::: client

[22:03:40] [Client thread/INFO] [sTDOUT]: [htd.rot.events.FMLEventPlayerTick:playerTickEvent:35]: Vitality=4 ::: client

[22:03:40] [Client thread/INFO] [sTDOUT]: [htd.rot.events.FMLEventPlayerTick:playerTickEvent:37]: -----------------------------------------

[22:03:41] [server thread/INFO] [sTDOUT]: [htd.rot.events.EventEntityDeath:onEntityDied:29]: Dead Mob: Bat

[22:03:41] [server thread/INFO] [sTDOUT]: [htd.rot.events.EventEntityDeath:onEntityDied:32]: Strength=3

[22:03:41] [server thread/INFO] [sTDOUT]: [htd.rot.events.EventEntityDeath:onEntityDied:32]: Dexterity=2

[22:03:41] [server thread/INFO] [sTDOUT]: [htd.rot.events.EventEntityDeath:onEntityDied:32]: Intelligence=1

[22:03:41] [server thread/INFO] [sTDOUT]: [htd.rot.events.EventEntityDeath:onEntityDied:32]: Vitality=4

 

 

It should have been all 0's for the bat

Sadly I'm still having the issue of the capabilities being returned all as the same regardless of it being the player or a mob or newly generated mob.

 

This is creating a damper on things as I haven't gotten to the "more than one player" tests and if it's going this route it may as well be the last player to have their stats changed to update every player, and as well as that but mobs too.

CapAttributeData.attributes

is a static field, so it's shared between all instances of

CapAttributeData

.

CapAttributeData.attributes

is a static field, so it's shared between all instances of

CapAttributeData

.

 

Aren't those just String constants he's using to name the NBT fields? Not sure how that could cause any trouble...

 

Hugo, in these situations I usually start again more simply. Right now you have a fairly large number of attributes and are debugging all of generating / save & loading / syncing with packets.

 

Break it down. At the time of generation are you getting expected different random stats? At the time of writing NBT are you getting expected stats? At time of reading NBT are you getting expected stats? At the time of sending a sync packet are you getting expected stats? At the time of receiving the packet are you getting expected stats?

 

So I'd write console statements in all of the above points in the code and trace through to see where the problem is occurring.

Also, where in your packet to you indicate which entity should get the synced information? Maybe your approach works (to sync capabilities directly) but I personally would do the syncing as follows.

 

1) When an entity capability value changes, send a packet indicating containing the entity ID and the VALUES of the capability (e.g. the same NBT you'd have from the writeNBT()).

2) When an the packet is received I'd go through the received NBT and then take the entity indicated by the ID and one-by-one I'd update all the attributes one-by-one by calling their setter methods.

 

Pet peeve: why doesn't Forge go ahead and add the syncing functions for these interfaces (it was a problem with IEEP and Capabilities)? It is pretty standard problem to have to sync them, and only a few of us are sufficiently familiar with custom packets to do it right, so would probably save 10% of this forum's time by providing a sync interface that eliminates the need for every modder to redo it...

Also, where in your packet to you indicate which entity should get the synced information? Maybe your approach works (to sync capabilities directly) but I personally would do the syncing as follows.

 

1) When an entity capability value changes, send a packet indicating containing the entity ID and the VALUES of the capability (e.g. the same NBT you'd have from the writeNBT()).

2) When an the packet is received I'd go through the received NBT and then take the entity indicated by the ID and one-by-one I'd update all the attributes one-by-one by calling their setter methods.

 

I know that the capability is serializable and therefore can go directly into a packet but I'm not convinced that it knows the correct entity on both sides. It certainly may, but I personally wouldn't rely on it.

 

Pet peeve: why doesn't Forge go ahead and add the syncing functions for these interfaces (it was a problem with IEEP and Capabilities)? It is pretty standard problem to have to sync them, and only a few of us are sufficiently familiar with custom packets to do it right, so would probably save 10% of this forum's time by providing a sync interface that eliminates the need for every modder to redo it...

CapAttributeData.attributes

is a static field, so it's shared between all instances of

CapAttributeData

.

 

Aren't those just String constants he's using to name the NBT fields? Not sure how that could cause any trouble...

 

The

attributes

field is storing the attribute values, the

attributeTags

field is storing the tag names.

Wow I feel dumb now, Yes Choonster was right, I just never saw it. In my ambition to make this capability easy to add or remove new stats, I directly referenced the "int[] attributes" var in CapAttributesData.class from the Packet, which of course asked me to make it static, which silly me just went "Ok sure" completely forgetting what static does or at least everything it does.

 

I can't believe I overlooked it for 3 days.

 

I'd also like to thank Animefan8888 and you too jabelar for having a look.

 

@jabelar: I didn't mind the custom packets too much, however I know for quite a few of my systems (mainly GUIs) I had to have a request and response packet for a few IEEP (and now going to be Capability) so the client can send, and get told by the server if their request was valid (Enough mana, gold, etc)

 

[spoiler=long winded chat]Anyways your actual question was "Also, where in your packet to you indicate which entity should get the synced information?"

Currently it's in the "CapAttributePacket.CapAttributePacketHandler.onMessage()" method, where it reaches into the proxy to get a player object (from the proxies) and then send the data off to that, and just assigns the read data to it.

 

I just followed someone elses code to get it working. But I know I will be redoing the packets to function the way I had my IEEPs working which was when a player connects they check a bool in their IEEP to see if they had been init'd yet, it defaults to false so clients will always ask on their first update, in which the server sends them the raw values it has saved. Then after that packets are sent only when needed (Mana change, stamina change, stat change, etc)

 

Most of the Mob stats can stay on the server side as there won't be anything the player can do to view them, as I will be making a few new capabilities more geared towards unique Player and Mob values (Player Gold, Mob Boss Name, Player Class, etc) I managed to rip some MC code for getting an entity from the LoS so for some overlay rendering will be asking a viewed mob some basic info