Tagging - another idea for grouping objects

[Tels]

Everything after // is a comment, and despite what I suggested months ago, I have to agree with OrbWeaver that we shouldn't mess with comments unless there is absolutely no other way to go.

 

The "// primitive 47" seems to be used by Doom to tell you wish brush makes problems when it generates warnings (during dmap), as normal brushes don't have any ID attribute.

[Gildoran]

I wanted to add another idea that I hadn't seen. This would likely turn out way too complicated and difficult and error-prone, but perhaps it's worth mentioning...

 

What about importing/exporting map files, and comparing maps before/after being edited by D3ed?

 

For example, you create a big complicated map with all sorts of grouping and layer info and save it in DRmap format. When you compile the map, DR exports it and saves a backup D3ed map file. You could then go around moving ragdolls, setting up lights, etc, and save the D3ed map file. Going back to DR, you select "commit changes" and DR pops up a list of changes you made. You can check/uncheck specific changes and commit them to your DR map.

 

This would work by DR parsing and comparing both D3ed maps. It would understand only certain limited types of changes (such as adding/removing an entity, changing spawn args or repositioning a ragdoll). Certain kinds of changes couldn't be committed without losing grouping information. For example, adding/removing worldspawn primitives would lose all worldspawn grouping info because DR wouldn't know exactly which primitives were added/removed, only that worldspawn's primitives changed.

 

This is far from an ideal solution, but it might act as a stopgap measure until a renderer and ragdoll editor are created for DR...

[sparhawk]

IMO the only thing that to be checked are wether a group still consists of existing entities. I wouldn't make it to complicated. If comments are not acceptable (which is understandable), we can also extend the map parser (which will break compatibillity of course). Writing such metainfo into a seperate file is also acceptable IMO. If objects no longer exists, because they were removed with a different editor, than it's bad luck. Most of the time, mappers will be aware of this though, so I don't really see a big problem with a secondary file, apart from the ugliness.