SuperGeniusZeb

Please show me how.

Well, you can't do either, so I guess the answer to your question is... yes? Your first example resembles the vanilla format, but that format is rather difficult-to-read/messy-looking, hence my use of a "conditions" group to make things more structured and organized. I'm not sure its the best solution to the problem, though. The problem with the current Forge blockstates format is that you can't have a model/texture applied based on if 2 or more conditions are true. Changes can only be applied on a single-condition basis. This is where the vanilla format has an advantage over the Forge format. (Though the way it handles it is somewhat clunky.)

In my previous topic, I discovered that the Forge blockstates format still doesn't support models like stairs, mainly due to the fact that multiple-condition-tests are not possible. (They're possible in the vanilla format.) See my previous topic here: http://www.minecraftforge.net/forum/index.php?topic=43581.0 And so, I decided to try and fix the problem with a new blockstates format. Here is my first draft/concept: { //This format is intended to be capable of everything the current format is capable of, as well as what the vanilla format can currently do that the Forge format cannot "forge_marker": 2, "defaults": { //Required (as opposed to optional in the current Forge format) because "variants" system does not force every possible combination of values to be defined "model": "mymod:model1", "textures": { "texture1": "mymod:block/texture_name", "texture2": "mymod:block/another_texture", "a_submodel_texture": "mymod:block/default_texture_for_a_submodel_if_present" }, "uvlock": false }, "variants": [ //Optional { "conditions": { //Allows for checking multiple conditions, which is necessary for things like STAIRS to be possible without using the vanilla format "property1": "this_value", //value can be string, int, or bool, depending on the property's type "property2": "this_other_value" }, "model": "mymod:model2", //replaces default model "textures": { "texture1": "mymod:block/texture_name", "texture2": "mymod:block/another_texture" }, "x": 90 }, { //Condition-sets are tested and variations are applied in sequence/order, so the sets defined last have highest priority and can override previous values "conditions": { "property1": "this_value", "property3": true }, "submodel": "mymod:model2", //is added to existing model, like in current Forge blockstate format "textures": { "example_texture_param": "mymod:block/texture_name" }, "y": 180, "uvlock": true }, { //Since this condition/model-set is defined last, and can override anything set by the previous sets, like the main model's x-rotation' "conditions": { "property4": "another_value" }, "submodel": { //Demonstration of multiple submodels "a_submodel_name": { "model": "mymod:the_model_used_by_the_submodel", "x": 180 } }, "textures": { "texture2": "mymod:block/placeholder_texture_name", "submodel_texture:": "mymod:block/texture_used_by_submodel" }, "x": 270, "uvlock": true } ] } I am almost certain I've made some mistake or overlooked something important (and even if I haven't, I'd like to make sure), so that's why I'm posting it here to get some feedback. What do you think should be improved/changed? Would this be possible to actually implement into Forge, or is there some internal code limitation I'm not aware of? Please let me know what you think so I can revise this conceptual format as needed. My goal was to make a format that does everything the current Forge blockstates format does, as well as everything the vanilla format is capable of that the Forge format is not. I've based this format off of the current Forge blockstates format, which you can see in the official Forge docs, as well as the vanilla format, which you can see an example of by looking through the vanilla assets and opening the stairs and fence blockstate files, which give examples of the "variants" & "multipart" system that vanilla uses in its blockstates format. Thank you ahead of time for your help & feedback!

Awww. I was hoping there had been some change/addition to the format in 1.10/1.11... I guess it's time to try and think of a better/improved format and post it here to take suggestions, then. (Maybe this is why vanilla still uses its current format and didn't switch to something like the Forge on...)

You mean like... http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/#sub-models ? The "submodels" part of that section not being the relevant part, look at mossy and pillarcount. I'm well-aware of the submodels system. (See my previous discussion linked in the main post.) But it's not enough for stairs. To see what I mean, just TRY and make stairs using the Forge blockstate format. You can divide the stairs into submodels, but it won't be enough to handle all the possible rotations and shapes the stairs can have. You'll run into rotation problems pretty quickly.

So a little while back I was trying to make custom stairs using the Forge blockstate JSON format. (See: http://www.minecraftforge.net/forum/index.php?topic=39104 ) I concluded that it must be impossible to do so, and resorted to using the vanilla format. So my question is... is it possible now? Is there any way to define a block like stairs in the Forge blockstate format? The key problem seems to be that the vanilla format supports multiple conditions per model, like "facing=east,half=bottom,shape=straight" being one example. I can't find a way to do this with the Forge format... but this is required for a model like stairs. It also seems that you can't rotate a model more than 2 times, and rotation of an axis cannot be handled by 2 different properties simultaneously. Is there a way to do this now? It's been a while, and I would expect the Forge blockstate format to be capable of anything that the vanilla format can do. Has there been any discussion on this, or is this even known about?

See title. Specifically, I want to be able to override just 1 method in BlockPistonStructureHelper... addBlockLine() to be specific. I'm trying to increase the piston push limit from 12 to 16, and having taken a look at the vanilla code, I can see that it's literally a 2-line change to do it. I am well aware that coremodding is by far no easy task (especially for someone with as little experience as myself), and is one of the most complex and hated aspects of modding. But I want to try anyway and hopefully learn something and gain some experience, even if I fail. Where do I start, and also, what are the alternatives to using a coremod? I know Forge replaces vanilla buckets with custom ones, but I'm not sure how I would do something like that and ensure compatiblity with mods requiring pistons in recipes and stuff like that, or how difficult it would be in comparison to coremodding.

Thanks for the helpful link and explanation, Choonster! I understand the format a whole lot better now.

I was able to get it working and have a rough idea of how to do it now, but I still don't quite understand. (I have no prior experience with Maven.) Should I organize all the mods into folders based off of their actual repository formats or can I make up my own organization? In the example, how does it know that "universal" refers to the "ironchest-6.1.10-universal.jar" file? How exactly does a Maven-style locator work? I'm also curious as to why the mod_list.json uses this format and what the advantages are. Basically, I've got it working, but I don't know why or how it works.

I've already read that. That's how I knew how to format the mod_list.json in the first place. But thanks anyway. Ok, I changed the mod_list.json, and here is what it looks like, complete with all the mods I have listed: And now Forge just crashes when I try to start the game. Here's what the launcher logs say: I'm not sure why it seems to think I'm running Windows 8.1. (Is it just a minor bug with Forge, the new launcher, or what?) Also, in case you're wondering what's up with the .minecraft folder, I actually have a symbolic link in the normal location where the .minecraft folder would be. The symlink links to the actual location of my .minecraft folder, which is in my Dropbox, so I can use the same Minecraft installation on other computers or on my Ubuntu partition. (Also in case my laptop dies, so I don't have to worry about losing my worlds.) I'm not sure if I'm doing something wrong, if it is a bug with Forge, or if it is a problem with the new launcher & Forge. Also, no, my username is not literally [uSERNAME].

I've placed all my mods in a central location, and I'm trying to load them using a mod_list.json in ".minecraft/mods/1.10.2". I'm not sure how to specify an absolute path, though. I tried doing what the Github page said, and my .json looks like: { "repositoryRoot": "absolute:C:/Users/[MY-USERNAME]/Documents/Minecraft/Mods/1.10.2", "modRef": [ //lots of mods here ], "parentList": "" } When I start up the game, however, none of the mods load. The launcher logs say: Possibly relevant: I'm using the latest version of the new beta native Minecraft launcher, using the latest version of Forge for 1.10.2, and I'm running Windows 10 64-bit. Do you have to type the absolute path differently? Or is the mod_list.json thing just broken with the new launcher?

In addition to what pWn3d said, keep in mind that even 1.8 mods will usually not work with 1.8.9, and likewise many 1.9 mods don't work with 1.9.4. A lot of 1.9.4 mods DO work with 1.10.2, though. This is a relatively rare case, though, as not many internal changes affecting mods were made between the 2 versions in either Minecraft or Forge. 1.11 is expected to have several changes which will probably affect at least several mods, causing at least some, if not complete incompatibility with 1.9.4 and/or 1.10.2 mods.

The current up-to-date version of the mod with all the latest features (1.2) is available for Minecraft 1.10 & 1.9.4. The previous version of the mod (1.1) was made for MC 1.8.9 and 1.9, and the original 1.0.0 version of the mod was made for Minecraft 1.8. You can see a changelog on the mod's page on my website. http://supergeniuszeb.com/project/colore/

Are you sure that registerSounds() is being called in the proxies? Forgetting to actually call registration methods has tripped me up before in the past.

Forge for 1.10 came out, and now Colore 1.2 for MC1.10 has come out too! There's no new features in this update... it's literally identical to the 1.9.4 version except for the version number. So enjoy playing the mod on 1.10!