Using name, not Name, in configs

[Starstrider42]

Could the Kethane configs please be made to use name (lowercase) rather than Name (uppercase)? Writing all but the simplest ModuleManager configs for the current system is a nightmare, because Name doesn't work with bracket notation.

[Majiir]

Why doesn't it work? I'm inclined to say that if ModuleManager is privileging some keynames over others, that's an issue to take up with Sarbian. In any case, I'd like more information on this.

[Starstrider42]

Because name is conventionally a unique identifier, at least within its tree -- and that's a KSP convention used by the ConfigNode class, not an MM convention. Therefore the KSP ConfigNode syntax

NODE {
    name = Foo
}

is supported by the ModuleManager syntax

NODE[Foo]

This is a fundamental part of MM's language extension, and I'm certainly not going to make a fool of myself by reporting it to @sarbian as a bug.

So why does Name cause trouble? Because, unlike name, it's not guaranteed to be unique. So for example

%NODE[Foo]

means "edit the node named Foo if it exists, otherwise create it". On the other hand, searching for the non-unique field Name requires

%NODE[*]:HAS[#Name[Foo]]

which has ill-defined semantics. Just how many nodes are there with Name = Foo? If there aren't any and you want to create one, just what should it be named? You never gave a name, which is what ConfigNodes expect.

All I'm saying is that there's a well-established convention for how ConfigNodes are identified. It predates ModuleManager, but that's where violating the convention causes the most trouble.

[Majiir]

Because name is conventionally a unique identifier, at least within its tree -- and that's a KSP convention used by the ConfigNode class, not an MM convention.

Do you have evidence of this? name is conventionally used in a lot of KSP nodes, but so are uppercased node names (e.g. PART). I don't know of any part of the ConfigNode class that actually privileges the name key.

This is a fundamental part of MM's language extension

That may be, but the MM syntax should be able to cope with other keys. For example, how would you work with the (stock) EXPERIMENT_DEFINITION nodes? Those have an id and title but no name.

Changing the Kethane node structure means manually changing the string in each place it's used and writing an update script to migrate old nodes. If I miss one string, I get fifty thousand angry users yelling about how I corrupted their saves. So, while I can do this, I'm reluctant to unless it's clear that this is a design flaw in Kethane and not another one of Ialdabaoth's "standards" shoved down our throats.

[sarbian]

Majiir is right, the problem lies within MM code and not his files. For node with a name some of MM code is case sensitive. I'll see if I can make a clean code change, but to be sure please open a ticket in my github.

As for the " MM syntax should be able to cope with other keys". It can, the syntax is just a bit more arcane than the default one, but that did not stop anyone from editing the experiment or the other non classis nodes.

[Starstrider42]

Sorry for the delayed reply, RL meant I had to avoid KSP for a while.

For the evidence that it's a KSP thing, I refer you to the ConfigNode documentation: https://github.com/Anatid/XML-Documentation-for-the-KSP-API/blob/master/src/ConfigNode.cs. Note the name field, and the name parameter in both one of the constructors and the AddNode() factory method.

@sarbian, I'll open an issue right away. Agree that custom keys are probably an easier solution.

[Majiir]

The name field in ConfigNode has nothing to do with keys. The name of a ConfigNode is the part that comes before the brackets. Consider this node:

Foo {
    name = Bar
}

In this example, the node's name is Foo, not Bar. There is no privileging of any key.

[Starstrider42]

Aha. I stand corrected.