[+][SUG][ED] Saving Terrain Groups and Using Groups in Styles

[Dullstar]

From the components present in a NL style, it is often possible to build up much more complex pieces using combinations of blocks and erasers, such as the numerous vertical/horizontal to diagonal bar transitions in this level:
_{(yes, I keep re-using the same level images I have lying around if they happen to demonstrate my point)}

Now that we have terrain grouping, I can see that it has useful properties when working on these sorts of combinations: not only do they become easier to select, any erasers that are included to make up the piece are absorbed completely into the group and essentially become a private member of sorts: it exists to the pieces inside the group, but the surrounding pieces only see the net result of the combination of pieces and don't have to worry about implementation details like what erasers were necessary to make the block possible. In that sense, the terrain block thus functions exactly as a piece provided by the style. You can even use it as an eraser or as part of another terrain group - that's right, nesting terrain groups works exactly how you would expect, and they ungroup cleanly one nesting level at a time.

So, what's the suggestion?
These are two closely related but also mostly independent suggestions, though if both are implemented the implementation of 1) may have implications for the best way to implement 2).

1) Allow user to save commonly used terrain groups. They could then be lumped in with a style's terrain or as an additional groups tab to go with objects and terrain... well, most of the time. But sometimes styles get mixed, and then how should that be handled? Should the piece be shown in the groups tab for each contributing style?

2) Allow style developers to provide pre-built terrain groups. To simplify dependencies, it might be best to require all pieces come from the style the group is defined in. These could then be displayed either as regular terrain, or in a separate groups tab as described in 1). Many styles already feature distinct terrain pieces that are essentially just concatenations of smaller components (e.g. pillars and longer pillars in orig_pillar; bars and longer bars in orig_marble); while this wouldn't necessarily replace that for backwards compatibility reasons, it would be an option for new styles going forward.


Since terrain groups are simply groups of other terrain, levels wouldn't need to be aware of whether the user used a saved/pre-built group or built one from scratch like you can do currently, since it would all look the same in the level file. Therefore, in addition to convenience, it would allow more flexibility in updating styles without introducing breaking changes, as pieces provided as terrain groups can safely be modified or even completely removed from the style without breaking levels that use them as long as the underlying component pieces are left unchanged.

[namida]

Good ideas. During the initial discussions around piece grouping, it was even debated (at least between myself and Nepster; not sure if it became public) whether groups should be an attribute of the level, the style, or their own thing altogether.

Given that the "store it in the level" still allows these other options to be useable as editor features, without relying on the end-user actually having the standalone group files, there is definitely potential to do these.

Counter-argument though, especially in regards to #1 - once copy/paste between editor instances is implemented, it would be very feasible for a user to simply have a "groups templates" level that they copy / paste from, rather than having to implement a specific functionality for this. This to some extent even works with #2, but a bit less cleanly.

[WillLem]

1) Allow user to save commonly used terrain groups. They could then be lumped in with a style's terrain or as an additional groups tab to go with objects and terrain... well, most of the time. But sometimes styles get mixed, and then how should that be handled? Should the piece be shown in the groups tab for each contributing style?

Good idea, and yes - I think what you've suggested is the best way to handle mixed styles. Particularly because it's often the case that a particular style has a particular shape that's handy as an eraser, and it would be good to be able to access it from either style.

Also, it means that once you've gone through the slight rigmarole of using the eraser/No Overwrite/layer trick to create new shapes, you can potentially save it as a group and not have to do it again each time.

Just the one counter-point: there is something satisfying about knowing how to rigmarole. Maybe a 'save groups' feature would make people forget how to achieve the desired layout for future groups.

[namida]

once copy/paste between editor instances is implemented, it would be very feasible for a user to simply have a "groups templates" level that they copy / paste from, rather than having to implement a specific functionality for this.

Speaking of this, copy/pasting terrain groups between editor instances is implemented in commit 3ea828c and will be included in the next update.

[WillLem]

A very simple way that this could be done would be to have a "Groups" tab in the Piece Browser which, like "Rulers" (previously "Sketches"), would be style-independent.

The groups can then simply be saved/loaded to/from a single text file.

We can also allocate groups to styles on a per-user basis by adding a "[name_of_style]" header to the saved group. When saving a group, the user can choose whether to save it as a generic group, or add it to a particular style (or styles). If the group is steel, it would be added to the "Steel" tab rather than the "Terrain" tab for the selected style(s).

When used in a level, the group would be saved to the level file as normal, preserving cross-user compatibility.

As for (2), my honest thoughts are that if a style creator recognises that a particular piece grouping is useful and should be available to all users, they should simply go ahead and add that piece as a regular terrain/steel piece, rather than the Editor having to messily support in-style groups for basically the same end result. It seems more natural that custom groupings be supported on a per-user (rather than per-style-creator) basis.