Brush paremeters via command arguments

[mickare]

Since /vs set <parameter> = <value> is way to complex, it would be nice to be able to set them directly in each /b ... command like it is common in the command-line.

Syntax: /b <shape> <mask> <effect> [-parameter=value] ...

The parameter starts with a - and will be set with =. This should be very good parsable with a Regex Expression, e.g.: \s-([a-zA-Z]+)=([a-zA-Z0-9\+-\.]+) -> https://regex101.com/r/lN3xD1/1

Example:

• /b d m -face=true -height=5

[Deamon5550]

either your syntax of -key=value -key2=value2 or {key=value key2=value2} was what I had in mind

so your brushes would look something like:

/b disc -face=true materialmask biome -biome=jungle material

/b disc {face=true} materialmask biome {biome=jungle} material

[mickare]

Syntax

Side question that could affect this matter:
Can there be multiple masks of the same type but each with varying parameters?

• If true then your example is the way to go.
• If not then I think the best way is to just putting them at the end.
  This way you can clearly see what main modifications the command is doing.
• /b disc materialmask biome material -face=false
• /b disc materialmask biome material -face=true -biome=jungle
• /b disc materialmask biome material -biome=jungle -face=false

Yep, you loose the semantic to which the parameter is belonging but this is the price to pay for clarity.

Behavior

Should command arguments change the sniper's attributes (I think in code it is called aliases?), or should it just be a modification of parameters for the very command?

[Deamon5550]

A brush can have multiple shapes, effects, and masks so the arguments really need to follow the brush part they are applying to directly, since you could have two of the same brush part that you want to configure differently, or two brush parts that use the same key.

[mickare]

This is a prime example for what I like to call the "trap of generics & complexity".

I experienced it a lot in my coding... but often the easier way is the best way for the end-user in terms of usability & complexity and for the developer(s) in terms of coding and maintainability.

On the side:

First of all I don't see many artists using multiple shapes. And even then similar effects can be created by using another brush a second time at that spot. Artists develop and share their own techniques to terraform, shape and create landscapes, etc.

So I don't think that merging those work-flows into a single brush would be a greater improvement than it complicate things.

If you still want to rock the multi way then keep in mind that the minecraft command in chat is limited to a certain length.
I propose that the whole multi brush command is spread out and may be integrated into the alias command.

Because of the limited command space, it would need a new command structure to create, modify and delete custom brush commands. Much like the alias command but with a command structure like PermissionsEx is using.

Divide the brush commands into:

• Singleton brush command /b ... with one shape, simple masks & material (like old time)

• Generic brush command /g <name> <subcmd> (I choose "g" here just for the example not relevant)

  • /g mybrush new
  • /g mybrush delete
  • /g mybrush mask push <mask> (args) - push on top of mask stack (stack is ordered)
  • /g mybrush mask remove <mask> - remove all masks of type from stack
  • /g mybrush mask set <mask> (args) - set args if existing, else push
  • /g mybrush effect ... - same as mask
  • /g mybrush shape ... - same as mask
  • /g mybrush -arg=5 - use the brush with custom parameters.

  For better customization there should then be the ability to define custom variables in the mask/effect/shape arguments. Those arguments are then required and filled via the custom parameters.

So you see to really go the usability of the generic brushs to the end there needs a lot more effort in the command structure.

Keep it simple and think of usability first. ^^