Change your pack_format from 1 to 2 in pack.mcmeta.
Why is it 1 vs. 2 rather than 1.8 (or just "1") vs. 1.9? And why a blanket incompatibility message? It's not a new format, just some changes to model display/blockstate files. Any pack that focuses on just textures should be compatible with 1.8 and 1.9. If anything, seems like a "model_format" would be a more useful check... or just if a pack is pack_format 1 AND contains models (rather than all pack format 1 packs).
Speaking of that, it'd be nice if with pack_format 1 as it is now to automatically compensate for the display changes in the snapshot... 300+ model files to go through and look for display settings to change the rotation and scale by a set value isn't gonna be fun. Even if it wasn't a general pack feature, but a specifically enabled "resource pack author mode" that only worked on pack folders and actually overwrote the changes, that'd be better that nothing. (if that existed, changing model file names to a more sane, unified format would be really great, too)
Also, if you're going to break compatibility on things, please break them more so there is a reason to have 1.9 specific packs and so we have benefits NOW rather than something to go without that'd be a lone compatibility break later if you decide to do it. Mainly, please go back and un-stitch many of the textures that were left behind on the resource pack transition: allowing them to have dedicated names (less confusing on what they are), future compatibility (future additions will have a dedicated image rather than a blank spot that older packs won't show at all), multiple resolutions etc. (using folders for more organization of images that used to be in one image before, if needed)
give the slider handle a dedicated texture rather than taken from buttons
moon phases (not that important compared to everything else, but not much reason not to)
I mean, if you're going to break things, break EVERYTHING so we get the benefits. 1.8 was already like a new pack format for any packs using models, requiring a dedicated version (1.7 won't use it the same way). 1.9 will be the same if entity models/GLSL shaders happen to be usable in resource packs... so the only ones losing out are basic packs that wish to offer overarching support of versions... still they can have the 1.8 version that supports mostly everything and then a 1.9 version (or even a 1.9 add-on!) to fix that (plus block/item textures will still be compatible).
Unrelated to all of this, with the iron bar cages in the end, horizontal iron bars iron grate(?) (that are like pane-thin slabs that have a top/bottom orientation and connect similar to iron bars, able to make a perfect iron-bars cube) would be really nice. Edit: http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2488277-1
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
Apparently it only checks the version when you initially load minecraft.
"2" was the first thing I tried, but it remained red, and "incompatable" until I restared minecraft.
Not just the version but the whole pack.mcmeta, it only gets check on initial load, it's a pain when you are trying to lay out some nice coloured text and you have to keep restarting the client.
So, I don't suppose anyone here is making an automated way to adjust for the display differences, like a shell script?
I mean, I could do a shell script, but I'm not that keen on regular expressions that would probably take to do it. Plus it seems like the scale values have changed a bit (it might just be me, but GUI/item frame display seems like it increased in size WAY less than every other display setting).
I'm not sure on if any more than basic math would be needed for that (specifically GUI scale and trying to get it in the middle)
@The_Fool76, you're into that kinda thing, right? Terminal-ly things, penguin-y things? (anyone else? I know thecrazydueSRD uses Linux, not sure if script-y, though) I don't recall you having models though, so might not be an issue for you....
Unless people can clue me in on regex/rotation+scale+translation offsets (and any division needed, esp. with relation to scale and translation?) and maybe I could cobble something together?
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
Has anyone exparamented adding "multipart" support to other blocks?
Works perfectly fine. I used it briefly on my end portal frame (and it worked), though I did end up removing that since it was not really needed in that case.
So, I don't suppose anyone here is making an automated way to adjust for the display differences, like a shell script?
I mean, I could do a shell script, but I'm not that keen on regular expressions that would probably take to do it. Plus it seems like the scale values have changed a bit (it might just be me, but GUI/item frame display seems like it increased in size WAY less than every other display setting).
I'm not sure on if any more than basic math would be needed for that (specifically GUI scale and trying to get it in the middle)
@The_Fool76, you're into that kinda thing, right? Terminal-ly things, penguin-y things? (anyone else? I know thecrazydueSRD uses Linux, not sure if script-y, though) I don't recall you having models though, so might not be an issue for you....
Unless people can clue me in on regex/rotation+scale+translation offsets (and any division needed, esp. with relation to scale and translation?) and maybe I could cobble something together?
I have a few block models I've updated for my sci-fi themed Mooncraft pack so I'll probably have to wrestle with this a little. I'll let you know if I come up with an automated way to do this. It might be a while though as I've not really been terribly active on the whole minecraft texture front since the Bukkit meltdown and sale to M$. (What I really want is the blasted plugin API thing but those events kinda soured me on that dream.)
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
Has the option to disable "alternate blocks" been taken away permanently or is it just temporarily missing? If so, does that mean we have to make our own custom block model/etc. in order to negate it?
Has the option to disable "alternate blocks" been taken away permanently or is it just temporarily missing? If so, does that mean we have to make our own custom block model/etc. in order to negate it?
Having it on really ruins tiling:
From what I can tell, it is permanent, since fire now uses that to make its block model randomized, rather than relying on an additional four tags or so to do that.
In either case though, I would advise disabling the random models in your resource pack even if the option was still there. It seems nicer to not force a user to change their options to use a resource pack, plus it allows you to randomize other models. I did whipped up a resource pack awhile ago with does just that. Feel free to copy the files into your pack(s) if desired (no credit needed)
And this multipart stuff whould work fine for directional CTM, right? I haven't tried it yet, but it looks like it should work...
As Kwerti said, not for blocks without available blockstates. So, not normal blocks.... more advanced culling would be needed for that. Just being able to cull faces when specified side of a block ISN'T present would probably (AND cull it when another one is present, without this it will any CTM attempt sacrifes inter-block culling so internal faces are still rendered) would be the least needed to make it possible, but that would be really annoying to work with as you'd need all of your faces for CTM layered into an overlay. With as much control as multipart for culling you could do it (for example, CTM vertical connection on north face, when the exact scenario is matched, the face is culled (and rendered in the exact opposite scenario):
Writing it out makes it seem much simpler than I thought. HOWEVER this would not even be a full replacement for classic CTM.... since you just have what blocks are present to go by, you can't control them as far as CTM does.... meaning you can't get the stupid corners (the ones with 1 px that confuses just about everyone, any block with 4 connections on it would be the same as the innermost CTM tile).
The best you could do would be a bit more than horizontal+vertical connection... if I'm thinking about it correctly, it'd be 14-tile CTM:
1 tile, no connections
1 tile, all connections
4 tiles, horizontal+vertical
4 tiles, T-connection
4 tiles, corners
This is easily represented as a 5-px + with a square connecting the ends.
As for CTM+multipart? It doesn't make anything possible that wasn't possible before, just might make it easier to do so. A good example for the possibility is probably iron bars/glass panes, or even better yet, redstone. Redstone is a pretty good example since it has the most complicated set of connections.
Previously, you had to make each possible state into a model (minus rotation of course, unless before UV lock) even when it's just a combo of certain parts of a model turned on and off. Making exceptions to that was not easy because then you had to make even MORE models and then go into the blockstate file and work all of that out....
The only way this could be easier is if you could translate/scale multipart models, and if you could so exceptions directly (I don't think there is any way to do this currently.. just carefully laying out how you define the "when" statements).
Also, in another way multipart somewhat has fixed-CTM-like features...
PSA:
The inclusion of Multipart (at least testing in 15w31c) now allows for editing states that aren't editable with traditional variants (see MC-60242 for details) with the requirement that you entirely use multipart. Yeah, that'll be tedious for something like hoppers where it might work fine with just 1 part model for the "disabled" versions but instead you've got to completely remake the model in multipart.
allows you to give a jukebox with record in it.... a model that actually shows the record in it.
So, as long as you're using 100% multipart, you can fix the horridly broken tripwires (making the tripwire move like it used to, or make a laser tripwire for sci-fi packs), do leaf decay textures, actual "someone is in that bed" model (really only for servers) and a few other things... well, theoretically... I haven't tested it all yet, so I'm assuming that, barring states not being applied correctly (like dispensers and the "triggered" state) that stuff should work.
From what I can tell, it is permanent, since fire now uses that to make its block model randomized, rather than relying on an additional four tags or so to do that.
Uhh, that doesn't make sense.... vanilla uses it, so ability to remove it is gone? I think it's more likely that there was a snag with disabling random models from multipart. Or maybe they accidentally deleted it with the super secret settings button? Hahaha..... I can't really think of a logical explanation on why it'd be removed. Then again, it's the same way with the SSS button.
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
Made simple "CTM" for reeds, different texture if there is no block above. Crashed the texture pack when used with reeds, however works fine when used on the chrous plant, which is aware of adjacent blocks of the same type.
EDIT:
Is there some kind of formatting chang, or change in strictness? Some of the custom models i've made with different geometry, such as doors, and trapdoors are reduced to the dreaded magenta and black box. There doesn't seem to be any inheritance issues, they just chain back to JSON in my texture pack. Other custom models i've made work just fine, like the 3d mushrooms.
I saw somewhere that //comments aren't allowed, but I don't use those.
I don't really have any familiarity with JSON outside of texture packs.
Made simple "CTM" for reeds, different texture if there is no block above. Crashed the texture pack when used with reeds, however works fine when used on the chrous plant, which is aware of adjacent blocks of the same type.
EDIT:
Is there some kind of formatting chang, or change in strictness? Some of the custom models i've made with different geometry, such as doors, and trapdoors are reduced to the dreaded magenta and black box. There doesn't seem to be any inheritance issues, they just chain back to JSON in my texture pack. Other custom models i've made work just fine, like the 3d mushrooms.
I saw somewhere that //comments aren't allowed, but I don't use those.
I don't really have any familiarity with JSON outside of texture packs.
Don't you have a text editor with syntax highlighting for .JSON? I use a basic one (Gedit, it's on Linux) and it does it by default (just highlighting, no code collapsing or anything fancy like that).
Also, not only does sugarcane not have useful states, it doesn't cull itself either... like mine hide the top/bottom faces perfectly but will only be culled by a solid block.
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
Don't you have a text editor with syntax highlighting for .JSON? I use a basic one (Gedit, it's on Linux) and it does it by default (just highlighting, no code collapsing or anything fancy like that).
Thanks! that solves the problem (though it worked fine in 1.8)
There is highlighting in my editor, but I didn't know what the colors meant. Now I know that grey means "error".
Why is it 1 vs. 2 rather than 1.8 (or just "1") vs. 1.9? And why a blanket incompatibility message? It's not a new format, just some changes to model display/blockstate files. Any pack that focuses on just textures should be compatible with 1.8 and 1.9. If anything, seems like a "model_format" would be a more useful check... or just if a pack is pack_format 1 AND contains models (rather than all pack format 1 packs).
Speaking of that, it'd be nice if with pack_format 1 as it is now to automatically compensate for the display changes in the snapshot... 300+ model files to go through and look for display settings to change the rotation and scale by a set value isn't gonna be fun. Even if it wasn't a general pack feature, but a specifically enabled "resource pack author mode" that only worked on pack folders and actually overwrote the changes, that'd be better that nothing. (if that existed, changing model file names to a more sane, unified format would be really great, too)
Also, if you're going to break compatibility on things, please break them more so there is a reason to have 1.9 specific packs and so we have benefits NOW rather than something to go without that'd be a lone compatibility break later if you decide to do it. Mainly, please go back and un-stitch many of the textures that were left behind on the resource pack transition: allowing them to have dedicated names (less confusing on what they are), future compatibility (future additions will have a dedicated image rather than a blank spot that older packs won't show at all), multiple resolutions etc. (using folders for more organization of images that used to be in one image before, if needed)
Things like:
I mean, if you're going to break things, break EVERYTHING so we get the benefits. 1.8 was already like a new pack format for any packs using models, requiring a dedicated version (1.7 won't use it the same way). 1.9 will be the same if entity models/GLSL shaders happen to be usable in resource packs... so the only ones losing out are basic packs that wish to offer overarching support of versions... still they can have the 1.8 version that supports mostly everything and then a 1.9 version (or even a 1.9 add-on!) to fix that (plus block/item textures will still be compatible).
Unrelated to all of this, with the iron bar cages in the end,
horizontal iron barsiron grate(?) (that are like pane-thin slabs that have a top/bottom orientation and connect similar to iron bars, able to make a perfect iron-bars cube) would be really nice. Edit: http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2488277-1"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
Thank you. *hugs*
Is this a temporary stand-in for the versioning system? Really should've included a little PSA about it in the blog post if it's here to stay.
Apparently it only checks the version when you initially load minecraft.
"2" was the first thing I tried, but it remained red, and "incompatable" until I restared minecraft.
EDIT: Note that previous versions of MC do not object to loading a pack of set to "2".
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Not just the version but the whole pack.mcmeta, it only gets check on initial load, it's a pain when you are trying to lay out some nice coloured text and you have to keep restarting the client.
https://www.johnsmithlegacy.co.uk/ - John Smith Legacy for Minecraft
Has anyone exparamented adding "multipart" support to other blocks?
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
I can tell you that it does work. I replaced vines' blockstate with multipart and it worked perfectly.
Putting the CENDENT back in transcendent!
So, I don't suppose anyone here is making an automated way to adjust for the display differences, like a shell script?
I mean, I could do a shell script, but I'm not that keen on regular expressions that would probably take to do it. Plus it seems like the scale values have changed a bit (it might just be me, but GUI/item frame display seems like it increased in size WAY less than every other display setting).
I'm not sure on if any more than basic math would be needed for that (specifically GUI scale and trying to get it in the middle)
@The_Fool76, you're into that kinda thing, right? Terminal-ly things, penguin-y things? (anyone else? I know thecrazydueSRD uses Linux, not sure if script-y, though) I don't recall you having models though, so might not be an issue for you....
Unless people can clue me in on regex/rotation+scale+translation offsets (and any division needed, esp. with relation to scale and translation?) and maybe I could cobble something together?
"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
Works perfectly fine. I used it briefly on my end portal frame (and it worked), though I did end up removing that since it was not really needed in that case.
I have a few block models I've updated for my sci-fi themed Mooncraft pack so I'll probably have to wrestle with this a little. I'll let you know if I come up with an automated way to do this. It might be a while though as I've not really been terribly active on the whole minecraft texture front since the Bukkit meltdown and sale to M$. (What I really want is the blasted plugin API thing but those events kinda soured me on that dream.)
And this multipart stuff whould work fine for directional CTM, right? I haven't tried it yet, but it looks like it should work...
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
I would think you are only able to use existing blockstates in multipart.
Putting the CENDENT back in transcendent!
Having it on really ruins tiling:
From what I can tell, it is permanent, since fire now uses that to make its block model randomized, rather than relying on an additional four tags or so to do that.
In either case though, I would advise disabling the random models in your resource pack even if the option was still there. It seems nicer to not force a user to change their options to use a resource pack, plus it allows you to randomize other models. I did whipped up a resource pack awhile ago with does just that. Feel free to copy the files into your pack(s) if desired (no credit needed)
As Kwerti said, not for blocks without available blockstates. So, not normal blocks.... more advanced culling would be needed for that. Just being able to cull faces when specified side of a block ISN'T present would probably (AND cull it when another one is present, without this it will any CTM attempt sacrifes inter-block culling so internal faces are still rendered) would be the least needed to make it possible, but that would be really annoying to work with as you'd need all of your faces for CTM layered into an overlay. With as much control as multipart for culling you could do it (for example, CTM vertical connection on north face, when the exact scenario is matched, the face is culled (and rendered in the exact opposite scenario):
"render_when": {"north":false, "east":false, "west":false, "up":true, "down":true}
This also wouldn't work so well because glass against a wall would cause culling, so again:
"render_when": {"north": "false", "east": "false_self", "west": "false_self", "up": "true_self", "down": "true_self"}
Writing it out makes it seem much simpler than I thought. HOWEVER this would not even be a full replacement for classic CTM.... since you just have what blocks are present to go by, you can't control them as far as CTM does.... meaning you can't get the stupid corners (the ones with 1 px that confuses just about everyone, any block with 4 connections on it would be the same as the innermost CTM tile).
The best you could do would be a bit more than horizontal+vertical connection... if I'm thinking about it correctly, it'd be 14-tile CTM:
This is easily represented as a 5-px + with a square connecting the ends.
As for CTM+multipart? It doesn't make anything possible that wasn't possible before, just might make it easier to do so. A good example for the possibility is probably iron bars/glass panes, or even better yet, redstone. Redstone is a pretty good example since it has the most complicated set of connections.
Previously, you had to make each possible state into a model (minus rotation of course, unless before UV lock) even when it's just a combo of certain parts of a model turned on and off. Making exceptions to that was not easy because then you had to make even MORE models and then go into the blockstate file and work all of that out....
The only way this could be easier is if you could translate/scale multipart models, and if you could so exceptions directly (I don't think there is any way to do this currently.. just carefully laying out how you define the "when" statements).
Also, in another way multipart somewhat has fixed-CTM-like features...
PSA:
The inclusion of Multipart (at least testing in 15w31c) now allows for editing states that aren't editable with traditional variants (see MC-60242 for details) with the requirement that you entirely use multipart. Yeah, that'll be tedious for something like hoppers where it might work fine with just 1 part model for the "disabled" versions but instead you've got to completely remake the model in multipart.
Example, blockstate file jukebox.json:
{
"multipart": [
{"when": { "has_record": "false" }, "apply": { "model": "jukebox"}},
{"when": { "has_record": "true" }, "apply": { "model": "jukebox_has_record"}}
]
}
allows you to give a jukebox with record in it.... a model that actually shows the record in it.
So, as long as you're using 100% multipart, you can fix the horridly broken tripwires (making the tripwire move like it used to, or make a laser tripwire for sci-fi packs), do leaf decay textures, actual "someone is in that bed" model (really only for servers) and a few other things... well, theoretically... I haven't tested it all yet, so I'm assuming that, barring states not being applied correctly (like dispensers and the "triggered" state) that stuff should work.
Uhh, that doesn't make sense.... vanilla uses it, so ability to remove it is gone? I think it's more likely that there was a snag with disabling random models from multipart. Or maybe they accidentally deleted it with the super secret settings button? Hahaha..... I can't really think of a logical explanation on why it'd be removed. Then again, it's the same way with the SSS button.
"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
Confirmed. ;(
Made simple "CTM" for reeds, different texture if there is no block above. Crashed the texture pack when used with reeds, however works fine when used on the chrous plant, which is aware of adjacent blocks of the same type.
EDIT:
Is there some kind of formatting chang, or change in strictness? Some of the custom models i've made with different geometry, such as doors, and trapdoors are reduced to the dreaded magenta and black box. There doesn't seem to be any inheritance issues, they just chain back to JSON in my texture pack. Other custom models i've made work just fine, like the 3d mushrooms.
I saw somewhere that //comments aren't allowed, but I don't use those.
I don't really have any familiarity with JSON outside of texture packs.
here's an example:
{
"ambientocclusion": false,
"textures": {
"particle": "blocks/door_birch_lower",
"back": "blocks/door_birch_lower",
"front": "blocks/door_birch_lower-rh",
"edge": "blocks/door_birch-edge"
},
"elements": [
{
"from": [0,0,13],
"to": [3,16,16],
"faces": {
"down": {
"uv": [13,0,16,3],
"texture": "#edge",
"rotation": 90
},
"west": {
"texture": "#front",
"cullface": west
},
"east": {
"uv": [3,0,0,16],
"texture": "#back"
},
"north": {
"uv": [6,0,3,16],
"texture": "#edge"
},
"south": {
"uv": [5,0,8,16],
"texture": "#edge"
}
}
},
{
"from": [0,0,3],
"to": [3,12,13],
"faces": {
"up": {
"uv": [2.5,3.5,13.5,6.5],
"texture": "#edge",
"rotation": 90
},
"down": {
"uv": [2.5,0,13.5,3],
"texture": "#edge",
"cullface": down,
"rotation": 90
},
"west": {
"texture": "#front",
"cullface": west
},
"east": {
"uv": [13,4,3,16],
"texture": "#back"
}
}
},
{
"from": [1.5,12,3],
"to": [1.5,16,13],
"faces": {
"down": {
"texture": "#front"
},
"west": {
"texture": "#front",
"cullface": west
},
"east": {
"uv": [13,0,3,4],
"texture": "#back"
}
}
},
{
"from": [0,0,0],
"to": [3,16,3],
"faces": {
"down": {
"texture": "#edge",
"rotation": 90
},
"west": {
"texture": "#front"
},
"east": {
"uv": [13,0,16,16],
"texture": "#back"
},
"north": {
"texture": "#edge"
},
"south": {
"texture": "#edge"
}
}
}
]
}
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Your cullfaces are wrong. For example, you got:
"cullface": west
should be:
"cullface": "west"
Don't you have a text editor with syntax highlighting for .JSON? I use a basic one (Gedit, it's on Linux) and it does it by default (just highlighting, no code collapsing or anything fancy like that).
Also, not only does sugarcane not have useful states, it doesn't cull itself either... like mine hide the top/bottom faces perfectly but will only be culled by a solid block.
"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 use comments and have had no issues, sometimes the files can be confusing so comments do make them a little easier to follow.
For example, fence_inventory.json in the model directory has comments making the file a little easier to understand.
https://www.johnsmithlegacy.co.uk/ - John Smith Legacy for Minecraft
Thanks! that solves the problem (though it worked fine in 1.8)
There is highlighting in my editor, but I didn't know what the colors meant. Now I know that grey means "error".
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
He means adding comments by preceding them with two slashes, not comments by using a dummy tag.
I've noticed another issue with models in the snapshots.
You don't have to provide UV coordinates for each side. Opl's model creator didn't always, but it looked fine in 1.8.
However in the snapshots it presumably makes different assumptions about the UV coordinates and the textures are often? always? misaligned.
I don't know what the different UV assumptions are based on-- any insight would probably help a lot with repairing my models.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help