This guide is really helpful I could like to a model tv with a gif file too like it is showing a tv doing like minecraft steve walking then the tv turns off that will be great for feature models for others
I'm working on some built-in "better grass", as part of the basic grass block.
The problem is obvious. With Smooth Lighting ON, whenever the grass block is next to another block, sticking-up grass turns realy dark. With no Smooth lighting it looks fine. I don't want to turn the lighitng off for the whole block.
Any way, I can exempt the sticking-up grass from this shading?
I'm working on some built-in "better grass", as part of the basic grass block.
The problem is obvious. With Smooth Lighting ON, whenever the grass block is next to another block, sticking-up grass turns realy dark. With no Smooth lighting it looks fine. I don't want to turn the lighitng off for the whole block.
Any way, I can exempt the sticking-up grass from this shading?
Erm, I'm confused as to why you're calling it "better grass" as I remember that being where it tries to make sides of blocks have full textures as if they're actual hills.... unless you're referring to the grass in the successor "better grass and leaves mod"?
What you seem to want is removing ambient occlusion on those elements which I don't think is possible (it's a block-wide option...). Have you tried instead using "shade":false on those faces? Even if it doesn't stop ambient occlusion, maybe it will reduce the darkening and make it overall more blended in?
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
....unless you're referring to the grass in the successor "better grass and leaves mod"?
That's it. Also it is "better" or would be without this shading glitch.
Have you tried instead using "shade":false on those faces? Even if it doesn't stop ambient occlusion, maybe it will reduce the darkening and make it overall more blended in?
The screenshot uses "shade":false on those elements. It was slightly worse without it. The spoiler contains the .JSON.
I believe your issue is MC-51447, or the game does not properly account for lighting on models. For some reason, it determines the face's lighting based on the side rather than the cullface direction (as would make sense, with no cullface setting it to maximum light) for said block)
I believe your issue is MC-51447, or the game does not properly account for lighting on models. For some reason, it determines the face's lighting based on the side rather than the cullface direction (as would make sense, with no cullface setting it to maximum light) for said block)
I agree. I have tried every possible fix on solving this problem. Really annoying. If someone has a solution that works I'd love to know.
I decided to turn off Ambient Occlusion for the block. Not an ideal solution but for most people I think it will detract, less than the grass adds.
Cullfacing only activates for opaque blocks, right? I'd like to make it a bit taller, but then it will stick up through carpets. Carpet doesn't seem to activate the culling of those faces, unless i'm doing it wrong.
Cullfacing only activates for opaque blocks, right? I'd like to make it a bit taller, but then it will stick up through carpets. Carpet doesn't seem to activate the culling of those faces, unless i'm doing it wrong.
For the most part, yes. Opaque blocks will cull other blocks, although a few transparent blocks also have self culling.
I thought of that, but the wiki says you can't use "variant" and "multipart".
While that is true, he means directly applying both pieces separately using only multipart, as multipart applies models for all conditions that match, even if said conditions are the same.
While that is true, he means directly applying both pieces separately using only multipart, as multipart applies models for all conditions that match, even if said conditions are the same.
Yep, that's what I meant. However, I found out that AO for the whole block is taken from the first model applied, so it's useless for working around the AO bug.
The black goes away, that's what I meant. I'm making a bookcase model and had the same problem (so solid block), the books inside the model were really dark. Later I was setting the face culling for optimization reasons and somehow it fixed the texture. Just keep in mind it's not the matter of setting it to true or false... Face culling makes it so if the model is covered by another block from for example north, and you select the textures that will not be visible (when covered by that block) and you set the cull face to north, these textures will be invisible (they'll not be rendered) when in north there is a solid block.
Basically, set the cullface to the side that the face should receive its lighting from, for example your grass should disappear if a block is placed above, thus its cullface should be set to "up". It does only seem to work when smooth lighting is disabled though.
Apparently there is a solution as stated by Arzim in the opl's Model Creator thread
Basically, set the cullface to the side that the face should receive its lighting from, for example your grass should disappear if a block is placed above, thus its cullface should be set to "up". It does only seem to work when smooth lighting is disabled though.
I was trying to wrap my head around this when I realized that this needs a disclaimer that it's only a partial fix to MC-51447 and not a fix to MC-51113 (your issue).
Because your issue things that don't have any logical cullface at all since the faces don't touch (or exceed) normal block boundaries (or in some cases, because it's visible from all directions rather than just 1), like my redstone model that has darkened faces when you put a block over it. I mean both issues are really part of the same coin with the same cause: the game is arbitrarily darkening faces it thinks should be culled, the difference is their issue almost has a fix and yours doesn't.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Yep, just about to post that. Walls work because they have that 'up' state.
The closest you could get would be to make the when argument to apply the post in all scenarios except only N-S or E-W (which would be annoying/overcomplicated since you can't just do multipart normally and then add specific overrides for exact states) but then that would make any fences above it disconnected since they'd have a post with no lower attachments.
This might actually be something you could do with modding (specifically Meddle), or at least I assume so given that when loading a world without that mod (and thus no "up" state) the game would just remove that state and use it like a normal fence. Well, not sure how this would treat existing fences.... I guess it depends on if their states are evaluated more than once or if it'd need a chunk update.
If you know about multi-part, better parent combination, and predicates, that's about the span of what we got in 1.9. Hardly anything really 'new' is possible with these new features, it just makes those things a ton easier. Like multipart means doing models like vines is now a sane thing to do (same for redstone, but that actually wasn't too bad especially for the outcome) and now clocks/compasses aren't hardcoded so you specify the model, but you could actually use animations to do animated models before (this change means you can probably do more advanced stuff that wouldn't be optimal before, tradeoff being generated models also got overcomplicated since each frame needs a model file).
So I'd say the only real 'new' features we got relate to predicates, specifically the ability to change model based on damage (which is a bit gimmicky IMO, I don't feel like making a bent/cracked sword) and the ability to add more frames into the bow pulling animation (which we have extremely limited rotations and thus shapes anyways, so more frames are unneeded except for gimmicky PVP packs). Lefthanded is a thing but I honestly don't think most people are going to use it for the intended purpose... stack size would have been useful but was left out because of faulty logic concerning durability/stack size conflicts even though nothing in the game that has durability can stack (and if it could, you'd just make it not stack if it is damaged)
Hey guys, don't want to take the painstaking task of converting 1.8 clock/compass animations to the ok-I-get-it-cool-for-models-though-I-could-do-that-with-the-animations-before-so-a-bit-too-complex-for-regular-items-1.9 format?
There IS a better way now, introducing this thing I've been making for the past few days, a python-fu script for GIMP:
Open desired 1.8 clock and/or compass animations (the RIGHT-most file seems to be the one that uses the filter)
Go to filters>Python-Fu>console
Paste the script's content
???
If everything runs smoothly, no red text will appear and comments will show up with info
(if you opened clock AND compass, close the one it just did, clear the console and hit enter, and then paste the script again.... if any issues occur, try doing each image individually and then closing GIMP before you run it again)
Tell me what you think! This is probably the most 'real' coding I've done, first time working with Python, it wasn't too bad (although I'd prefer semicolons to whitespace in most cases) so those of you with more coding experience should get some other converters finished, hehe...
Also, it was quite easy to do the clock.... but the compass? Gah. Instead of using it like the clock does, it's offset to start in the middle and then loop back.... BUT that's just the model order, the image numbers are used the same as clocks. That took me considerably longer than other parts.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
but i think about using more some of the block states and more variants... i don't have my own fire graphics yet, and the possibility to use fire age states could be interesting. Maybe.
One thing that's REALLY annoying is the lightning bug, i saw that there seems to be a fix, but i didn't understand it yet.
Saywhatnow? DOES fire have age state now? I legitimately have no way to tell, it's not used in the fire's blockstate file and f3 doesn't show states for fire. Also, more states+variants are you referring to how tweaking variant setups or using (full) multipart to put models to previously hardcoded states (like jukebox has_record, tripwire powered state, hopper enabled, etc.) or modding in more states as I mentioned?
I discussed the lighting bug on the last page in depth if you'd like to look. The TL;DR is that it isn't fixed in smooth lighting and it actually isn't fixable in all scenarios.
Basically speaking, if you've re-modelled a FULL BLOCK and it has the issue, you can fix it (for fast lighting) by properly setting the cullface on all faces that can be obscured... to the face they can be obscured by. Like if you added indents to the crafting table on the north side, the "shelves" should have cullface set to "north". If you make faces that pop out they should cull because of the face they're on, too.
The bug is not at all fixable for models that don't have applicable culling on faces that are darkened, for example 3D redstone. This is what truly makes it a bug, because it darkens faces it thinks should be culled even if there is no way they would be, therefore no user fix.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
http://minecraft.gamepedia.com/Block_state , the new ones are marked with upcoming... well, there's only fire (is the age tag even new? Not sure anymore), command blocks and some unused structure block (yet), so not that interesting. Wiki has some scattered information here and there. The german version of the Wiki is really nicely done, helped me a lot to bet back into it, i'm looking forward to the 1.9 update there. Example: http://minecraft-de.gamepedia.com/Modelldaten – look at all those examples!
Slightly off topic: the current version the English wiki's model page is based on the German version of the article, as the German wiki has a few more model experts than the English one.
They seemed to have updated it quite a bit since that time (lots of helpful examples there), so I might eventually try to translate some of the new content into a tutorial on the English wiki (as its a little out of bounds for a regular article)
I imagined that i can see the small cubes through the transparent parts of the big one, but that's of course not possible. Textures aren't visible from the inside... What solution did you have in mind there?
Sadly, the rendering limitation imposed on most opaque blocks don't allow transparency. If you cutout the texture and it was replaced with a solid color, that's your issue. The only block I think I've actually done this with is item frames, and I wanted to do it with doors and I never got around to it.
If the cutout works, then you have another issue. Make sure that the element designed for the inside is completely inverted-the from and to should be switched. IIRC you might also want to mess around with the coordinates of the textures to make them render properly as well. How you have it drawn out there, you'd also want to make the cullface based on what face it's embedded on, like if that's the north face all sides would be culled by north.
EDIT: I'm a bit confused by some of what you said, like that last line, but if I've hit all the wrong marks and you're doing this for something like stained glass and want to see it from the other side, don't forget about backface culling.... which means you'll have to duplicate the element and invert it (in this case, UNinvert it), mess with the texture coordinates and which face is deleted etc. yet again.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
I have been making a resource pack that disables the tintidex on grass , leaves, and plants.
Since Mojang refuses to remove/exerntalize the hard-coded tints that RUIN almost any resource pack theme, I've decided to completely disable the biome tinting.
This has been going well, aside from one major problem.
the tallgrass model appears to just ignoring that I removed tintIndex from it completely.
I had my friend send me error logs to see if something was wrong with the file, but only error was with the vine_u model, that I've fixed.
Since this is happening, I am forced to watch sugarcane and any tall grass variant clash horribly with everything else I've done in this pack. Ofc, maybe I should just scrap the whole thing.
There any reason besindes Mojang being either incompitent or evil with the "user customization" features of minecraft that I am still getting biome-tinted reeds and grass? If I can disable this on the grass block, and leaves, and vines, and lillypads, then...IT SHOULD FREAKING WORK ON THE GRASS, TALLGRASS, AND SUGARCANE.
I have had the tint turned off on sugarcane since that was an option and it works perfectly fine. I would advise checking that the model is indeed being changed to make sure your tintless model is actually being used.
If it is, please pack up just the relevant model files (please, I can't really download large files) in a valid resource pack zip so I can check it out.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
I have had the tint turned off on sugarcane since that was an option and it works perfectly fine. I would advise checking that the model is indeed being changed to make sure your tintless model is actually being used.
If it is, please pack up just the relevant model files (please, I can't really download large files) in a valid resource pack zip so I can check it out.
I have since learned to create packs with an optimized filesize, so I'll send the whole pack, a whopping 23 kb!
All it does is completely breaks the color tinting applied to plants and grass, and it changes the related grayscales out with colored textures. http://crystalien-redux.com/unrelated/ETX/noTint.zip
I should warn you that the classic grass and oak leaves also make a return.
Some people may not like those textures. Personally, they don't bother me.
So far, I think it's only been tested in the 1.9 snapshots
I cannot test it myself, because of computer issues, so I've been having my friend do it.
p.s
sorry for late reply, has been a busy day.
(also, since certain ad providers have successfully bypassed adblock, these forums are chewing the RAM and CPU up)
So far, I think it's only been tested in the 1.9 snapshots
OK, here's the issue: 1.9 changed the name of the 'tallgrass.json' file you used to be more accurate: 'tinted_cross.json'. Change it accordingly and all your issues should be fixed.
Grass seemed to work already for me... unless when you said "GRASS, TALLGRASS, AND SUGARCANE" you meant "tallgrass, double tallgrass, and sugarcane" in which case it is indeed fixed.
p.s.: You should probably make sure your UVs are flipped on the opposite side of 2D faces (compare the 'tinted_cross.json' file against your own) so it doesn't have a magical spinny effect when you walk around it (particularly bad with lopsided textures). The problem you have with vines is also probably because vines have switched over to multipart (makes it much easier!) and you're trying to use the 1.8 way.
p.p.s: you might want to try uBlock origin. It blocks about the same (if not better) and has lower resource requirements. That and Disconnect (causes some issues sometimes like with twitter stuff unless you turn that part off, but blocks tracking stuff and lowers data usage around 10%).
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
This guide is really helpful I could like to a model tv with a gif file too like it is showing a tv doing like minecraft steve walking then the tv turns off that will be great for feature models for others
FireMario211
Youtube:
FireMario211
Skype:
FireMario211
Steam:
FireMario211
Planetminecraft:
FireMario211
IGNMC:
FireMario211
Games I play on steam:
Terraria
Garry's Mod
My website:
flamingcraft3.enjin.com
Xbox Gamer tag Xbox360/XboxOne:
FireMario211
I'm working on some built-in "better grass", as part of the basic grass block.
The problem is obvious. With Smooth Lighting ON, whenever the grass block is next to another block, sticking-up grass turns realy dark. With no Smooth lighting it looks fine. I don't want to turn the lighitng off for the whole block.
Any way, I can exempt the sticking-up grass from this shading?
{
"__comment": "Model generated using MrCrayfish's Model Creator (http://mrcrayfish.com/modelcreator/)",
"elements": [
{ "from": [ 0, 0, 0 ],
"to": [ 16, 16, 16 ],
"faces": {
"down": { "uv": [ 0, 0, 16, 16 ], "texture": "#bottom", "cullface": "down" },
"up": { "uv": [ 0, 0, 16, 16 ], "texture": "#top", "cullface": "up", "tintindex": 0 },
"north": { "uv": [ 0, 0, 16, 16 ], "texture": "#side_a", "cullface": "north" },
"south": { "uv": [ 0, 0, 16, 16 ], "texture": "#side_a", "cullface": "south" },
"west": { "uv": [ 0, 0, 16, 16 ], "texture": "#side_b", "cullface": "west" },
"east": { "uv": [ 0, 0, 16, 16 ], "texture": "#side_b", "cullface": "east" }
}
},
{ "from": [ 0, 0, 0 ],
"to": [ 16, 16, 16 ],
"faces": {
"north": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay-side_a", "tintindex": 0, "cullface": "north" },
"south": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay-side_a", "tintindex": 0, "cullface": "south" },
"west": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay-side_b", "tintindex": 0, "cullface": "west" },
"east": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay-side_b", "tintindex": 0, "cullface": "east" }
}
},
{
"name": "s_grass",
"from": [ 0, 16, 12.5 ],
"to": [ 16, 17.9, 12.5 ],
"rotation": { "origin": [ 8, 8, 8 ], "axis": "y", "angle": 45, "rescale": false },
"shade": false,
"faces": {
"north": { "texture": "#short_grass", "uv": [ 0, 14, 16, 16 ], "cullface": "up", "tintindex": 0 },
"south": { "texture": "#short_grass", "uv": [ 16, 14, 0, 16 ], "cullface": "up", "tintindex": 0 }
}
},
{
"name": "w_grass",
"from": [ 3.5, 16, 0 ],
"to": [ 3.5, 17.9, 16 ],
"rotation": { "origin": [ 8, 8, 8 ], "axis": "y", "angle": 22.5, "rescale": false },
"shade": false,
"faces": {
"east": { "texture": "#short_grass", "uv": [ 0, 2, 16, 4 ], "cullface": "up", "tintindex": 0 },
"west": { "texture": "#short_grass", "uv": [ 16, 2, 0, 4 ], "cullface": "up", "tintindex": 0 }
}
},
{
"name": "n_grass",
"from": [ 0, 16, 3.5 ],
"to": [ 16, 17.9, 3.5 ],
"rotation": { "origin": [ 8, 8, 8 ], "axis": "y", "angle": 22.5, "rescale": false },
"shade": false,
"faces": {
"north": { "texture": "#short_grass", "uv": [ 0, 10, 16, 12 ], "cullface": "up", "tintindex": 0 },
"south": { "texture": "#short_grass", "uv": [ 16, 10, 0, 12 ], "cullface": "up", "tintindex": 0 }
}
},
{
"name": "e_grass",
"from": [ 12.5, 16, 0 ],
"to": [ 12.5, 17.9, 16 ],
"rotation": { "origin": [ 8, 8, 8 ], "axis": "y", "angle": 45, "rescale": false },
"shade": false,
"faces": {
"east": { "texture": "#short_grass", "uv": [ 0, 6, 16, 8 ], "cullface": "up", "tintindex": 0 },
"west": { "texture": "#short_grass", "uv": [ 16, 6, 0, 8 ], "cullface": "up", "tintindex": 0 }
}
}
]
}
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Erm, I'm confused as to why you're calling it "better grass" as I remember that being where it tries to make sides of blocks have full textures as if they're actual hills.... unless you're referring to the grass in the successor "better grass and leaves mod"?
What you seem to want is removing ambient occlusion on those elements which I don't think is possible (it's a block-wide option...). Have you tried instead using "shade":false on those faces? Even if it doesn't stop ambient occlusion, maybe it will reduce the darkening and make it overall more blended in?
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
That's it. Also it is "better" or would be without this shading glitch.
The screenshot uses "shade":false on those elements. It was slightly worse without it. The spoiler contains the .JSON.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
I believe your issue is MC-51447, or the game does not properly account for lighting on models. For some reason, it determines the face's lighting based on the side rather than the cullface direction (as would make sense, with no cullface setting it to maximum light) for said block)
I agree. I have tried every possible fix on solving this problem. Really annoying. If someone has a solution that works I'd love to know.
I believe that 1.9 multipart may allow one to apply two models to one block: one with AO, and another without AO.
edit: Nope, that doesn't work. AO and particle textures don't work well with multipart anyway.
Putting the CENDENT back in transcendent!
Cullfacing only activates for opaque blocks, right? I'd like to make it a bit taller, but then it will stick up through carpets. Carpet doesn't seem to activate the culling of those faces, unless i'm doing it wrong.
I thought of that, but the wiki says you can't use "variant" and "multipart".
Just vote for an keep updating the bug report.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
For the most part, yes. Opaque blocks will cull other blocks, although a few transparent blocks also have self culling.
While that is true, he means directly applying both pieces separately using only multipart, as multipart applies models for all conditions that match, even if said conditions are the same.
Yep, that's what I meant. However, I found out that AO for the whole block is taken from the first model applied, so it's useless for working around the AO bug.
Putting the CENDENT back in transcendent!
Apparently there is a solution as stated by Arzim in the opl's Model Creator thread
Basically, set the cullface to the side that the face should receive its lighting from, for example your grass should disappear if a block is placed above, thus its cullface should be set to "up". It does only seem to work when smooth lighting is disabled though.
I was trying to wrap my head around this when I realized that this needs a disclaimer that it's only a partial fix to MC-51447 and not a fix to MC-51113 (your issue).
Because your issue things that don't have any logical cullface at all since the faces don't touch (or exceed) normal block boundaries (or in some cases, because it's visible from all directions rather than just 1), like my redstone model that has darkened faces when you put a block over it. I mean both issues are really part of the same coin with the same cause: the game is arbitrarily darkening faces it thinks should be culled, the difference is their issue almost has a fix and yours doesn't.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Yep, just about to post that. Walls work because they have that 'up' state.
The closest you could get would be to make the when argument to apply the post in all scenarios except only N-S or E-W (which would be annoying/overcomplicated since you can't just do multipart normally and then add specific overrides for exact states) but then that would make any fences above it disconnected since they'd have a post with no lower attachments.
This might actually be something you could do with modding (specifically Meddle), or at least I assume so given that when loading a world without that mod (and thus no "up" state) the game would just remove that state and use it like a normal fence. Well, not sure how this would treat existing fences.... I guess it depends on if their states are evaluated more than once or if it'd need a chunk update.
If you know about multi-part, better parent combination, and predicates, that's about the span of what we got in 1.9. Hardly anything really 'new' is possible with these new features, it just makes those things a ton easier. Like multipart means doing models like vines is now a sane thing to do (same for redstone, but that actually wasn't too bad especially for the outcome) and now clocks/compasses aren't hardcoded so you specify the model, but you could actually use animations to do animated models before (this change means you can probably do more advanced stuff that wouldn't be optimal before, tradeoff being generated models also got overcomplicated since each frame needs a model file).
So I'd say the only real 'new' features we got relate to predicates, specifically the ability to change model based on damage (which is a bit gimmicky IMO, I don't feel like making a bent/cracked sword) and the ability to add more frames into the bow pulling animation (which we have extremely limited rotations and thus shapes anyways, so more frames are unneeded except for gimmicky PVP packs). Lefthanded is a thing but I honestly don't think most people are going to use it for the intended purpose... stack size would have been useful but was left out because of faulty logic concerning durability/stack size conflicts even though nothing in the game that has durability can stack (and if it could, you'd just make it not stack if it is damaged)
Also posting this again. Not sure if anybody has used it because nobody has replied that they have. Note, clocks and compasses are currently borked (clocks spin at noon and compasses spin in a bunch of conditions when pointed at spawn) so that's not my fault.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Saywhatnow? DOES fire have age state now? I legitimately have no way to tell, it's not used in the fire's blockstate file and f3 doesn't show states for fire. Also, more states+variants are you referring to how tweaking variant setups or using (full) multipart to put models to previously hardcoded states (like jukebox has_record, tripwire powered state, hopper enabled, etc.) or modding in more states as I mentioned?
I discussed the lighting bug on the last page in depth if you'd like to look. The TL;DR is that it isn't fixed in smooth lighting and it actually isn't fixable in all scenarios.
Basically speaking, if you've re-modelled a FULL BLOCK and it has the issue, you can fix it (for fast lighting) by properly setting the cullface on all faces that can be obscured... to the face they can be obscured by. Like if you added indents to the crafting table on the north side, the "shelves" should have cullface set to "north". If you make faces that pop out they should cull because of the face they're on, too.
The bug is not at all fixable for models that don't have applicable culling on faces that are darkened, for example 3D redstone. This is what truly makes it a bug, because it darkens faces it thinks should be culled even if there is no way they would be, therefore no user fix.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Slightly off topic: the current version the English wiki's model page is based on the German version of the article, as the German wiki has a few more model experts than the English one.
They seemed to have updated it quite a bit since that time (lots of helpful examples there), so I might eventually try to translate some of the new content into a tutorial on the English wiki (as its a little out of bounds for a regular article)
Sadly, the rendering limitation imposed on most opaque blocks don't allow transparency. If you cutout the texture and it was replaced with a solid color, that's your issue. The only block I think I've actually done this with is item frames, and I wanted to do it with doors and I never got around to it.
If the cutout works, then you have another issue. Make sure that the element designed for the inside is completely inverted-the from and to should be switched. IIRC you might also want to mess around with the coordinates of the textures to make them render properly as well. How you have it drawn out there, you'd also want to make the cullface based on what face it's embedded on, like if that's the north face all sides would be culled by north.
EDIT: I'm a bit confused by some of what you said, like that last line, but if I've hit all the wrong marks and you're doing this for something like stained glass and want to see it from the other side, don't forget about backface culling.... which means you'll have to duplicate the element and invert it (in this case, UNinvert it), mess with the texture coordinates and which face is deleted etc. yet again.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
I have been making a resource pack that disables the tintidex on grass , leaves, and plants.
Since Mojang refuses to remove/exerntalize the hard-coded tints that RUIN almost any resource pack theme, I've decided to completely disable the biome tinting.
This has been going well, aside from one major problem.
the tallgrass model appears to just ignoring that I removed tintIndex from it completely.
I had my friend send me error logs to see if something was wrong with the file, but only error was with the vine_u model, that I've fixed.
Since this is happening, I am forced to watch sugarcane and any tall grass variant clash horribly with everything else I've done in this pack. Ofc, maybe I should just scrap the whole thing.
model file for tall grass:
There any reason besindes Mojang being either incompitent or evil with the "user customization" features of minecraft that I am still getting biome-tinted reeds and grass? If I can disable this on the grass block, and leaves, and vines, and lillypads, then...IT SHOULD FREAKING WORK ON THE GRASS, TALLGRASS, AND SUGARCANE.
Is there a model file I'm missing?
Do I need to modify a blockstate?
I have had the tint turned off on sugarcane since that was an option and it works perfectly fine. I would advise checking that the model is indeed being changed to make sure your tintless model is actually being used.
If it is, please pack up just the relevant model files (please, I can't really download large files) in a valid resource pack zip so I can check it out.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
I have since learned to create packs with an optimized filesize, so I'll send the whole pack, a whopping 23 kb!
All it does is completely breaks the color tinting applied to plants and grass, and it changes the related grayscales out with colored textures.
http://crystalien-redux.com/unrelated/ETX/noTint.zip
I should warn you that the classic grass and oak leaves also make a return.
Some people may not like those textures. Personally, they don't bother me.
So far, I think it's only been tested in the 1.9 snapshots
I cannot test it myself, because of computer issues, so I've been having my friend do it.
p.s
sorry for late reply, has been a busy day.
(also, since certain ad providers have successfully bypassed adblock, these forums are chewing the RAM and CPU up)
OK, here's the issue: 1.9 changed the name of the 'tallgrass.json' file you used to be more accurate: 'tinted_cross.json'. Change it accordingly and all your issues should be fixed.
Grass seemed to work already for me... unless when you said "GRASS, TALLGRASS, AND SUGARCANE" you meant "tallgrass, double tallgrass, and sugarcane" in which case it is indeed fixed.
p.s.: You should probably make sure your UVs are flipped on the opposite side of 2D faces (compare the 'tinted_cross.json' file against your own) so it doesn't have a magical spinny effect when you walk around it (particularly bad with lopsided textures). The problem you have with vines is also probably because vines have switched over to multipart (makes it much easier!) and you're trying to use the 1.8 way.
p.p.s: you might want to try uBlock origin. It blocks about the same (if not better) and has lower resource requirements. That and Disconnect (causes some issues sometimes like with twitter stuff unless you turn that part off, but blocks tracking stuff and lowers data usage around 10%).
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin