imacatlolol

Nice, yeah that's exactly what I was thinking. I can see that having hundreds of items might cause a bit of trouble, and my IDE doesn't always play nicely with inner-classes when I try searching for them or auto-completing, but aside from that I still think it's a worthwhile idea.

I have a simple question that honestly might generic enough for SO, but I think it fits. Would it be a bad idea to make my "ModItems", "ModBlocks", etc. classes just be inner-classes of my main mod class? (I.e. Mod$Items, Mod$Blocks) An alternative would be to rename the classes "(Mod ID)Items", "(Mod ID)Blocks" etc. but it feels just as sloppy, especially for longer mod ids. Using the word "Mod" is just asking for class name collisions, and I'm not a fan of having to use fully qualified classpaths in my code. (Edit: Object holders kind of fix this issue, but I think it's still worth talking about) Using inner-classes feels logical, as my mods items are a direct aspect of my mod, therefore it seems like it's not too far fetched to use inner classes for this. But, I'm not confident. It feels like a pretty basic Java styling principal that I'm just ignorant of, so I'd like to get some input from people who are more experienced than me.

I started back with Risugami's ModLoader before Forge became a thing, so I don't entirely remember my process. But I'm sure I just did the same as @diesieben07. I assume most people start out like that; it's generally the most effective way to learn if tutorials aren't cutting it.

Ah okay, I misunderstood, no worries.

Glad it's working, but please keep in mind that Biomes O' Plenty's current copyright license doesn't allow this if you intend to distribute your mod.

athelasTea doesn't appear to be given a registry name, unless you're doing it in the item's constructor or something.

General word of warning: BlockBench has a bunch of rendering inconsistencies that don't mirror the actual game, especially when it comes to transparency. When it comes to entities, it's really only good quick prototyping in my opinion. Chances are BlockBench is just being weird.

Ahh okay, thanks for the clarification

Don't worry about it. Mojang marks some methods as deprecated when they really mean "don't call". Unless the original method has a comment from Forge telling you what to use instead, it's okay to override it.

Just wondering, when did they do that? From all I found in their Terms and Conditions, they only disallow the selling of cape cosmetics, but there's no mention of not being allowed to make mods involving them (as long as they aren't sold).

If you're talking about blocks, it should be as simple as referencing the model in the blockstate json like normal. Just make sure to include the ".obj" part.

I believe ClientTickEvent is on the Forge event bus, not the Mod bus.

Great, thanks for the details!

Rather than rendering a texture/image, it may be better to use OpenGL to specify four vertices with different colors, then render a square. It should produce the 2D gradient effect you're looking for without having to generate a new texture every frame. I'm not very experienced with OpenGL, so I'm afraid I can't give an exact workflow for it.

Bumping since I'd still appreciate some clarification.

Thanks for the lead, wasn't expecting a fake world to be that clean!

I'm altering the block highlight effect when a given block is intractable. It's a sort of "immersive WAILA" type of thing. I'm doing the same for other situations, such as when blocks are harvest-able with a tool, but intractable blocks have been the only hurdle I haven't been able to find a clean solution to. My reflection idea functions well enough, but not being able to perform the actual Block#onBlockActivated check has been a real killer...

Yeah, that's what I was worried about. One option would be to somehow pass in a fake world, which would be pretty ridiculous and not at all viable... probably? A more likely option would be to iterate over all of the registered blocks after initialization and use reflection to see if they override Block#onBlockActivated. But, that would entirely disregard the actual method's logic and probably be pretty slow (though I'd probably cache it with a config value)...

Is there a simple way to check if a block can be activated? Ideally, it would return the same result as onBlockActivated, but without actually affecting anything. Not sure if this is viable or even possible...

I've been learning about the new NightConfig-based system that Forge uses now, but I've still got a few questions to clear things up: For the config type, the javadocs says that the SERVER type is synced to the client. How would I use this, exactly? If I had to take a guess, the client registers the config like normal but a local file is never made by the client (unless it's a local world); the server simply fills in the object values upon connection, and from that point they should be treated as immutable on the client side. The takeaway being the the client still needs to register the server config during initialization. Is that right? How performant is it to get values from the config? What I mean is, if I need to check a config value every frame for rendering code, is it okay to just grab the value from the config like normal? Or, should I store a "proxy" value that only gets updated when the config changes? I'm assuming it doesn't query the file every single time so it wouldn't be an issue, but I'm not confident. For client configs, should I place its registration in the client's proxy, or can I leave it in the mod's constructor like other configs? I would assume that client configs would simply be skipped on the server side and wouldn't create a file, but again, I'm not confident.

Agreed, Tabula and other utilities make it so much easier to position and tweak things on the fly. Trial and erroring semi-abstract numbers is a massive waste of time. However, there's a useful feature many are unaware of that most IDEs can use to alleviate similar issues: hotswapping. I don't know how to do it on Eclipse, but on IDEA you can simply launch the game in debug mode, change some code, then just hit the build button to hotswap the changed code into the running game. It can't do everything (e.g. adding/removing methods requires a full restart), but changing rendering code inside a method is an ideal use case for this feature. But with that said, I sadly don't think hotswapping will work for adding/changing model boxes since those are usually defined in the model's constructor. Workarounds are possible (does anyone know if F3 + T also reloads entity models?), but Tabula/Blockbench is still the way to go to get fast results.

Just read the names of the parameters. The first three are the center position of the box, then size of the box, then the scale. Read some of the vanilla code to see some real usages.

You could probably just remove your render() override entirely and the problem may fix itself; you don't seem to be doing anything special and you properly set your model objects as children of the parent's objects, so the parent model can just handle everything on its own. If you don't want to get rid of it, just remove your individual render calls for your objects and call the method's super. Admittedly though, it's been a while since I've worked with entity models.

The values you define with the API as I mentioned will work in modpacks, yes. Modpack makers can still use the custom_emc.cfg config file to change the EMC of objects added by your mod and other mods (from what I understand, at least). That's what I assume the commands are for. I'd recommend reading the wiki page for details.

On ProjectE's wiki, it mentions an EMC mapper API. Digging through the mod's source code, you can get an instance of an EMC proxy (used to register EMC values) from the API's class. All you have to do then is use the provided registerCustomEMC() methods. You can search on GitHub for other mods using this API, if you need to.