Some Schems are Broken

[Margaery_Tyrell]

Hey I've noticed a few of the schems are broken, for example the MixedForests schemset has several trees that when spawned do not reach or touch the ground and produce trees that float 6-10 blocks off the ground

So if anyone is messing with the schemsets can you please make sure to playtest them before changing them.

 

[Thamus_Knoward]

I am redefining some schematics, however, I am not messing with defined schemsets!
But perhaps it is the time now to discuss how to make them consistently so they work both with the schembrush and scripts.

I don't have time right now to write an extensive post, but as a quick fix you could try using this option at the end of the schembrush command:
From https://github.com/mikeprimm/SchematicBrush/wiki/Commands

-placelacement - selects placement strategy for schematic: default is CENTER (block clicked by brush is center of schematic - same as //brush clipboard). Others supported are BOTTOM (bottom of schematic is placed just above the block clicked by the brush), and DROP (lowest layer of schematic containing non-air blocks is placed just above the block clicked by the brush).

Do you think you can work out which trees are not working in that set?
I've re-defined:
BirchS, BirchM, CottonwoodS, EmilyPine, WolfswoodM, ForestOak, SentinelS, LJungleM, WillowM and PoplarM. Possibly some others too, I can only check my master list later.

 

[AerioOndos]

Also your SentinelY schem is not working. The top block is spawning either on the point selected by the brush, meaning most of it is underground

 

[Thamus_Knoward]

You need to understand that there is a difference between a schematic and a schemset defined through the schematic brush!

For all my newly made schematics, I did NOT define a schemset. Instead they are made to be used either individually or through a script.
Schematics I made include e.g. SentinelY, ThamCWD, ThamBranchSpr, ThamBranchJun, ThamBranchOak, ThamBranchBirch, ForestBeech, ForestBeechLM.

You can load these by doing /schem load schem name, and then //paste them relative to your position, or you can use //br copypaste or you can place them using the #fullcopy[schem][rotation][mirror] pattern of WE.

So, don't use my schems with the schematic brush unless you define a set first and configure the offsets accordingly.

 

[Margaery_Tyrell]

ForestOak is the one Ive noticed having issues with

 

[Thamus_Knoward]

Okay I'll take a look!

BTW, it might be that the schematic brush is redundant now that FAWE has an equal if not more powerful brush.

Would be cool if someone with root-access to the server could organise all the schems into respective folders then we could do exactly what's being done in this video without needing to set offsets etc:

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

www.youtube.com

This is the best command in that video. (Do not mess with saving schematics unless you know what you're doing):

//br scatter #fullcopy[trees][true][true] <radius> <points> <dist-btw-pts>

 

[Thamus_Knoward]

This might work with wildcards too so maybe re-arranging the schematic folder is not a necessity. Will try this tonight!

 

[Thamus_Knoward]

Wildcards don't work just in case anyone was wondering.

 

[Arkilstorm]

I don't know anything about schems / schemsets beyond choosing the schem or set and placing, but we've been trying to do the HG forests this weekend and a couple of the trees in MixedForests are floating, so we have to /undo every 2-3 clicks. Pleeeeeease fix this! I'm begging you! It's killing me.

 

[Thamus_Knoward]

In case people are experiencing issue with the schematic brush at the moment. There are two possible reasons:

1. For the forest scripts I defined a way to standardize schematic generation through a script (posted on the forum here). This causes clashes in mixed sets where schems defined with the script are brought together with schems that aren't defined with the script. My suggestion is to define all schems with the script for consistency.

Schems that I redefined are:

List of Schems I use in the scripts:

PoplarM
SpacerT1
ForestOak
ForestBirch
AlderS
AlderM
LJungleS
ThamFallenJungle
ThamFallenSpruce
BirchM
OakM
AshS
LJungleM
WillowSCopp
SpacerS
ForestBeech
ForestBeechML
SpacerW
BirchS
MapleS
CottonwoodS
WillowM
ThamBranchSpr
ThamBranchJun
ThamCWD
SentinelS
SentinelSL
SentinelY
EmilyPine
WolfswoodM

2. There seems to be a bug in the SchemBrush itself:

The -place: PLACEMENT option gets the offset wrong by one block for CENTER and BOTTOM and DROP is completely off.

Try it yourself with the schemset &TestCube and &TestCube2.
Here a pic of the test @Iwan and I have used to investigate this issue.

I see two ways about this: 1. Notify Mike and wait for him to fix the bug, 2. Consider alternatives using FAWE as outlined above.

 

[Thamus_Knoward]

For those at a loss at how to deal with this in the short term. There are two workarounds both with caveats:

1. Only the Mixed Schematic Sets containing trees that I redefined are 'broken', but the individual Schem Sets still work fine. MixedForests contains schematics from the sets of ForestOak, ForestMaple and ForestAlder, which you can check with /schset get &MixedForests. I've only redefined ForestOak for my scripts so you can just load 3 individual brushes with:
/schbr &ForestMaple
/schbr &ForestAlder
/schbr &ForestOak -place:BOTTOM

2. If you want more fine-grained control over which trees are placed, you can pick individual species from tree test and use the scatter brush in FAWE like so:
/br scatter #fullcopy[ForestMaple1],#fullcopy[ForestOak4],#fullcopy[ForestOak6],#fullcopy[ForestAlder1] 10 3 5

Essentially you can chain a bunch of #fullcopy[tree] statements then you provide the radius then how many points you want to have in that radius and then how far these points should lie apart. A problem with this seems to be that the trees are 'rooted' by default. So afterwards you'll probably have to use the adjacency pattern to remove the visibly exposed thin logs.

The #fullcopy command optionally also takes rotation and mirroring parameters, but I found them to be a bit odd since the schematics aren't centered.

Play around with the radius, amount of points, and distance between points for the scatter brush. I'm sure you could populate a decently spaced forest with a single click if you set a larger radius

 

[AerioOndos]

except the scatter brush, unlike schem brushes, replaces blocks with its own. So if your working on a slope, the trees are scattered at the same height level, some of the trunks are in the ground and so have to be fixed. Not too much of an issue with Highgarden and other gently rolling terrain.
Also some of the individual schems are broken. SentinelS appears 3 blocks above the ground or so. Its pretty easily fixable but takes an annoying amount of time to select the space and move the tree downwards.

 

[Nuggets - Shygirlstan]

except the scatter brush, unlike schem brushes, replaces blocks with its own. So if your working on a slope, the trees are scattered at the same height level, some of the trunks are in the ground and so have to be fixed. Not too much of an issue with Highgarden and other gently rolling terrain.
Also some of the individual schems are broken. SentinelS appears 3 blocks above the ground or so. Its pretty easily fixable but takes an annoying amount of time to select the space and move the tree downwards.

Some people need to build in mountainous terrain. Can this be fixed?

 

[Margaery_Tyrell]

ForestOak is also significantly shorter than the previous iterations by like 3-4 blocks so like the forests I made pre-adjustment and the ones made post-adjustment have very different heights.

I think in the future any changes to the schemsets we use extensively should be taken with the community before we change them. Either that or make a new set of schems so that the people utilizing their current iterations aren't thrown off.

For example it wasn't until now that my thoughts about PoplarM (namely that they've changed to be shorter) has been validated and I wouldn't have known until the issue was addressed.

 

[Adorkabley]

I feel like if anyone wants to make changes to schems either consult or make your own set of schems like Carci does. That way things don't get changed and throw ppl off. Just a suggestion.

 

[Thamus_Knoward]

Some people need to build in mountainous terrain. Can this be fixed?

I don't think we can modify the behavior of the scatter brush, but if you work in mountainous terrain, I see two options:

1. Use the first workaround from this post

2. Take a look at the river bank scripts I posted here, they contain the logic to place schematics on a large area simply by replacing existing blocks with entire trees. The relevant section is this:

//gmask [air]&>[wool:orange]
//generate -o [95:15] round(abs(x)%(5+random()))+round(abs(z)%(5+random()))==0|
//gmask
//replace [95:15]&~[95:15][1][8] air|
//replace #offset[3][0][3][95:15] 23|
//replace 23 10%[#fullcopy[AshS1][false][false]],10%[#fullcopy[AshS2][false][false]],10%[#fullcopy[AshS3][false][false]],10%[#fullcopy[AshS6][false][false]],10%[#fullcopy[AshS5][false][false]],10%[#fullcopy[AshS7][false][false]]|

The difficult part imo is spreading out some blocks randomly with a certain distance between them. The generate command does an OK job but if you want more control you could try the following:

/br scatter 95:15 15 7 3
/mask air&>[#surface]

Then select the whole area and run these lines replacing AshS with the trees you want:

//replace #offset[3][0][3][95:15] 23|
//replace 23 10%[#fullcopy[AshS1][false][false]],10%[#fullcopy[AshS2][false][false]],10%[#fullcopy[AshS3][false][false]],10%[#fullcopy[AshS6][false][false]],10%[#fullcopy[AshS5][false][false]],10%[#fullcopy[AshS7][false][false]]|

And afterward, replace the offset placeholder by running

//replace [23]&|[dirt,gravel,grass][3][6] dirt
//replace 23 air

I don't want to complicate things, but I need to add that the x-dimension of the schematic determines the required amount of offset. Most of the S sized trees require an offset of 3 blocks, while M is typically 7. There are some variations though which makes this a bit annoying. I should also add that this only works well with the schematics that I redefined (see the list above).

Also some of the individual schems are broken. SentinelS appears 3 blocks above the ground or so. Its pretty easily fixable but takes an annoying amount of time to select the space and move the tree downwards.

ForestOak is also significantly shorter than the previous iterations by like 3-4 blocks so like the forests I made pre-adjustment and the ones made post-adjustment have very different heights.

For example it wasn't until now that my thoughts about PoplarM (namely that they've changed to be shorter) has been validated and I wouldn't have known until the issue was addressed.

Neither is the case, the offset is merely wrong since the schematics are now defined with the bottom at the bottom of the trees as opposed to the center of the tree as it was before. If you're using the schem set &ForestOak use the placement option -place:BOTTOM to get trees that are mostly the same height as they used to be. I say mostly because in addition to the schems being redefined they are placed shifted down into the ground by one block which is due to a bug in the SchemBrush plugin outlined here.

I think in the future any changes to the schemsets we use extensively should be taken with the community before we change them. Either that or make a new set of schems so that the people utilizing their current iterations aren't thrown off.

In my defense, and reiterating again, I didn't actively change the sets. When I started I intended to fix some of the gross inconsistencies with our schematics. My understanding of Mike's plugin was that the sets were independent of the individual schematics. It is only through your feedback that I learned that changing the schematics regretably did also affect the defined sets.

I'm happy to completely reorganize and standardize tree test, along with redefining all the schematic sets. However, we're still left with having to handle the bug in the Schematic Brush plugin itself.

And maybe one more specific comment to @Margaery_Tyrell, I've offered you my help dealing with all these issues and the large forests you're planning on numerous occasions. So just to reiterate, that offer still stands!

 

[Iwan]

Just want to explain what causes the weird offsets (floating trees, or ones dug into the ground) again.

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?)

The problem - as far as I understand it - is, that we were anything but consistent in the way we set up schematics.

Think of a schematic like you making a WE selection, copying that selection into your clipboard and then pasting it elsewhere, only that the content you saved into your clipboard is stored as a schematic file on the server, and you can call that file later and get the selection into your clipboard to paste somewhere. That's what the schematic brush does when you select a Set of schematics (the SchemSet): it randomly selects a schematic file out of a predefined list of schematics, waits till you pasted it, then selects another one, etc.

Any Editor can set up a schematic, and make a set of several schematics. We have never established detailed guidelines for setting up these thing, which not only lead to all sorts of strange names for the sets, but also inconsistently set up schematic files. This means that some people selected the object they wanted to store as a schematic and tried to limit excessive, empty area so there is no empty blocks below or above the object, e.g. a tree. And others didn't pay attention to that, and there are excessive air blocks above or below the object. This can be fixed by declaring an offset when making the set, so that every schematic in the set is placed a couple of blocks lower, for instance.

The issues arise when we mix differently set up schematics inside the same set: imagine a number of oak trees that all have 2 blocks of air underneath, and a number of elm trees that don't. If you were to make a set out of these, you cannot fix the offset of the one species without altering the behaviour of the other.

Tham has re-defined a number of schematics to work with his forest scripts. The way he set them up, they do not have any excessive air blocks below or above. Some of these re-definitions changed the behaviour of species used in mixed sets, which now reference schematics that are both fixed, and schematics that are not fixed, because the set was declared with certain offsets.
This can - in theory- be fixed by adding -place:<PLACEMENT>, where PLACEMENT is either CENTER, BOTTOM or DROP. In most circumstances you would add -place: DROP, which supposedly places the lowest nonempty block of the schematic on top of the block you clicked. Unfortunatelly, the brush does not seem to actually do that, which might be a bug in the schematic brush.

The solution to this is to set up all schematics in a structured, organised and uniform way, and to do so in the future, and then to redefine the schematic sets.

 

[Arkilstorm]

The emoticons in these posts are hilarious.

Thanks for the update guys.

For the sentinelS I've been using: /schemset &SentinelS -yoff:-3 (that should fix it)
For the MixedForests for the time being i'm using the individual sets Tham shared above and they seem to work fine. It's less randomly placing trees, but they look alright!

Cheers for the workaround guys.