No support for keys/values without quotes

[JugadorXEI]

Certain Valve-made keyvalues files do not place quotes around names or values, like with TF2's population files (such as this one, for example) or gameinfo.txt files in various Source Engine games. This is currently unsupported by the library, as it will ignore them completely (and as a result it will not parse these files correctly).

Support for these would be greatly appreciated.

[Matthias Möller]

Added a new branch which should add the unquoted attribute support. Still have to go through the code again.

This will not fix the whole issue. One of your file has multiple root objects in one file, which is currently also not supported. Have already written something which adds it, but I need to write some more tests and it will change a bit the API.

[JugadorXEI]

I have tested the i#5_unquoted_support branch, works perfectly aside that the root key needs to be quoted for it to parse correctly (it should also have unquoted support, if possible). I will test the multi_root_objects branch as soon as possible and report back with results.

[Matthias Möller]

Thanks for testing.
Yes, just the multi_root_objects branch support currently unqouted root object names.

I am also unsure about the interface. For the multi_root_objects. A std::vector gets returned containing all the root vdf::objects.

The alternative which comes into my mind would be, returning a vdf::object which is either the one root or, in case multiple roots are in one file, is unnamed and has all the roots as childs.

[JugadorXEI]

The latter approach makes more sense considering how some VDF files are formatted. For example, a .vmf (valve map format) file is formatted like this, with multiple children in the file itself:

versioninfo
{
	"editorversion" "400"
	"editorbuild" "7538"
	"mapversion" "1"
	"formatversion" "100"
	"prefab" "0"
}
entity
{
	"id" "21"
	"classname" "info_player_start"
	"angles" "0 0 0"
	"origin" "0 0 64"
	editor
	{
		"color" "220 30 220"
		"visgroupshown" "1"
		"visgroupautoshown" "1"
		"logicalpos" "[0 3500]"
	}
}
// so forth and so on...

Meanwhile, the .pop file I shared before also has #base file.pop key value pairs. It's likely the file itself is considered the "root" in these cases, and can have any number of key value pairs and children, similar to how most VDF files have one already-defined "root" defined as a child itself.

[Matthias Möller]

I am just unsure about how to give it back and what will be probably the least confusing behaviour.

• every root object into a std::vector
• every root object into a object without childs.
• as the second, but when there is only one root object in the file, the result will be only the root object, not an object with 1 child which is the root object.

I tend to use the third, but I kinda fear that this behavior is too confusing.

[JugadorXEI]

Why not introduce a new struct (like multiroot_object) that can hold multiple roots? That way, programmers know what to expect, and no breaking changes would happen to already-existing code using the library. As long as it behaves similar to a multikey_object (it would need to as a necessity to cover multiple #base file key value pairs, and same-name roots like it happens to .vmf files), it would be perfect.

[Matthias Möller]

Sorry, took a bit. Christmas and New Year was in between.
I think the current master branch should solve all your problems.

If there are multiple roots, an unnamed object is returned with all the root objects as childs.
The rest doesn't change at all, no api change.
If there are multiple roots in a included file, they just get added as childs to the current object (unnamed object if toplevel include).

[JugadorXEI]

I'll test it as soon as possible, thank you for your hard work.