List of Schematic Brushes

[Kor_Bro]

Added some new schems for the Neck.

Trees:
&SwampCypress
&SwampAshL
&SwampPineL

Also:
&Vines

(creates a column of vines of varying lengths emanating downward from where you click)

Awesome Schematics Loras, perfect for the neck!
SwampCypress8 seems to have a bit of glass at the top. A quick /schset remove SwampCypress SwampCypress8@**^x and then add in the the same one without the glass should do the trick!

Looking forward to seeing these being used!

 

[Kor_Bro]

New Schematics for more Birch forest:

MixedNorthernBirchM
MixedNorthernBirchS

Also, I took Carc's bocage schemset CarcBocage3 and made jungle and birch leaf versions:

JungleBocage
BirchBocage

 

[Thamus_Knoward]

Hey guys, do we have a guide somewhere of how to make a new schemset including a guide on how to make new schems?

 

[an_escaped_duck]

@oOIOoMajic knows

 

[CashBanks]

I've found mike's guide pretty useful:
Commands
Examples

 

[Thamus_Knoward]

@CashBanks Nifty! But that doesn't really seem to cover how to make the schems in the first place.

 

[CashBanks]

Mhmm looks like Mike's guide assumes the reader already knows how to create a schematic file, and just wants to know how to add them to schsets.

This guide shows how to create them, see how you go with Mike's guide from there.

 

[SerLoras]

@CashBanks Nifty! But that doesn't really seem to cover how to make the schems in the first place.

Most of the time you choose a name for the schemset you want to make (e.g. "Oak"), then you'll want to build all the oak trees you want in your schemset. You should select each oak tree you've made (making sure the selection is as small as possible and the tree is centered inside the selection) and copy it. (It doesn't matter where you stand when you copy it). After you copy the selection to you can save that selection as a schem ("//schem save Oak1"). You'll want to do this for each indvidual tree and name the shems accordingly (e.g. "Oak1", "Oak2", Oak3", etc.).

Most Schem sets on the server are created with a command like "//schset create Oak Oak*@**^10".

The first asterisk includes all the schems starting with "Oak" (e.g. "Oak1", "Oak2", Oak3", etc.) and randomly chooses one of them. The second two asterisks cause the schem to be randomly rotated and flipped when it is placed to create a wider variety of tree types.

The "^10" is the vertical offset. Each schem will need a different vertical offset number depending on how tall the schem is. By default the schem is placed at its center point. That means without a vertical offset most trees schems would be placed half way underground. I usually have to go through a little trial and error to find the perfect vertical offsets that causes the trees to be properly placed. If you get the vertical offset wrong, I find the easiest option is usually to delete the schemset ("//schset delete Oak") and try creating the set again with a different vertical offset.

It is a good idea to make all the selections for each tree in your schemset the same height so that they will all have the same vertical offsets even if the trees themselves are slightly different heights. Otherwise you will have to determine the vertical offset for each individual tree and your schem set creation command would have to look something like this "//schset create Oak Oak1@**^10 Oak2@**^9 Oak3@**^11".

(If any of those commands don't work, try them with one "/" instead of two. I always forget which ones need one and which ones need two.)

 

[Thamus_Knoward]

Thanks for the guide @SerLoras !! That should be pinned imo its super important!

I've created the sets WillowSFreshPoll, WillowSOnePoll, and WillowSTwoPoll. First is freshly pollarded willows, second and third are one and two years after pollarding respectively. Added pics to the wikia! https://westeroscraft.fandom.com/wiki/SchemSets

 

[Emoticone11]

Just to elaborate on @SerLoras 's helpful tutorial above (I meant to write one up a while ago, but haven't had the time):

I've found that using the same vertical offset for all the trees in the schemset doesn't work in general. I'm not sure exactly how the placement logic works, but sometimes I've had issues where an offset that works for one tree doesn't work at all for another tree of similar height.

Because of this, I usually prefer to add trees to the schemset incrementally. You should be able to create an empty schemset just by doing //schset create Oak.

If you have an existing schemset, and know the vertical offset you want, you can add another schematic to it by doing "//schset append Oak OakM1@**^10". Note that I'm using the specific schematic OakM1 here, without the wildcard.

Make sure you get the vertical offset correct before you add to the schemset. You can remove schematics from the schemset, but you have to use the exact schematic string as when you added it, including any rotation and offset information, i.e. "//schset remove Oak OakM1@**^10". You probably won't remember the exact rotation/offset information you used, which makes this a bit annoying and error-prone.

You can play around with offsets by just using the normal schembrush with a fixed schematic (and not a schemset). That is, "//schbr OakM1@**^10". Try a few different offsets, paste a few trees, and see what offset works. Then append that schematic+offset to the schemset. Repeat for all of the schematics you want to add to the schemset.

 

[SerLoras]

I've found that using the same vertical offset for all the trees in the schemset doesn't work in general. I'm not sure exactly how the placement logic works, but sometimes I've had issues where an offset that works for one tree doesn't work at all for another tree of similar height.

I have always found that as long as the selection for the trees are the exact same height and ground level for every tree is at the same point in that uniform selection size then the same vertical offset will apply to each tree schem.

Say for example you build all of you trees in within the same 30 block high box and you make ground level for every tree be at be at a block height of 5 within that selection. You can make different trees within that 30 block box that are 25, 26, 27, 28, etc. blocks high, but since the selection size and the ground level block height for each tree is uniform the actual physical height of the tree doesn't matter. Each tree schem would by defualt (with no offset) be placed at the half way point of the selection height (about block 15), and then you need a uniform vertical offset of 10 to bring the placement point to your desired the ground level point (block 5). That should be the same for every tree.

The key is to be sure you have a uniform selection height for every tree schem AND that ground level for every tree is at a uniform height within the selection. AFAIK air blocks and solid blocks within a schem selection are treated the exact same way as far and height and vertical offsets go, so it is the size of the red WE selection box you use to create schem, not the height of the solid blocks within the selection that control.

 

[SerLoras]

Also if you are using just a general schem brush to test your schem set, make sure you redo the brush command after making any changes to the schem set.

For example, you could do "//schset create Oak Oak*@**^10" and then do "//scbhr &Oak" to test the new schem with a schem brush. Then you could decide you need to change the vertical offset, so you do "//schset delete Oak" and then "//schset create Oak Oak*@**^11". Don't use that same schem brush you were using before! You need to redo the schem brush command ("//scbhr &Oak"), otherwise the brush will still use the schem set configuration that existed when it was created, and it won't reflect the changes you have just made to the schem set.

I spent a great deal of time editing schem sets and then trying to test them with a brush, and being frustrated that nothing had changed after the edit. It was because I wasn't redoing the //schbr command after the edit.

 

[Thamus_Knoward]

Im just gonna record some annoyances with TreeTest and Schems here:
- Poplar schematics have seemingly wildly different dimension?
- Trees should stay consistent in what leaves and trunk blocks they use. Not change depending on the size of tree one chooses. (Willows currently go from spruce (S) to oak (M) to spruce (L) trunks.
- Offsets should be consistent between all schematics. Oak has a different offset from cottonwood and from poplar for instance. The 'ground' should be on the same height in all schems tho. Ideally, they should all just start from the ground (I don't think we do roots anymore do we?)

=> In the future we should consider completly standardizing and automating the schematic creation process with scripts? This should also avoid the annoyances with having to set the offset for each schem separately.

=> I figured out how to place schematics just with a region selection and scripts, but the issues of schematic dimensions and offset make it impossible for some trees.

 

[Thamus_Knoward]

Alright I managed to make a script that standardizes the process of schematic generation. There is a tutorial in game at /warp schemgenerationguide.

Here is the script itself:

$${LOG(Before you start using this script)}$$
$${LOG(use //sel cuboid to select)}$$
$${LOG(the bottom, western-most edge of the frame that marks)}$$
$${LOG(the soil of the row that you wish to turn into schematics.)}$$
$${LOG(Skip the southern and northern-most blocks of this edge.)}$$
$${LOG(For a visual guide, /warp schemgeneratorguide)}$$
$${LOG(WARNING: This script will simply overwrite files. This cannot be undone!)}$$

$${#verticalrepeats = $$[VerticalRepeats]}$$
$${#horizontalrepeats = $$[HorizontalRepeats]}$$
$${#counter = 1}$$
$${#movehorizontalstep = 1 + $$[XDimension]}$$
$${#movevertical = 1 + $$[YDimension]}$$
$${#expandhorizontal = $$[XDimension] - 1}$$
$${#expandvertical = $$[YDimension] - 1}$$
$${#movehorizontalreset = %#movehorizontalstep% * %#horizontalrepeats%}$$
//shift 1 east
//shift 1 up
$${ECHO(//shift %#expandhorizontal% east)}$$
$${ECHO(//shift %#expandvertical% up)}$$
$${ECHO(//expand %#expandhorizontal% west)}$$
$${ECHO(//expand %#expandvertical% down)}$$
//toggleplace
$${DO(%#verticalrepeats%)}$$
$${DO(%#horizontalrepeats%)}$$
$${WAIT(1)}$$
//copy
$${WAIT(1)}$$
$${LOG(Saving $$[FileNameRoot]%#counter%)}$$
$${ECHO(//schematic save $$[FileNameRoot]%#counter%)}$$
$${WAIT(1)}$$
$${ECHO(//shift %#movehorizontalstep% east)}$$
$${INC(#counter)}$$
$${LOOP}$$
$${WAIT(1)}$$
$${ECHO(//shift %#movevertical% up)}$$
$${WAIT(1)}$$
$${ECHO(//shift %#movehorizontalreset% west)}$$
$${WAIT(1)}$$
$${LOOP}$$
//toggleplace

I'll upload it to our repo too when I get the chance. It works fairly well (I redid all the Poplar schematics with it but haven't updated the schembrush). For forest generation I figured that it is possible to replace existing blocks with the schematics using:
//replace 95:1 #fullcopy[PoplarM1][true][false]

But to get a really nice forest script we need to fix 2 issues:
1. The schematics are still placed relative to where they are copied from (they are copied from pos1 (thanks @Kor_Bro ), but still thats not centered on the block). Temporarily offsetting the blocks before replacement might be a solution. The amount of offset can be scripted as a variable that could be defined for each set and it is usually the same for x and z axes of schmematics of the same tree (since the selection box and pos1 position stays the same with the script I wrote). I honestly think #offset could do the trick but I couldn't get that to work either. What version of FAWE are we using? Maybe I've been looking at newer documentation!?
2. We need to be able to define a distance spread for the blocks we are replacing with the schems. I can't for the life of me figure out how #surfacespread works, but I'm sure that would do the trick.

 

[CashBanks]

I knew there had to be a way to auto generate forests with scripts, amazing work Tham!

I imagine a perlin formula might be able to make an appropriately spread out noise pattern for the placeholder surface blocks

 

[Thamus_Knoward]

Perlin and Simplex could both work indeed, but it's a somewhat hacky workaround, which would add up to more lines of code I think. Ideally I'd like to set a single parameter that I have more control over like some sort of a distance or buffer measure. Something like this in pseudocode:
> existing selection
> replace air&above[wool] #spread[Y][placeholder]

Where Y is the minimum distance that two placeholder blocks can have to each other, such that I can make that small for dense thickets and large for huge solitary oak trees.


On the matter of the schem generator script: I'm going to add the creation of schemset to the script during my holidays. So, that it becomes super quick and easy to make these, which hopefully allows us to make better trees faster.

 

[Emoticone11]

@carci actually made a forest generation script already, but I’ve had little luck getting him to upload his secret cache

I think ultimately it would still be ideal to code this functionality into the schembrush mod, rather than relying on hacky scripts. We’d want a way to scatter schematics across a selection given seed/growth parameters, and perhaps a way to specify multiple schemsets to draw from randomly with corresponding weights. A scatter brush would also be nice (the logic would be the same, just in brush form rather than applying to a selection).

 

[Thamus_Knoward]

That’s the ideal scenario, but despite a very elaborate description in an issue I’ve opened in the schem brush repo and raising it with Mike a couple of times, this hasn’t materialized in the last 2 years (https://github.com/mikeprimm/SchematicBrush/issues/10).

FAWE gives us all the tools we need and scripting is a way to prototype the desired behavior quickly, so if we focus our efforts on this we could have something next week rather than in another 2 years maybe

 

[Thamus_Knoward]

That’s the ideal scenario, but despite a very elaborate description in an issue I’ve opened in the schem brush repo and raising it with Mike a couple of times, this hasn’t materialized in the last 2 years (https://github.com/mikeprimm/SchematicBrush/issues/10).

FAWE gives us all the tools we need and scripting is a way to prototype the desired behavior quickly, so if we focus our efforts on this we could have something next week rather than in another 2 years maybe

Besides, if you script it you can change ground block specifically at the tree placement in one go.

 

[Emoticone11]

FAWE gives us all the tools we need and scripting is a way to prototype the desired behavior quickly, so if we focus our efforts on this we could have something next week rather than in another 2 years maybe

Maybe, but it’s also generally slower, less flexible, and a bit more fallible/error-prone I’ve found. I think it might be good for prototyping, but we definitely shouldn’t rely on it for rolling out large-scale terra updates when we can push for a more optimal solution (maybe even help elaborate the pseudocode a bit more to make Mike’s job easier?) The scatter logic in particular should be the same as Voxel, it might be helpful to see if we can dig up that code. If I have time over break I’ll peek at the schembrush code and see what I can do.