Thamus' Texture Treasure Trove

[Emoticone11]

Yes they do.

Okay, well, that's not ideal at all. I wasn't aware of people doing that. If anything that's an argument to move the vanilla crops onto a custom ID (though it'd require Mike to run the block replace script).

Or I can try to make some biome variations of the tilled soil block, if the only reason people are using other blocks is because of climate variations in different biomes.

 

[Margaery_Tyrell]

Really? I don't remember seeing that. Do the blocks break if you place a block adjacent to them?

It works as well as any other block set up that requires no block updates (like candlesticks, flowerpots, etc.) and is only a risk if a builder griefs which we have a good record of. I'm not particularly concerned about block updates.

I'd still like to see a plan for a team to systematically update old builds with any new crop blocks, in the climates where they would be appropriate, before officially adding any.

I don't think is particularly necessary, new crops don't outdate builds as much as for example a new block set, especially since up until now we've used "representational" stand ins of the crops I mentioned that can pass for other crops or variations of them.

In addition making a team to update fields before we even know if we're even getting the crops in the first place also sounds like putting the cart before the horse so to speak.

 

[Emoticone11]

It works as well as any other block set up that requires no block updates (like candlesticks, flowerpots, etc.) and is only a risk if a builder griefs which we have a good record of. I'm not particularly concerned about block updates.

Yes, those aren't good either, and I'd very much like to move them onto custom blocks. The difference is these blocks became used in this manner after they were already present in the game, whereas now we have a choice to either add these crops as custom blocks or purposefully add them in an unstable and hacky way.

Builders accidentally place blocks when they're exploring all the time. I remember the water in the KL sewers being broken a multitude of times before we finally figured out the other water layer ID doesn't break. It's painstaking to fix and usually takes a while to detect, as sometimes the builder doesn't even notice it happen.

We've also known for a long time that WE'd half-banners and half-beds can cause memory leaks (I believe illblew pointed that out a while ago). I have no idea if this is also the case with these types of unstable blocks, but it seems like it's a possibility. Again, I'd rather err on the safe side when we have a choice to do so with little inconvenience to us.

I don't think is particularly necessary, new crops don't outdate builds as much as for example a new block set, especially since up until now we've used "representational" stand ins of the crops I mentioned that can pass for other crops or variations of them.

I disagree that it wouldn't outdate things. What's the point of adding these new crops if they're just substitutes for the existing stand-ins in terms of quality? There is the issue of ambiguous block uses for future RP functionality, certainly, but (a) that idea also seems to outdated old builds, and almost resigns every one to be redone eventually unless there's targeted efforts to update them, and (b) we're already between a rock and a hard place in that regard due to how many of our blocks are used this way. It's hard to tell what'll happen when we get to that point, but based on the UE4 experiments it seems like there's a chance we won't even be relying on MC functionality for that effort, in which case the point is moot.

 

[SseriousBusiness]

Yes, those aren't good either, and I'd very much like to move them onto custom blocks. The difference is these blocks became used in this manner after they were already present in the game, whereas now we have a choice to either add these crops as custom blocks or purposefully add them in an unstable and hacky way.

That can be problematic since a lot of elements are made with WE input like the candles. Changing that, or creating a custom block that doesn’t need a “cheat” would ensue a problem of updating every case in which there are fickle blocks that may disappear after block updates nearby (candles, water metadatas, doors on stairs and whole lot more). If there are ways to do that in a easy way then by all means but candles have placement variations (vertically and horizontally) that could also cause a problem if we used a replace command for example. But I’m no expert so idk what can be done.

 

[Emoticone11]

That can be problematic since a lot of elements are made with WE input like the candles. Changing that, or creating a custom block that doesn’t need a “cheat” would ensue a problem of updating every case in which there are fickle blocks that may disappear after block updates nearby (candles, water metadatas, doors on stairs and whole lot more). If there are ways to do that in a easy way then by all means but candles have placement variations (vertically and horizontally) that could also cause a problem if we used a replace command for example. But I’m no expert so idk what can be done.

Well, it’s just a matter of running an offline replace script, which Mike has already created, on the world data. Candles should be fine, since the vertical/horizontal variations have unique metadata IIRC. Likewise with the other blocks. The issue is that it does require some server downtime, so we’ve been a bit hesitant to do it I guess.

Actually, if there was a way to algorithmically replace stand-in crop blocks with new crop blocks (at least in sufficiently large patches), without affecting any of the other uses of those blocks, that would be the perfect solution. Then we might be able to incorporate that into the replace script somehow.

 

[Margaery_Tyrell]

Yes, those aren't good either, and I'd very much like to move them onto custom blocks. The difference is these blocks became used in this manner after they were already present in the game, whereas now we have a choice to either add these crops as custom blocks or purposefully add them in an unstable and hacky way.

Wouldn't that require replacing all the current crops with these new custom blocks? Turnips, carrots,etc.? Because my main goal is to get the crops in at all and retexturing unused assests seems to be a simpler and faster way of getting them in than waiting for every existing crop to be transitioned in, and then running a world-wide script to replace them with identical copies but with custom blocks.

Builders accidentally place blocks when they're exploring all the time. I remember the water in the KL sewers being broken a multitude of times before we finally figured out the other water layer ID doesn't break. It's painstaking to fix and usually takes a while to detect, as sometimes the builder doesn't even notice it happen.

Right and this very rarely happens with crops

We've also known for a long time that WE'd half-banners and half-beds can cause memory leaks (I believe illblew pointed that out a while ago). I have no idea if this is also the case with these types of unstable blocks, but it seems like it's a possibility. Again, I'd rather err on the safe side when we have a choice to do so with little inconvenience to us.

I don't think crops are going to be an issue with that, since in the half-banner/bed example we're talking about issues of block integrity (along with bed's function as spawn points) vs. blocks that thus far for the last couple of years havent done much of anything in terms of harm and exist perfectly fine in our server where crop growth is functionally halted entirely.

We already have beetroot in the game, I'm just requesting a cosmetic change of texture. Doesn't even have to go on non-farmland blocks :-I

I disagree that it wouldn't outdate things. What's the point of adding these new crops if they're just substitutes for the existing stand-ins in terms of quality?

Because our current stand ins are fairly poor but not poor enough where they warrant an entire sweeping wiping of the slate.

And I'm fairly skeptical of the prospect of making a hypothetical group for redoing crop fields when we don't even know if the retextured blocks are even getting added in the first place. What would be the point if its being pre-emptively being denied already

 

[Elduwin]

Just out of curiosity, what is our blocks ID limit actually? How close are we to reach it?

 

[Thamus_Knoward]

Just out of curiosity, what is our blocks ID limit actually? How close are we to reach it?

It’s at 4096 unique block IDs I believe (and this includes vanilla block IDs). According to the WesterosBlocks.json we started at 2000 and are now at 2206, so it looks like there may still be some room. Especially considering that we’re still carrying sound blocks in the mod.

I dabbled with my own fork of WB briefly and if I remember correctly I maxed out the limit. My Minecraft client ended up consuming upwards of 12 gigs of ram and it took me about 30 mins to boot it up. So that’s something I’d advise against.

I think there is a middle ground in loosening the restrictions on the grounds of redundancy and obsolescence in WB and our RP, but I also concede that Emote’s scrutiny and caution are indeed valid despite my best efforts to test the limits.

 

[Elduwin]

Another (probably naive) question: I guess it's not possible to remove some vanilla block IDs from our pack?

 

[Thamus_Knoward]

Here's the latest ThamPack plus overlay, including the terrainset updates I was working on. The alt packs are on the vanilla stone blocks, for now, 1:1 to 1:4.

Knock yourselves out!

Dropbox

www.dropbox.com

Dropbox - File Deleted - Simplify your life

www.dropbox.com

 

[Thamus_Knoward]

Another update!
- adds alt block for the Stormlands TS
- adjusts the overlay blending between the sets
- adds biome shading for the Dorne TS and the Red Mountains TS
- adds a moss block prototype

Known bugs:
The overlay from the Stormlands TS is shaded which gives that an orange tinge. Will fix that in the next iteration.
There are currently no overlays between some of the terrainsets.
The reach and westerlands overlay still use the old main textures.

/warp terrainsetinfo for further instructions!

Dropbox

www.dropbox.com

Dropbox - File Deleted - Simplify your life

www.dropbox.com

 

[Thamus_Knoward]

Cheeky update:
- replaces all Ores and makes them blend with all terrainsets (except for river and ocean)

See my post here for a visually enticing changelog!

Dropbox

www.dropbox.com

Dropbox - File Deleted - Simplify your life

www.dropbox.com

 

[lemonbear]

Could you make a version of your pack without the sandstone/brick/lp/arbor/oldtown stone and plant changes? The stone changes in particular don't really work with some palettes that currently exist (e.g., they make the Central Westerlands houses look a mess). I do really like the changes with the terrainsets, and what not.

 

[Thamus_Knoward]

Could you make a version of your pack without the sandstone/brick/lp/arbor/oldtown stone and plant changes? The stone changes in particular don't really work with some palettes that currently exist (e.g., they make the Central Westerlands houses look a mess). I do really like the changes with the terrainsets, and what not.

I'll refer you to Emote for that. This is predominantly my test pack. Unfortunately, I don't really have nor do I necessarily want to spend time on making it suit production use. For me it's paramount to keep a fast development cycle and switching out my dev textures every time I release an increment just makes it tedious.

 

[Thamus_Knoward]

I always wanted to do this! The stuff in the center is a new texture for redstone ore that I'm working on.
When I run across it the texture switches and I leave some fiery footprints! :O

 

[Margaery_Tyrell]

I always wanted to do this! The stuff in the center is a new texture for redstone ore that I'm working on.
View attachment 4812When I run across it the texture switches and I leave some fiery footprints! :O

View attachment 4813

I very much support this A+

My only concern is that in the Dragonpit and habited areas of Dragonstone uses redstone ore as normal road and wall materials, so we'd have to replace those redstone blocks in the Dragonpit with normal blocks that don't appear to burst into magma when stepped on. Dragonstone tho should be redone imo

However this should 100% be added in.

 

[Thamus_Knoward]

Here's the latest version of my Overlay pack adjusted to fit with the latest official terrainset release from Emote!

Again, this is not the 'official' pack. But it makes stuff look a lot nicer IMO, so I'm constantly using it. However, use it at your own peril there may be some experimental textures in it.

 

[Margaery_Tyrell]

Can we have a changelog from the previous iteration? I think Im most excited about the ores

Also I think you should also add an overlay for scorched earth, fallen leaves, pine needles and ash blocks as well, since those would benefit a lot from a "scatter" effect

 

[AerioOndos]

If ash, pine needles and fallen leaves spread onto other blocks around them, that would be very cool, yeah!

 

[Margaery_Tyrell]

I did spot a small issue with plasters, theres a checkboard floor pattern in two rooms in Highgarden made from brown plaster and white plaster that ends up with this: