General questions

[KoloBear]

Hello everyone! I'm new to the forum as I've just picked up modding agian. I use to do it way back when but really could only add blocks and other simple things.

I have some questions about forge for current problems I'm having as well as somethings I know I'll run into.

Firstly, I would really like to learn so I wont be posting any code.

I've read through the forge docs about menus and screens, but I still don't really understand even though I've got one working.

Whats the difference between a screen/menu/container?

What are some methods of referencing variables from the screen class to the entity that called it (or really any other static object)

It looks like when the screen is registered (MenuScreens.register(xxxx)) there is a disconnect to that object.

I've read things on data packets and whatnot, but I still don't really see how you could use that without finding the actual screen object during runtime.

Also, I tried looking in the horseinventoryscreen. I found that it passes an abstractHorse through their register somehow, yet that horseregistry is not in the regular MenuType registries.

Is there a custom registry just for special cases like that? I can only seem to find the MenuScreens for just about everything else.

Any advice/thoughts would be appreciated!

[KoloBear]

It looks like I can actually save the MenuProvider before returning it as an object.. I feel like i'm so close, haha.

I was also thinking about using nbt data, but if i can get this to work then i guess theres no need.

Which actually brings up a better question, what is nbt data good for when creating mods? Just like unusual item/entity states?

 

[ChampionAsh5357]

10 hours ago, KoloBear said:

Whats the difference between a screen/menu/container?

A container is simply a list which holds items. A menu is analogous to a view in SQL which essentially represents the data on the server and syncs it to the client. A screen is the user interface which allows you to see what is currently being displayed in the menu.

10 hours ago, KoloBear said:

What are some methods of referencing variables from the screen class to the entity that called it (or really any other static object)

None. You do not reference the screen class from the entity whatsoever. You can send data from the entity to the screen via a packet (or if its already synced, by passing in the entity directly), and write data by using a packet back to the server. The screen will need to know the entity id for this to work.

10 hours ago, KoloBear said:

It looks like when the screen is registered (MenuScreens.register(xxxx)) there is a disconnect to that object.

I've read things on data packets and whatnot, but I still don't really see how you could use that without finding the actual screen object during runtime.

MenuScreens#register attaches a MenuType to a method which constructs a new instance of a screen. If you are using a menu, then the client side will construct the screen using the menu type sent from the server by looking it up in the registered map. If your screen does not have a menu, you wouldn't be touching this method and only open the screen directly on the client.

10 hours ago, KoloBear said:

Also, I tried looking in the horseinventoryscreen. I found that it passes an abstractHorse through their register somehow, yet that horseregistry is not in the regular MenuType registries.

They have their own packet because that's what Mojang did. You can accomplish the same using IContainerFactory and sending the entity id using the friendlybytebuf, so you can register the menutype without issue.

10 hours ago, KoloBear said:

Is there a custom registry just for special cases like that? I can only seem to find the MenuScreens for just about everything else.

IContainerFactory as mentioned above.

8 hours ago, KoloBear said:

Which actually brings up a better question, what is nbt data good for when creating mods? Just like unusual item/entity states?

For storing extraneous data or sending complex data through a packet.

[KoloBear]

That makes a whole lot of sense, thanks for the detailed explanation! I ended up getting data to pass from the entity to the screen via the menuprovider, however its not like what you described. I'm going to try it on a server and see what happens.

Essentially when I make a new menuprovider I have it saved to another menuprovider object before i return it

example:

EntityClass:

public static myCustomMenu ref;

public getEntity(){
	return this;
}

public myCustomMenu createMenu(int windowId, Inventory playerInventory, Player playerEntity) {
	ref = new myCustomMenu(windowId, playerInventory, null);
	ref.setEntity(getEntity());
	//reference whats in the menu here
	return ref;
}

Quote

None. You do not reference the screen class from the entity whatsoever. You can send data from the entity to the screen via a packet (or if its already synced, by passing in the entity directly), and write data by using a packet back to the server. The screen will need to know the entity id for this to work.

So the screen really only reads variables from the menu class, which is created by client or server and talks to the entity? And you can't access the screen because its under a registry?

I think I'm starting to get it, thanks for the help agian!

Edited April 21, 2023 by KoloBear
code update