Jump to content
The Dark Mod Forums

Tagging - another idea for grouping objects


Recommended Posts

As far as I know there's some limitation in .map file structure that makes grouping objects impossible. Recently I thought about alternative method - tagging entities instead of grouping them. Tags would be assigned just like any other spawn_args. Actually - the functionality is already there - you just write any word and it's added to the list. I'd say tag would be anything which is not a recognised as spawn_arg.

 

The only functionality which has to be done is "Select by Tag/Spawnarg". It shouldn't be difficult to do, should it? And there's really plenty of possibilities to make selecting a group of objects easy and flexible. I mean diffrent modes of selecting etc., but these are details at this moment.

 

Of course any object could have many tags, so you can have f.e. galleon with all stuff on it tagged with "galleon". But if you want to move only lamp on the galleon, you could select lamp and light source tagged f.e. "lamp_12" and "galleon" tag would be ignored.

 

Another great functionality would be filtering by tags.

 

What do you think about it?

Link to comment
Share on other sites

As far as I know there's some limitation in .map file structure that makes grouping objects impossible. Recently I thought about alternative method - tagging entities instead of grouping them. Tags would be assigned just like any other spawn_args. Actually - the functionality is already there - you just write any word and it's added to the list. I'd say tag would be anything which is not a recognised as spawn_arg.

 

The only functionality which has to be done is "Select by Tag/Spawnarg". It shouldn't be difficult to do, should it? And there's really plenty of possibilities to make selecting a group of objects easy and flexible. I mean diffrent modes of selecting etc., but these are details at this moment.

 

Of course any object could have many tags, so you can have f.e. galleon with all stuff on it tagged with "galleon". But if you want to move only lamp on the galleon, you could select lamp and light source tagged f.e. "lamp_12" and "galleon" tag would be ignored.

 

Another great functionality would be filtering by tags.

 

What do you think about it?

 

Couldn't you just add a spawn_arg "tags" and have the property of it be the "tags"? Just like "name" contains an arbitrary string, "tags" could do, too. Or did I misunderstood you?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I don't mind if tags would be a string as a property of some spawn_arg or they would be unrecognised spawn args (without a need for a property to put in). It's just a matter of aesthetics and functionality (practice would tell it).

 

The thing is if selecting objects in DR by those tags is possible or not. For me it looks quite easy to do and gives really great possibilities of organizing stuff in the scene.

Link to comment
Share on other sites

The problem with grouping by spawnargs is that it only works for entities -- you would never be able to group a number of brushes or patches together, because they are all part of a single entity (the worldspawn).

 

However, if this limitation was accepted it probably would not be that hard to do.

Link to comment
Share on other sites

The problem with grouping by spawnargs is that it only works for entities -- you would never be able to group a number of brushes or patches together, because they are all part of a single entity (the worldspawn).

 

However, if this limitation was accepted it probably would not be that hard to do.

 

Is there any downside to make brushes some entity instead of just children of world_spawn?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Is there any downside to make brushes some entity instead of just children of world_spawn?

 

Yes, they won't participate in map compilation and will not seal the void or portal zones (they will all be func_statics, like models).

Link to comment
Share on other sites

Yes, they won't participate in map compilation and will not seal the void or portal zones (they will all be func_statics, like models).

 

Ah. Good to know. Do patches seal these areas? (I fear not :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

The problem with grouping by spawnargs is that it only works for entities -- you would never be able to group a number of brushes or patches together, because they are all part of a single entity (the worldspawn).

But tagging is not a grouping really - it doesn't change the structure of map objects. And you can assign some spawn_args (=tags) to brushes as well, so it should work. I added some "tag"" to one of my brushes, it was added to the list, not ignored, it was saved with a map, compiled with no problems, so actually the core functionality is there already - we CAN add "tags" to brushes or entities. But we cannot select by spawnargs (=by tags, as far as I know).

It would be actually useful feature not only for tagging - you could use it by selecting all entities with f.e. "noshadows" spawn_arg etc.

 

Missing any form of grouping feature is really bad. It takes ages to select complex group of entities - using brush for selecting usually ends up with selecting more than you need and than you have to spend some time on unclicking unwanted entities and so on...

 

Tagging has another advantage over regular grouping - you could select f.e. only books in whole map. And together with filtering option you could hide everything except books, so you could focus on editing them only.

Link to comment
Share on other sites

But tagging is not a grouping really - it doesn't change the structure of map objects. And you can assign some spawn_args (=tags) to brushes as well, so it should work. I added some "tag"" to one of my brushes, it was added to the list, not ignored, it was saved with a map, compiled with no problems, so actually the core functionality is there already - we CAN add "tags" to brushes or entities. But we cannot select by spawnargs (=by tags, as far as I know).

It would be actually useful feature not only for tagging - you could use it by selecting all entities with f.e. "noshadows" spawn_arg etc.

 

Missing any form of grouping feature is really bad. It takes ages to select complex group of entities - using brush for selecting usually ends up with selecting more than you need and than you have to spend some time on unclicking unwanted entities and so on...

 

Tagging has another advantage over regular grouping - you could select f.e. only books in whole map. And together with filtering option you could hide everything except books, so you could focus on editing them only.

Brushes and patches don't have spawnargs, it was the worldspawn you were assigning that tag to actually. All other world brushes carry the same spawnarg, check it out. :)

 

I can perfectly see the benefits of having a grouping feature, it's just not as easy as it sounds. At least we are already allowing for a layering feature after the next scenegraph refactor, but don't hold your breath.

Link to comment
Share on other sites

If we have multiple layer groups that is already a step in teh right direction. Assigning groups to individual objects and brushes would also be great, but one thing after the other. :)

 

As for grouping brushes. A brush has a definite structure in the map file, and you can use comments anywhere, so this should be feasable. The only thing you need to add, would be a mechanism to allow setting such groups. Spawnargs wont work for the above mentioned reasons, but that doesn't matter.

 

I don't have a mapfile here to check it, but even though brushes are attached to worldspawn, they still retian their own structure, otherwise it wouldn't even be possible to select them as individual objects inside the editor. And this would be metadata information for the editor only, as the mapcompiler and the game don't need that grouping information.

Gerhard

Link to comment
Share on other sites

I don't have a mapfile here to check it, but even though brushes are attached to worldspawn, they still retian their own structure, otherwise it wouldn't even be possible to select them as individual objects inside the editor. And this would be metadata information for the editor only, as the mapcompiler and the game don't need that grouping information.

 

Brushes are stored as individual objects, yes, but I don't know of any easy way to associate arbitrary metadata with them in the map file -- I am totally against using comments for this purpose, because it screws up the entire parsing system (i.e. the DefTokeniser class which returns a list of tokens already strips out comments; if this was changed it would mean that all of the parsing systems would have to deal with comments separately, adding considerable complexity to the code).

 

One way this could perhaps be done is to maintain brushes in a particular order in the map file, and to attach spawnargs to the worldspawn mapping brush indexes to layers, e.g.

 

"editor_drLayerMapping1" "firstlayer"

"editor_drLayerMapping2" "firstlayer"

"editor_drLayerMapping3" "secondlayer"

"editor_drLayerMapping4" "myCustomLayer"

 

which would assign each numbered brush into its correct layer when DarkRadiant loads the map file.

 

Of course the layering could get broken if DoomEdit was used to save the map since the order might not be correct any more, but perhaps DoomEdit would ignore these unrecognised spawnargs anyway and therefore not save them with the map.

Link to comment
Share on other sites

I think the mapfile is parsed within the SDK, yo might add additional keywords there. As for using DoomEdit, bad luck I would say. People should be aware that DoomEdit is not the way to go, but of course, until a proper renderer is available inside DarkRadiant, there is probalby not much choice.

 

One option would be to export/import the grouping into a seperate file, so the mapper can export it, before he uses DoomEdit. It's not very elegant, but it might be a solution for now.

Gerhard

Link to comment
Share on other sites

I think the mapfile is parsed within the SDK, yo might add additional keywords there. As for using DoomEdit, bad luck I would say. People should be aware that DoomEdit is not the way to go, but of course, until a proper renderer is available inside DarkRadiant, there is probalby not much choice.

 

If there is a possibility for inserting keywords into the map file which will not cause Doom 3 to choke, then that is fine -- we can obviously write the DarkRadiant parser any way we like, so it is just a question of what Doom 3 will accept and what will cause an error.

 

One option would be to export/import the grouping into a seperate file, so the mapper can export it, before he uses DoomEdit. It's not very elegant, but it might be a solution for now.

 

Yes, the separate file solution may well become necessary at some point. I don't really like using multiple files, but it may be the only way to get around limitations in the .map format once more advanced features need to be saved.

Link to comment
Share on other sites

If I'm right, the mapfile parser is in idLib/mapfile.cpp :) Can't check it as I only have the sourcecode here to look at, but it looks like it. It also makes sense, because the mapfile can be completely replaced in the open part of the SDK and a map can be setup in any way you would like to. You can replace it with a binary format if you want to because the loading all happens in the gamex86.dll part.

Gerhard

Link to comment
Share on other sites

Yup. :) Only the material parser is not opened, because the textures are to close to the renderengine to allow for that. With the map we should eb able to do whatever we want. :)

 

I wonder if DoomEdit uses the same code to load the map, but I guess not. It has to be tested, but that would probably expecting to much.

Gerhard

Link to comment
Share on other sites

I wonder if DoomEdit uses the same code to load the map, but I guess not. It has to be tested, but that would probably expecting to much.

 

I would think so -- after all, why would they want to write a map parser twice when they have already written it a first time?

Link to comment
Share on other sites

Well, because the map loading code from the game doesn't neccessarily need to be the same as the one from the editor. They have to write a writer also, so maybe they did it in one go. Especially since the editor is essentially a seperate app. I guess we have to test it and see if the editor chokes or not. If not, it would be great. :) There is still the chance that custom stuff would be erased when the map is written back though. Depends on how the editor maintains the original mapfile.

Gerhard

Link to comment
Share on other sites

I read through the SDK parser once in the past, it's obviously old code originating from Quake 3 or earlier days (there are several (old) types of brushes supported, IIRC), so there's definitely room to change something here.

 

However, we should take care that both DarkRadiant and Doom 3 are able to parse all types of maps (native D3, and TDM-specific maps). Maybe it's enough to bump the mapfile version number from 2 to something higher - a turnout for switching map file parsers.

 

Of course, if DoomEdit has the map parser burned in its EXE file, then we're out of luck. This would mean that DoomEdit couldn't be used anymore for adjusting DarkRadiant maps.

Link to comment
Share on other sites

Brushes and patches don't have spawnargs, it was the worldspawn you were assigning that tag to actually. All other world brushes carry the same spawnarg, check it out.

Oh, yes. Now I know what you meant... Somehow I knew it wouldn't be that easy...

 

I think that it still would be better to have it working only with entieties rather than nothing, but hopefully you'll find a way to get around that problem.

Link to comment
Share on other sites

My guess is breaking DoomEd compatibility would go beyond just losing the pretty renderer, and in-editor particle editor, etc.; it would probably also break changes made in-game and saved out, like speaker editing and ragdoll placement. IMO, losing the realtime lighting is bad enough, without a solution in DR at this time (I guess namespace vanished).

 

Edit: Worldspawn brushes have identifiers, e.g., "// primitive 3". Couldn't that be used?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 1 reply
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...