Considering there's a new "trend" to put crop blocks on non-farmland blocks, can we get new wheat/barley/carrot/turnip/pease blocks so we have consistency in what we allow to use underneath and to make them stable.
Westeroscraft Texture Pack Megathread
- Thread starter Emoticone11
- Start date
-
The Spring 2023 edition of The Rookery is now out! Take a look to see the latest builds, guides, progress and development updates on the upcoming 1.18.2 switch. You can read it here:
https://indd.adobe.com/view/f943da18-ed77-4d55-845d-fee9bfa14247
_Simbaa
Printmaker
- Pronouns
- they/them
- Pronouns
- they/them
A few requests for the Arbor:
- 1st, is it possible to retexture a bit the Arbor Brick set? the contrast is too high, and there's a 1 pixel thin line bordering the block that prevents the block to blend with the other arbor blocks.
- ask for new blocks: a small brick set (like OT bricks set and Reach light stone set, no need for small bricks and light small bricks); and if possible a specific OT light stone (to match the OT set of blocks, between the Arbor light stone and the Reach light stone).
- fences with vines with white grape (to match the white grape foliage), and maybe no necessity to have the 4 wood fences, but just to have at least one to match, because it's strange to have black grapes on fences and white grapes on foliages.
I know all about the necessity to limit the addition of blocks, I just feel that the Arbor set is currently flawed and not working on its own. And the OT light stone would imo help a lot both palettes, OT and Arbor. I prefer to ask for those before going too far in building the Arbor and realizing that we'd need those blocks to make things right.
Happy to discuss that in game @Emotione11!
- 1st, is it possible to retexture a bit the Arbor Brick set? the contrast is too high, and there's a 1 pixel thin line bordering the block that prevents the block to blend with the other arbor blocks.
- ask for new blocks: a small brick set (like OT bricks set and Reach light stone set, no need for small bricks and light small bricks); and if possible a specific OT light stone (to match the OT set of blocks, between the Arbor light stone and the Reach light stone).
- fences with vines with white grape (to match the white grape foliage), and maybe no necessity to have the 4 wood fences, but just to have at least one to match, because it's strange to have black grapes on fences and white grapes on foliages.
I know all about the necessity to limit the addition of blocks, I just feel that the Arbor set is currently flawed and not working on its own. And the OT light stone would imo help a lot both palettes, OT and Arbor. I prefer to ask for those before going too far in building the Arbor and realizing that we'd need those blocks to make things right.
Happy to discuss that in game @Emotione11!
Last edited:
Arbor blocks currently have light stone, cobble and bricks. I'd like to add small bricks block (the shape of the OT bricks and Reach light stone, but for the Arbor). It's kinda hard to describe as our sets doesn't use the same names for the same blocks shapes haha, like the equivalent of the OT bricks are the Reach light stone, and would probably be the Arbor small bricks (as the Arbor bricks already exists).
And I suggested that there's no need to have 2 different hues of those bricks, like we have in the OT palette (oldtown brick / light oldtown brick) and the grey palette (light grey stone / faint light grey stone).
And I suggested that there's no need to have 2 different hues of those bricks, like we have in the OT palette (oldtown brick / light oldtown brick) and the grey palette (light grey stone / faint light grey stone).
Would love to hear it! Going to be finishing up a small update with the leaf fixes soon, so I need to make a decision whether to include those or not.
Thamus_Knoward
Shadowbinder
I may not correctly remember the issue at hand, but there are apparently 4 sets of metadata that the leaf block uses. When you have two or possibly more leaf blocks on top of each other, the top one will get the final set while the bock below will be the middle set. I need help to investigate this further, but maybe this could be used to give the top set the snow-covered look?
Turns out that leaves in the north (or on the trees I checked in treetest) are either of the 'no decay' or 'no decay and check decay' type, while the hedges at Rousemont are the first four data values/ metadata.. I find that very curious but maybe something we can use here.
http://puu.sh/FHYwG/7a50b81bb5.png
Turns out that leaves in the north (or on the trees I checked in treetest) are either of the 'no decay' or 'no decay and check decay' type, while the hedges at Rousemont are the first four data values/ metadata.. I find that very curious but maybe something we can use here.
http://puu.sh/FHYwG/7a50b81bb5.png
Last edited:
Margaery_Tyrell
The Dark Lord Sauron
Wouldnt that result with snow leaves in places we dont want them to be.
Because I know for a fact that a great deal of trees in The Reach for example uses not just the first four but a great deal of the bottom 9 as well. In fact some of our older schems do this
Because I know for a fact that a great deal of trees in The Reach for example uses not just the first four but a great deal of the bottom 9 as well. In fact some of our older schems do this
Just based on what you said it sounds like it could be a difference between hand-built/worldpainter/old WE leaves and ones created with FAWE, but that's just a hunch.
I don't think that we actually need to select only the top part of the trees to replace with snowy leaves, I was just thinking of replacing all of the leaves with the snowy spruce block. So they look like these. We just make sure to only do the replace above the snow boundary. The only issue I'm trying to figure out is how to do this massive replace in the first place.
I don't think that we actually need to select only the top part of the trees to replace with snowy leaves, I was just thinking of replacing all of the leaves with the snowy spruce block. So they look like these. We just make sure to only do the replace above the snow boundary. The only issue I'm trying to figure out is how to do this massive replace in the first place.
I just need 20 good men.
Was playing around with striations on the new terrainsets a bit. I did the following really quickly and it can probably be improved a bit.
Method: create one translucent color overlay for each type of striation you want (currently I have 3 with varying shades of brown). Define one properties file for each of these, using the 'overlay_fixed' method. Use the 'heights' field in each file to define the heights that you want the striations to occur on.
Flaws:
- can only make darker striations rather than lighter ones (in principle, this can be solved by making the base texture lighter, and having a color overlay that returns it to its previous darkness which occurs at all heights except the light striation ones)
- will occur at the same heights no matter what, so will basically look like a big line going through the terrain without any variation. Not sure if there's any way to improve on this, although using 'overlay_random' or 'overlay_repeat' might be able to break up the homogeneity a little bit.
Thoughts? esp. @Thamus_Knoward ? I don't really have much time to work on this right now, but it might be something to keep in mind for the future.
Method: create one translucent color overlay for each type of striation you want (currently I have 3 with varying shades of brown). Define one properties file for each of these, using the 'overlay_fixed' method. Use the 'heights' field in each file to define the heights that you want the striations to occur on.
Flaws:
- can only make darker striations rather than lighter ones (in principle, this can be solved by making the base texture lighter, and having a color overlay that returns it to its previous darkness which occurs at all heights except the light striation ones)
- will occur at the same heights no matter what, so will basically look like a big line going through the terrain without any variation. Not sure if there's any way to improve on this, although using 'overlay_random' or 'overlay_repeat' might be able to break up the homogeneity a little bit.
Thoughts? esp. @Thamus_Knoward ? I don't really have much time to work on this right now, but it might be something to keep in mind for the future.
- Pronouns
- they/them
I still think it's worth messing around with a bit more. If you combine it with a very wide 'repeat' CTM where only some of it is the striation overlay, combined with the height restriction, you might actually be able to create striations which don't just form horizontal stripes like that.
Thamus_Knoward
Shadowbinder
My tip would be to run slightly angled striations on a repeat CTM maybe angled 25-35 degrees.
Crazy thought, but is it possible to do a 256xN repeat_overlay (where N is something sufficiently large that it doesn't tile badly), using a small handful of tile images (just solid colors of varying hues/opacities), and automatically generating tiles=<string> in the properties file from a photoshop document where we paint the striations over the terrainset in a handful of layers with each solid color on its own layer?
Thamus_Knoward
Shadowbinder
Sure, here's what I've been using:
If we're going to try a very large repeat_overlay, we wouldn't need the 'heights' fields anymore, and could just use a single .properties file generated as I mentioned above. We'll probably want to play around with the overlay hues/opacities a bit and add more, I just chose three somewhat randomly. Also we'd have to do the thing I mentioned earlier if we want light striations.
If we're going to try a very large repeat_overlay, we wouldn't need the 'heights' fields anymore, and could just use a single .properties file generated as I mentioned above. We'll probably want to play around with the overlay hues/opacities a bit and add more, I just chose three somewhat randomly. Also we'd have to do the thing I mentioned earlier if we want light striations.