Leaderboard

Because people still ask questions about 1.7.10 and no one fucking knows anymore. Forge, as a software platform, has the authority to say "we aren't going to support that version any more (on our forums, git hub, etc), its too old." 1.12 was dominant for a long time because getting Forge updated for 1.14 took a long time, but it was absolutely worth it. A lot of old kludge was cleaned up and things were made 5000% better. You can still go elsewhere for help, but elsewhere is not here. We also don't know where elsewhere is because we don't support elsewhere.

So after being told flatly to just update to a newer version of MC from 1.12.2 if I want help and having my topic closed, I suppose I'll try taking that admins advice. Would anyone be able to update a list of about 100 mods from different authors from 1.12.2 to a version this forum hasn't obsolesced the knowledge about? Maybe the name of the site should be updated to reflect it's intent.

Locking

Well I'll take all those points in mind, and I don't mean to disrespect your forum, but despite all the reasons forge is better now and why it makes sense you don't support 1.12.2, updating is not an option for me unfortunately. Maybe one day, major, indispensable mods for me like Tough as Nails will be updated, but I guess I'm just shit out of luck until then. One last question: You guys keep telling me about all the other forums where I could get this help; how do they manage to support modding 1.12.2? If that's advice you're giving out, you must believe it's possible to support modding 1.12.2. Just a curious thought.

You're not using Java 8

Isn't that what thread tags are for? I'd imagine someone capable of confidently answering any modding question would have a pretty good idea what works in what versions, especially when the version I'm asking about: Why set a flat rule to refuse those questions rather than leave it to your knowledgeable members to decide how to handle the questions? Make a forum rule to tag your version, etc. If it was once possible to get help with 1.12.2 here, and that knowledge is still being shared and used widely by the player base, I just don't get why that existing knowledge is being taken away from public sources.

Glad you figured it out. :)

Imagine having to write 100-200 json files by hand. Now imagine you had code that would do it for you once and never run again. That's why it's really just code that generates the data files to be loaded up by the data system. You do not need to use it. The code is not executed outside of development unless you manually call it or something.

Unplug game controller/USB device

There's no crash here, just the server kicking people when they try to join before it's done starting up. You also appear to be using Aternos, which I can't say is a reliable or quality server host.

Hi My guess: { "textures": { "particle": "scarlet_alchemy:block/scarlet_smoke_0", "inside": "scarlet_alchemy:block/scarlet_smoke_0" }, "elements": [ { "from": [ 2, 0, 2 ], "to": [ 14, 15, 14 ], "faces": { "up": { "texture": "#inside", "cullface": "up" } } } ] } If you are trying to look at the inside from the bottom of the composter instead of the top, then you should be using "down", not "up". An "up" face with "cullface:up" is invisible from the bottom. It's only visible from the top side of the face, which I'm guessing is inside your block. -TGG

Hi Jay You might find this link useful, although it sounds like you've got a good grasp of the concepts already http://greyminecraftcoder.blogspot.com/2020/03/minecraft-model-basics-rotation-1144.html Something I've found extremely useful while debugging model rotations, translations, and scales is to add in-game tweakable parameters, i.e. typing a command /mbedebug setheadrotation 2 53 6 and seeing what effect it has on the model without having to recompile. See mbe80 in here for an example https://github.com/TheGreyGhost/MinecraftByExample There are lots of traps when rotating and translating and I can never figure it out on paper, I find it easier to get 80% of the way there based on the theory and then get the rest of the way by trial and error. Things that have tripped me up: * order of transformation (translation, rotation) is extremely important and (at least for me) not intuitive. Even when I try to follow the theoretical rules I still usually stuff it up * rotation around an arbitrary point (as you already said) is translate, rotate, translate, but not necessarily in the order/direction you expect * model space vs world space -> your rotations and translations may be around a different axis to what you expect, or around a different origin, and translation may be in the opposite or even in an oblique direction Generally the answer has been: keep model-space and world space transformations separate if vanilla forces you to apply one at a time that you don't want to, you need to transform back from world to model, do your desired transformation, then transform from model back to world again. take baby steps use interactive in-game parameter tweaking of some kind (eg the mbe80 I mentioned above) -TGG

'setupDecompWorkspace' no longer exists. Forge, and by extent ForgeGradle, for 1.13.x received major rewrites, and a lot of things are done very differently. Please do your research before posting here. Also, Java 11 is not supported. Use Java 8, 9 or 10.