Jay Avery

Do I just have the wrong idea about how forge server compatibility works? Is it always possible to connect to a vanilla server from a forge client?

From the comment, it looks like a single version string should be interpreted as a valid version range - shouldn't it? And I don't understand how, even if I wrote the version range in the wrong format, it ends up letting me connect to a non-forge server. I would expect it to just not allow connecting to any server if it doesn't understand the version range I've given?

Look in the minecraft assets folder: resources/assets/minecraft/models/block.

Look at the models in the minecraft assets folder to decide which parent suits you. There are a few different cube_ variants with different texture definitions. For your purposes, cube_bottom_top is probably best.

You're using the parent cube_all, which has only one texture: #all. Then you define three textures which aren't in the parent model and don't get used.

I'm trying to figure out how to name and define versions for my mod. I know that any version will only be compatible with a single minecraft/forge version - which will be defined in @Mod.acceptedMinecraftVersions, in "mcversion" in the mcmod.info, and in the minecraft version section in build.gradle. (Am I on the right lines so far?) With other things as their default, the mod only allows a client to connect to a server which has the exact same mod version. So, say a 1.0.0.0 client can't connect to a 1.0.1.0 server. I'd like to allow clients to connect as long as their major version matches - so 1.0.1.0 should be able to connect to 1.0.0.0, but 2.0.0.0 shouldn't. I know there's @Mod.acceptableRemoteVersions. But I just tested that by setting it to the exact current version of the mod (i.e., I expected the result of this to be the same as if I hadn't changed this from the default at all), and ended up being able to connect to a server that wasn't even forge, let alone had my mod installed. Do I need to change a setting elsewhere, like in build.gradle or mcmod.info too? Have I misunderstood what acceptableRemoteVersions is supposed to do? I'm just confused because there are settings and metadata in various different places and they seem to all be important in similar but distinct ways and I can't figure it all out. It would be great if there was a summary somewhere about what the different bits do and how they relate, if anyone can recommend such a source? I've looked at the forge docs and stuff, but information about the different aspects is quite disjointed and separate and that's what I'm having trouble with.

Take a look at the forge documentation on events. For a non-static event handler method, you need the @SubscribeEvent annotation, and to register an instance on the MinecraftForge.EVENT_BUS. The @EventHandler annotation is only for FML lifecycle events (preInit, init, etc) in your main @Mod class.

The blockstates file goes in the blockstates folder - the file that I quoted.

Yes, that's right. assets/models/block/ is where model files go.

Yes, it is required. You already made a blockstates file, you must just have it in the wrong place:

Caused by: java.io.FileNotFoundException: projectprisma:blockstates/blockCopper.json Do you have a blockstates file at this location?

You are still doing it in init.

Post your most up-to-date code, blockstates file, and error logs.

We need to see your code in context to know exactly what it's doing (and what it should be doing). Where is your part field? Where are you using the line which causes an NPE? Post your whole block and TE classes.

You're in the wrong subforum, this is for people developing mods 1.7.10 is no longer supported on this forum You should first contact the devs of the mod which is crashing

Why is the registry name based on the blockstate? I'm pretty sure there should always be exactly one registry name per block, not per block variant.

You never create an ItemBlock for your SimLightBlock. An ItemBlock is the thing which exists in the inventory and creative tabs, a Block is the thing which exists physically in the world.

I'm not going to write it for you. You're very close to getting it right, and talking you through the errors with your version will teach you far more than just giving you a working replacement.

For a version with only two colours, you will need to change the way your block's properties are coded. Are you still getting model errors in the console? If so, post them.

Check the forge blockstates format rules again. The variants for a property like colour should not be in an array (in square brackets). Edit: You also have a json syntax error, an extra comma at the end of the "black" variant. Use an online json validator or a plugin for your IDE to catch syntax mistakes like this.

A blockstates file won't be processed correctly unless it has all the possible states in it - so even if the one variant is correct, it won't render if another variant is wrong or missing.

That means that you don't have a variant for that colour. Take a look at the docs I linked you, and make sure your blockstates file contains a variant for every colour in the correct format.

Can you clarify, exactly what doesn't happen as expected? Is a condition returning false/true when it shouldn't? Or something to do with adding to an inventory isn't working correctly?

Okay... what error?

The forge docs have an overview of the vanilla blockstates format (fine for simple blocks like yours), and the forge blockstates format (more versatile but marginally more complicated).