Inlined SBB definitions

[Argmaster]

Description

As requested in #1382 (comment)
Allow inlined SBB declarations, so it is not necessary to create SBB zon file when SBB has no children.

Syntax could be:

.{
	.blueprint = "cubyz:tree/oak/1/branch_3",
	.children = .{
		.crimson = .{
			.{.structure = "cubyz:tree/oak/1/leaf_1"},
			.{.structure = "cubyz:tree/oak/1/leaf_2"},
			.{.structure = "cubyz:tree/oak/1/leaf_3"},
		},
	},
}

Where cubyz:tree/oak/1/leaf_1 must map to existing blueprint asset.

Instead of:

.{
	.blueprint = "cubyz:tree/oak/1/branch_3",
	.children = .{
		.crimson = .{
			.{.structure = "cubyz:tree/oak/1/leaf_1"},
			.{.structure = "cubyz:tree/oak/1/leaf_2"},
			.{.structure = "cubyz:tree/oak/1/leaf_3"},
		},
	},
}

And assets/cubyz/sbb/tree/oak/1/leaf_1.zig.zon with:

.{
	.blueprint = "cubyz:tree/oak/1/leaf_1",
}

[IntegratedQuantum]

Why not connect the ids, so we wouldn't need the .blueprint field?

[ikabod-kee]

I have a suggestion, that may or may not be related to this:

.{
.blueprint = identical,
.children = .{},
},
}

For specifying files in sbb that have the same relative path in blueprints

[Argmaster]

Why not connect the ids, so we wouldn't need the .blueprint field?

Because dynamic interpretation of IDs and data structures creates a lot of pain when there is an error, creates generic and unhelpful error messages and painful edge cases when the interpretation is ambiguous and you have to check for those. Best contract is the strict one, there is no cost on asset creator side to explicitly state their intent, and ofc in implementation there will be no blueprint field, it will simply imply different data structure, mutually exclusive with normal SBB.

[Argmaster]

I have a suggestion, that may or may not be related to this:

.{ .blueprint = identical, .children = .{}, }, }

For specifying files in sbb that have the same relative path in blueprints

This is orthogonal to this issue, it is basically a workaround for not wanting to write down unambiguous and hence long IDs. I think it is better to avoid having SBB file for those with no children instead of removing even more of the contents of that file. By the way .children can and should be omitted when empty. It should be an error if you do that and there are children TBD

[Argmaster]

I can create Visual Studio Code extension that provides autocompletion for Cubyz IDs as a better workaround.

[IntegratedQuantum]

Because dynamic interpretation of IDs and data structures creates a lot of pain when there is an error, creates generic and unhelpful error messages and painful edge cases when the interpretation is ambiguous and you have to check for those. Best contract is the strict one, there is no cost on asset creator side to explicitly state their intent, and ofc in implementation there will be no blueprint field, it will simply imply different data structure, mutually exclusive with normal SBB.

Well we have this for textures, e.g. there is one name.png, one optional name_fog.zig.zon, one optional name_emission.png and so on. I don't see any ambiguities there, and if we put the .blp and the .zig.zon in the same folder it's also hard to make mistakes.

[Argmaster]

Blueprints are independent from SBBs and can have different use cases than just SBBs (eg. segment based maze generation or generator with no intersection between structures guarantee)

Anyway, should they share ID space or only directory structure?

[IntegratedQuantum]

Blueprints are independent from SBBs and can have different use cases than just SBBs (eg. segment based maze generation or generator with no intersection between structures guarantee)

Well, in those cases these probably either also want substructures (e.g. to randomize rooms in a maze), or they don't have any substructures, in which case the .zon file would be empty anyways, right?

[Argmaster]

What if you have a different SBB that uses the same blueprint as some other one? For example cubyz:birch/stem/0 uses cubyz:oak/stem/0 just with substitution map. Now since blueprints are Independent from SBBs you just link both to the same blueprint and if you change the SBB storage structure you can leave the blueprint the way it is. If you store blueprint alongside SBBs you can choose to desync them or propagate changes to all related SBBs. Also no shortcut syntax for those, as they can't be next to each other for folder names to be meaningful. Your proposal assumes that not very blueprint needs SBB, but makes it awkward in an inversed case, where not every SBB needs a blueprint.

[Argmaster]

Why not connect the ids, so we wouldn't need the .blueprint field?

How would that work? If you have SBB and Blueprint of the same ID, you need implicit precedence of SBB over blueprint and you are denying user the option to explicitly specify which one they want. This makes it also less readable, because you don't know if the ID is resolved to a bluepirnt or to SBB. And it also makes it more awkward during dispatch because you have to check two hash maps.

This is also different from the texture case, as those different textures have different destinations, they don't override each other. Here Blueprint and SBB would have the same designation, only one of them can be used to generate structure.