ChampionAsh5357

Ah ha! I figured it out! The initial position of your model is facing east, not north. As such, when rotating in the x axis, it just rotates left and right, which makes sense since you don't see any difference except for maybe the texture looking slightly different. Try using this for the filter connector instead, I've adjust the base model to point north: { "credit": "Made with Blockbench", "texture_size": [32, 32], "textures": { "0": "miningmadness:block/filter_connector", "particle": "miningmadness:block/filter_connector" }, "elements": [ { "from": [5, 5, 1], "to": [11, 11, 2], "rotation": {"angle": 0, "axis": "y", "origin": [8, 8, 8]}, "faces": { "north": {"uv": [4, 0, 7, 3], "texture": "#0"}, "east": {"uv": [6.5, 6, 7, 9], "texture": "#0"}, "south": {"uv": [4, 3, 7, 6], "texture": "#0"}, "west": {"uv": [6, 6, 6.5, 9], "texture": "#0"}, "up": {"uv": [7.5, 3, 7, 0], "rotation": 270, "texture": "#0"}, "down": {"uv": [7.5, 3, 7, 6], "rotation": 90, "texture": "#0"} } }, { "from": [4, 4, 0], "to": [12, 12, 1], "rotation": {"angle": 0, "axis": "y", "origin": [8, 8, 8]}, "faces": { "north": {"uv": [0, 0, 4, 4], "texture": "#0"}, "east": {"uv": [4.5, 6, 5, 10], "texture": "#0"}, "south": {"uv": [0, 4, 4, 8], "texture": "#0"}, "west": {"uv": [4, 6, 4.5, 10], "texture": "#0"}, "up": {"uv": [5.5, 10, 5, 6], "rotation": 270, "texture": "#0"}, "down": {"uv": [6, 6, 5.5, 10], "rotation": 90, "texture": "#0"} } } ], "groups": [ { "name": "Connector", "origin": [8, 8, 8], "color": 0, "children": [0, 1] } ] }

If you mean the screen, then yes, you would need a packet to send that information to the server which then gets updated on the client. Ah yes, you send a packet to the server, so the first thing you do is set data on the client. Since you are on the server, you can get the server level instance by grabbing it from the sender in the context event.

Isn't your host address supposed to be 127.0.0.1?

Again...if you want to complain about the documentation, please provide an issue. I can't know there are issues unless somebody mentions them. Additionally, as this is vanilla related stuff, all of this is documented on the Minecraft wiki which is linked on the Forge docs.

You would need to provide the entire debug.log, but that just sounds like a mod feature.

There are plently, but it depends on your operating system occasionally. You could just search on the internet for java profilers for your operating system and then follow their guide to hook into the running Minecraft instance.

Please provide the entire debug.log from the logs folder in the game directory via a pastebin or gist.

You can either use the Forge bot on the Forge discord or Linkie which has the commands for you.

Well, you don't run that code specifically, you play the sound directly through the SoundEngine by passing in the ResourceLocation since the SoundEvent can't exist. The server should be the one sending the packet to the client. The only thing you would be sending is the name of the sound to play and the position on where to play it. As I mentioned, the server will be responsible for sending out the sounds assuming that there is a list of sounds the server can access that is guaranteed to be on the client. If you want this to be dynamic, you can have the server with a datapack containing that information. I mean, it wouldn't be in sync no matter which way you do it if you don't send a packet. The only reason you are able to say that it's fine now is because the server and client are the same instance. If on a dedicated server, you would run into the same issues.

Ok, would you mind posting a repo with your code then? I want to try and reproduce on my end since I genuinely can't see anything wrong directly.

Unless something like RegisterClientTooltipComponentFactoriesEvent exists in 1.18.2, you'll need to use one of the RenderTooltipEvents to handle the rendering logic instead.

They are. It's just that, as mentioned, EntityType$Builder is not a valid type to supply for EntityType. You can get an EntityType from an EntityType$Builder via #build. Block#build is not a valid method. I believe you can figure out the rest if you read your code.

Hmm, it's strange that it isn't working since I don't notice anything wrong. Another curiosity, is the json in the `build/resources` folder the same as the blockstate json in the `src/main/resources`.

You are using Java 19; download and use Java 17 instead.

Please provide a log of a supported version if you would like to receive support. If the issue is as you claim, then we will be able to help.

Then post the contents of /etc/hosts.

There is no indication of which plugin is erroring, hence why I directed you somewhere else since they might have a may to figure it out. Either that or there is a weird compatibility issue.

No, if you wanted to do that, you would need a profiler that isn't a mod that you attach to the running Minecraft instance.

Yes, you'll need to send a custom packet with the string instead and play it manually on the client. You can't use sound events as they are registered objects.

If they were both on the front, there should be some z-fighting which it doesn't look like there is. I'm curious, if you load up a debug world, fly over to all your block states, and then look at the results using f3, which models are properly rendered and which aren't? Based on your blockstate json, I see nothing wrong unless I'm missing something in the block model itself.

You do realize you could force a server to load a resource pack, so that wouldn't matter. Then you can have some reader on the client with the data for the sounds and then just play them as required.

No, it is. Chorus plants do the exact same thing. I would guess that it might be a transparent texture is being applied since you aren't preserving the UV through the lock.

You shouldn't need to cast anything. Take a look at what type its asking for and what you are supplying it. Makes sense, EntityType$Builder is not a valid object to supply. Additionally `Block#build` doesn't exist. I suggest looking once again at what is available since you seem to have performed an incorrect copy.

Can I ask the reasoning for this? It seems kinda strange to need to touch any of the save's files imo. Yep, you're essentially creating the saved data and attaching that to the current level, and then creating another saved data without doing anything. #computeIfAbsent returns the current save data from the level or creates it if does not exist, so you should change #manage to return your saved data and the modify that.

Ok? What do you have so far?