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.

Yes, sadly most documentation is outdated or lacking, and few tutorials are comprehensive enough for more advanced feature implementation. The inner-classes of RenderGameOverlayEvent are what you need. Specifically, for changing the vanilla HUD elements, you'd want to cancel the Pre event for a specific element (e.g. the hotbar) to stop it from rendering normally and then render your own stuff manually. Take a look at ForgeIngameGui for more details on how the HUD is rendered. Always make to check the element type when using the event, otherwise you will end up rendering something multiple times and cause other graphical issues.

I see! That would certainly be achievable without needing a custom render type or lightmap. In this case, you would want to make a custom IModelLoader and model to use with your block JSONs. See MultiLayerModel and its usages for roughly what that process would be. Applied Energistics actually achieved this effect, but their repo is outdated and most of the actual code no longer applies. It's still a good reference for how you could try implementing it yourself if you get stumped. Just take a look at the charged certus quartz ore.

Not from a Jedi. Just wondering, but what is the specific purpose of your custom render type? It seems you just want a custom lightmap, but it would help to know your reasons since there might be safer alternatives.

Literally just google "Java 8" and you'll find it. If you're just trying to use mods, get the JRE. But if you're trying to make mods then get the JDK. The Oracle version is the old standard, but lots of people have been switching to OpenJDK.

You just download it and run the installer

Use Java 8

Capabilities are perfectly suited for this kind of feature. The documentation for them isn't perfect, but it should help you get started.

There's your problem. The event is normally intended to be used by simply setting the fog density via the event's setDensity method. The same goes for the fog color. A density of 0.3 will produce a very similar effect as the vanilla method, but it's not perfectly identical since vanilla uses more complex methods. However, the difference is very subtle and none of your users will likely even notice. If you really want an identical effect, you should set the density to 0 and then use those four RenderSystem method calls towards the end.

The effect is controlled by FogRenderer#updateFogColor, and FogRenderer#setupFog. Look for the usages of Effects.BLINDNESS to see the exact math it performs. Hook on to the EntityViewRenderEvent$FogDensity and EntityViewRenderEvent$FogColors events to override the vanilla behavior and do your own logic (the former event will need to be canceled for your stuff to work). I recommend using a lower event priority and then checking the state of the events so that other mods can override your system if desired.

Sadly, almost all of the documentation (even the JavaDocs in the code) is horribly outdated or lacking, as you mentioned. For your case, the "ItemStack sensitive version" comment refers to the hasContainerItem and getContainerItem in IForgeItem, which Item implements. Basically, just add an ItemStack parameter to the deprecated versions and it will override the new versions.