Cubeset generator

[xoft]

I'm currently working on a generic structure generator, where the admin would specify .cubeset files that the generator would use, and it would construct structures out of those files. If I do it right, it would be possible to have various custom structures with very little effort, and no custom code needed. We could then move the various testing and weird generators, such as POCPieces and TestRails, into those, out of the main code. Also the other generators, such as RainbowRoad and UnderwaterBase, could be removed in favor of the new system.

The only problem with this is that all the structures will have to be generated together in a single step, whereas currently one could set one of the structures to generate before the caves, the other one after the caves, etc. But I don't think that it's a big issue.

This is what I want the configuration to look like in world.ini:

Code:

[Generator]
Finishers=PieceStructures
PieceStructures=UnderwaterBase, RainbowRoad, BigCity

The generator would read the files from the Prefabs/Structures/*.cubeset files, where * is the name of the structure given in the INI file.

[worktycho]

If we could just get the pass to run twice with different settings that would resolve the issue with caves. Might need to change how config works for that.

[xoft]

The caves were just an example, it could get more complicated than that.

On the other hand, in the current defaults all the structures are in a single block. I'd just ignore that for this moment.

[NiLSPACE]

It would make sense to do things that way. Did you also plan to make the villages use that? Without "Villages" in the Finishers list, but have it in PieceStructures instead?

[xoft]

The villages are rather specific with their "road" pieces, I don't think I'll be converting them any time soon.

[NiLSPACE]

Isn't it possible to create a new VerticalStrategy that changes all individual columns to the proper height instead of the whole prefab?

[xoft]

It's not exactly a VerticalStrategy, it's more of a special imprinting, and it would really mess with things - imagine having to connect to connectors in such a case. And the imprinting such a thing could no longer use the cBlockArea:Merge() method, but instead would need a new one. Too much trouble for too little effect. It wouldn't be useful for anything else than village roads, for which I'm perfectly happy to make a special generator that imprints the road pieces.

Perhaps try writing a plugin that would take a .schematic file and imprints it in such a way (it should be possible, albeit slow, with the current API), I think you'll see that it distorts the areas too badly to ever be useful for anything else than roads.

[xoft]

As for my original problem with the finisher precedence, I came up with a simple solution: the PieceStructures generator takes a direct argument about what structures it should generate, and can be specified multiple times:

Code:

Finishers=Trees, PieceStructures: UnderwaterBase | TreePaths, RoughRavines, PieceStructures: TestRails

(this generates Trees first, then UnderwaterBase, then TreePaths, then RoughRavines and finally TestRails)