1.19.3?
RoonMoonlight opened this issue · 19 comments
Does this mod requires update to 1.19.3? if not please mark it as 1.19.3 compatible on CurseForge and Modrinth.
Most mods will require updating every minor version now since the junk that mojang decided to do this update.
I'll leave this issue open until the mod is updated but it should take a bit.
Can you update this mod some faster?
Patience is key bro. They are working on it so wait a little more
If you can't wait try contributing and make a pull request by yourself
So update for today:
There is a "working" version in the 1.19.3 branch but it's missing a very important feature which is the ability to load textures from outside of the standardized vanilla models. Releasing it in this state will break a lot of packs who store the texture next to the cit or outside of the default textures directories.
If you know what you are doing feel free to compile the 1.19.3 branch and it should load packs with cits that specify models explicitly and do the folders like they are in vanilla. If not, it's gonna take a while longer until I find a solution and even then it'd be a gross workaround.
If anyone has any ideas for working around this to allow old packs to load, please let me know.
@SenTony I would love to see you try and update if you think it's that easy. Please, go ahead. We are waiting :/
@SHsuperCM I'm don't think that updating is easy! I'm just playing on a server with my modpack and the server just updated to 1.19.3! I wanna to update modpack and this beautiful and unbelievable mod also in my modpack! To sum it up - Sorry!
@YoungSoulluoS sorry to interrupt, but you already have experience working on CEM, could you help with this question for CITResewn? 😊
Maybe the author of CIT should have a look at the CEM code and how textures and models are loaded there.
@YoungSoulluoS sorry to interrupt, but you already have experience working on CEM, could you help with this question for CITResewn? 😊
I'm not good at coding. It's not the same thing to refine what's ready and create it from scratch. Well, I'll have a look for interest.
Let's I do it later, I currently so busy. I had plans for port this mod into snapshots (currently known as 1.19.3).
I think I found a way around the atlas bullshit but it's not elegant for current code and it still has a few broken things in it. Gonna need to do some more testing.
Maybe the author of CIT should have a look at the CEM code and how textures and models are loaded there.
Sadly dorianpb/cem has nothing yet that tackles the issues I'm facing with 1.19.3.
@unit-a-user
Let's I do it later, I currently so busy. I had plans for port this mod into snapshots (currently known as 1.19.3).
I just saw the PR, thank you for your work but the 1.19.3 branch is already ahead of it. (closing the pr)
I think I found a way around the atlas bullshit but it's not elegant for current code and it still has a few broken things in it. Gonna need to do some more testing.
@SHsuperCM, why bypass it when you can join it 
@SHsuperCM, why bypass it when you can join it
? Just create your own atlases.
Whoops, sorry, I didn't mean bypass it as in not use it. I meant I found a way to add textures to the same "blocks" atlas that items use normally (also using paths I tell it to use). Right now what's still buggy is figuring out how to select the textures properly because there are some instances where adding the textures in the /cit/ directories is not enough and even if it was, it's against the performance increase that mojang wanted to achieve.
there are some instances where adding the textures in the
/cit/directories
@SHsuperCM, I think we should put the resource pack creators in some kind of frame of reference here, as well as ask them NOT to use broken IDs.
Mojang is trying to create some sort of standard for resource packs, and it would be nice to integrate mods into their ecosystem.
Above I just add a custom atlas source, but would like to coordinate a common atlas source for the optifine directory.
I would like to know your proposal for a solution to this problem.
Asking resourcepack creators to adhere to a standard isn't a viable solution as long as optifine is alive. People will always come in and complain that something is working on optifine but isn't on our mods. We should definitely advocate for it but we cannot rely on them listening. This is the reason I made broken paths something people must opt into, that way new pack creators are aware that it's just an extra unnecessary step that users would have to do.
What I'm going for with CIT Resewn is supporting (*some*) legacy stuff to allow some packs to work without much change. If we know already that, for example, certain cits are adding certain textures, it would be simpler to solve custom texture paths on the mod's side, rather than the pack creators'.
Above I just add a custom atlas source, but would like to coordinate a common atlas source for the optifine directory.
That's what I recently figured to do as well. For now I just added the assets/ROOT/cit directories(and their subdirectories) to the blocks atlas as well, I believe the next step for CIT Resewn would be to do something a little more clever than that to only add requested textures but I need to do more research and testing.
If you ask me, I'd say I'm against creating a common atlas source for the optifine directory as the whole purpose of the atlas change in 1.19.3 was to load resource packs faster which we would go against by adding the entire "optifine" directory or related directories. At that point it would be much clearer for pack creators if we just let them specify atlas sources(like mojang is doing).
Okay I need to do a little more bug testing, cleanup and look at some PRs but expect a 1.19.3 version within the next day if everything goes right.
Okay I need to do a little more bug testing, cleanup and look at some PRs but expect a 1.19.3 version within the next day if everything goes right.
That's great news! Thanks for your efforts.