imacatlolol

If you're not using a living entity, you'll have to implement the render method yourself in your renderer. Look at other non-living vanilla entity renderers for inspiration (BoatRenderer for example).

I would recommend trying and seeing if it works anyways just for the heck of it. Forge is in beta right now for 1.16, so some issues are to be expected. They're working quite hard to get things figured out, but it may take a little while.

Version 33.0.22 has re-implemented the registry, but things obviously aren't expected to work quite right yet.

Update to the latest version (33.0.22 at the time of writing). Edit: Also, see here for why.

Oh! Neat, I didn't recognize that as a vanilla method. Actually, looking at your code a little closer, you're misusing World#setBlockState and BlockState#cycle entirely. The integer parameter is for flags which are used for updating and syncing. You should use a flag of 11 for both lighting and un-lighting the block. As for the BlockState, you should use the with method instead of cycle.

Please define "not working". Show your code.

Where are you actually running your code? If you want it to change instantly you'll have to make a ticking tile entity (see how the daylight sensor works). Since that's not good for performance, you may want to just override the Block#tick method and let it update randomly (like how farmland and leaves works).

The model JSON is looking for a texture in items, but the actual folder is Items; it's case-sensitive.

Compiled mods are expecting to run against obfuscated code, but the dev environment is deobfuscated. This used to still work in older versions of Forge, but the feature seemingly got lost with the 1.14+ rewrite. If the mod you want to use is open source, you might be able to use JitPack as a workaround.

You're passing com.monroth.arcanapp.master_of_magic.MOD_ID as the deferred registry's ID, which is "arcpp" from the sounds of it. However, your mod's id is "mom". Also, your assets aren't in the right directory for either of those ids, as that's titled "master_of_magic". My recommendation would be to pick one of those three and stick with it.

I'm... not too sure, to be honest. Stripping the methods seems like a viable use case, but the annotation itself doesn't seem to be referenced anywhere (except for annotating things obviously). It's intended to only be used by FML/Forge and the javadocs say for modders not to use it, so I personally advocate against it. As far I'm aware, it's just a marker; FML/Forge merges the client and server and @OnlyIn is used to indicate the differences. So it's probably safe for you to use as a marker yourself, but I'm not sure. I imagine one reason for not using it is because people might misunderstand it and somehow believe that it'll magically make certain code not run on the server/client, when it seemingly does nothing in reality. Probably a good question for Lex or someone else who works on the lower levels of Forge, I'm curious as well.

See ServerWorld#tickEnvironment, towards the bottom of the method is where it does random ticks.

OnlyIn does literally nothing for modders. It's an internal marker for Forge/FML only, so modders shouldn't use it. A TickableSound would probably be ideal for this, as already mentioned. You could use Item#inventoryTick to start the sound by checking the item in the player's hand, kind of like how maps work .

In a sense, yes. There's no quick way of changing the HUD layout since it's all hardcoded. However, you don't actually have to "import" anything since TextureManager#bindTexture handles all the heavy lifting (it simply takes a path to the texture via a ResourceLocation). I recommend spending some time dissecting the vanilla code and playing around with it to see what does what. I generally advocate against copy-pasting vanilla code (partially for copyright reasons, among others), but since you mentioned that you're good with Java there shouldn't be a problem with doing so as long as it's just for learning/prototyping.

A counter is fine, but an another way of doing it would be to increase a number every tick and then use the modulo operator to compare the current value. So for example, create a ticks field, run ++ticks every tick to increment, then do if (ticks % 10 == 0). It will return true every ten ticks. The modulo operator is basically a division operator that returns the remainder, so comparing it to zero will only return true if the value is cleanly divisible. It won't make a noticeable difference performance-wise, but you may find the code to be a little cleaner. It's just a personal preference thing.