system_info('WorldGenSettings') return a nbt value object of WorldGenSettings from level.dat.

We could add these all to system_info, but add them separately, cos we have the border size already, as well as the seed, and like the dragon fight is useful but tbh could be put separately.

but.... border size&dragon fight are not in that tag......
and...i just looks at the code. there is a method already to store them as a NBT tag in that file.
i think i could use it directly.
needlessly to remove 'seed' from that tag.
just leave it here

Take account that it's unlikely that the game stores them as an NBT tag when running, so having returning them together as an nbt value is likely more work than just giving individual values.

Plus please no nbt if not needed!

        put("world_gen_settings", c-> {
            GeneratorOptions generatorOptions=c.s.getWorld().getServer().getSaveProperties().getGeneratorOptions();
            Optional<NbtElement> x = GeneratorOptions.CODEC.encodeStart(NbtOps.INSTANCE, generatorOptions).result();
            if(x.isPresent()){
                return new NBTSerializableValue(x.get());
            }else{
                return NullValue.NULL;
            }
        });

i added that to system_info code.
seems works.
here are 2 samples.(/script run write_file('aqq','shared_nbt',system_info('world_gen_settings')))
aqq.zip

i think that that result will satisfiy any users needs.
should i make a pr?

I fully understand that (as many have reminded me) generating nbt is expensive.
But it is really hard for me to imagine any other way to represent this data. After all, the data itself is a complex structure.

Not only that, the parameters of various types of dimensional types, biome types, and terrain generation types vary tremendously. They are also able to be combined with each other freely. When dealing with such a complex data, to implement it by yourself without errors is difficult.

As altrisi said, data provide by scarpet should be better not simply put "returns the value of the tag X in the level file" in the docs.
But I can't think of a good way to carefully break this data down into a series of smaller ones.

should i provide some limited information first? for example, return the layers of a super flat world (of each dim) if it is a superflat world in that dim.

and after that tell the user to try using this finally if the information provided before are not enough.

Yes, that makes sense. Split it up, also cos people may not want all the info, and may not know all the info in that (like me for example), so it's best to split as much as possible so you can add specific infos

ok, now it support querying that.


it support user-defined dim as well

code

Well if you're gonna develop as you explain, yuo might as well open a PR