Minecraft Forums

Well, we already know that connected models is possible (fences, stairs, and glass panes have it in vanilla), and so are random models. We just need some way to do it that doesn't fool with the block data.

Quote from Rocket_Scientist»

After my quick glance, I think CTM works like this: When a block instance is created, it checks for the north icon of each block around it. If it's the same block, and has CTM textures, it changes it's texture, then tells the other blocks immediately around it to perform this process. Then it does the same for south, east, west, top and bottom sides. So as far as I can tell, he wouldn't need to make a new model for every single combination, because it checks only for the properties the block has been to to (vertical, horizontal, etc.). Even so, Kahr wouldn't have to make any models because default uses no custom models. As for resource pack authors, I can confirm with the right program, it's not that tough to make three models for a ladder. Plus, many features already work, such as random textures.
Other than that, I completely agree with you that it wouldn't be a simple task.
(I would also like to keep in mind that there will be entity models on the way)

You are missing the Point. Kahr doesnt need to do ANY models. As this is for Ressourcepacks.
But you would still need a Ton of Model files. Because the Point of Custom Models is that you can have Details on the Model. Those need to Align with the Texture. If you just swap the Texture out. It Looks like ****.
Because of That, you have to make way more Models than you would have to make Textures. And even though a "Ladder Model" is fairly Easy and Fast to make. (Its the Easiest Block, also you can have Random Models already in Vanilla, so there is no need for MC patcher there).
For Example the Bookshelf. You would need way more than 3 Models. Just think about the Possible Conections you can have with Bookshelfs that would have to be Connected.
Connected Models like, like CTM is right now, is just not feasible.

Interesting would be a way to, as I said, Replace Specific Blocks and Items, that contain specific data, with specific models.

Quote from kwerti jumpWell, we already know that connected models is possible (fences, stairs, and glass panes have it in vanilla), and so are random models. We just need some way to do it that doesn't fool with the block data.

Fences, Stairs, and Glass Panes use rather Limited amount of Possible Connections. Even though they have quite the amount of Models.
My Point is not that it isnt doable. (Well, afaik there is no way of Storing additional Data on placed Blocks anymore, so it is kinda not doable for Blocks at least). Its just not a sane amount of work (and in my Opinion performance, I made my Leaves like those from better Gradd and Leaves and they suck Performance like hell) for Connected Models.

Quote from LanToaster»

Fences, Stairs, and Glass Panes use rather Limited amount of Possible Connections. Even though they have quite the amount of Models.
My Point is not that it isnt doable. (Well, afaik there is no way of Storing additional Data on placed Blocks anymore, so it is kinda not doable for Blocks at least). Its just not a sane amount of work (and in my Opinion performance, I made my Leaves like those from better Gradd and Leaves and they suck Performance like hell) for Connected Models.

"Horizontal CTM" is what the vanilla blocks have now (none, n, ne, ns, nse, nsew). Vertical CTM needs only four models (none, top, bottom, middle). H+V and V+H will be these two combined. The only one that's remotely hard is full CTM, which is really only useful for pipe setups, and would need only a few more base models (none, n, ne, ns, nse, ney, nsew, nsey, nsewy, nsewyd). I should also mention stair-like setups; I'm not sure where they fit.

This is assuming that the models can be rotated into other positions (with uv-lock) and that the corners are not counted for connections. If not, then yes, there will have to be vastly more models.

In theory, for Connected Models, all you would need to do is have 1 texture, and 2 .properties and one <model>.json



The 1 Texture= The connected model image. More will be needed for more models you wish to use more Connected Textures

The 2 .properties= 1 for the connected textures, the other for the model

The .json= The 3D model.

Quotes (to keep post small) ^
Thanks for the replies. This will be a very hard blow to my community, we have had these features for years, lot of creations will be ruined :/ I guess my only hope now is the never to be released mod api. In any case, I will most certainly have to be more creative than ever to save as many projects as possible

MCPatcher sucks

i did everything Gestankfaust said in the Install tab but it doesn't work i ran it as admin not as admin and i goto the game i put my resource packs in the folder and click the pack i want to use (LB Photo Realism 128x) and it click play and it crashes

no its not just that texture pack iv tried over 10 (all my texture packs) and i did what you just said and i got optifine

i want optifine for the added settings and zoom also optifine for some reason doesn't fix the textures of my texture pack

Kahr has specifically said that Optifine and MCPatcher are incompatible. Please avoid using them together

when trying to generate a mojang-frame-compass/clock from the custom-designed components in mcpatcher/dial (outputFrames=n) this fails, simply because MCPatcher can not create the direcory minecraft:item/clock.png or even mine craft:item/compass.png beneath .mine craft. Is apparently a bug linked to item-ids > item-names.

MultiMC is compatible with MC Patcher?

Quote from Miliardo»

McPatcher is not detecting LiteLoader 1.8 at all, it detects liteloader 1.7.2 and my other profiles just not my liteloader 1.8 profile. Any ideas what could be causing this?

I can see why this is occurring, but haven't figured out how to work around it. In the .minecraft\versions\1.8-LiteLoader1.8 folder, there is no 1.8-LiteLoader.jar file. This file is what McPatcher looks for, for the pulldown menu. Apparently since 1.8, LiteLoader does not need to create this file. I tried a couple of things, but they didn't work. I copied the 1.8.jar file to that folder and renamed it to 1.8-LiteLoader.jar. McPatcher found it and patched it. When I ran that profile, that file was ignored. I put that file in the 1.8 version folder and named it 1.8.jar, but Minecraft downloaded a new one and replaced it. I tried running McPatcher first, but LiteLoader replaced the patched file with a newly downloaded one. From OP of both authors of these programs it appears that neither of them realize this problem exists or the instructions on how to deal with this isn't understood by us non-programmers.

I posted my problem about getting version 1.8 McPatcher and LiteLoader to work together, (see above) on the LiteLoader thread, and received this reply from killjoy1221.

___________________________________________________________________________________________________

" I've posted it here before (I think), but I recently made a new page for it.


Without having to modify json files, this is probably the best way to use MCPatcher with Liteloader. It even makes it so FML doesn't complain.

http://mnm-mods.blogspot.com/p/mcpatcher-repackager.html "

____________________________________________________________________________________________________

The solution worked for me and was able to get Liteloader to use the McPatcher patched .jar file.