WOW! Comments on anything!

[Fidcal]

I often found it useful in Dromed to use the 'editor's notes' property on objects to add a comment where there was something unusual that I would never remember in connection with that object. This was mostly something like DO NOT REMOVE! OFFSET MARKER FOR.... where an object performed some function that was not obvious and ran the risk months later of being casually deleted as obsolete or just a mistaken clone.

 

Wished Dark Radiant could do this... Then I recalled accidentally misspelling a property name and it was accepted so I tried...

 

Comment

DO NOT REMOVE ELSE...

 

Yes! And this even works on brushes, on anything.

 

Is delete protection possible in DR to stop an item from deletion if it has say, a deleteLock property?

[greebo]

Note that brushes don't have their own set of spawnargs each, they are children of the worldspawn entity. Hence, if you edit the spawnargs of a brush/patch, you're editing the worldspawn spawnargs instead. Select a different brush and you'll see the same spawnargs again. A way around this would be to move brushes to func_* entities, which allows them to share the spawnargs with that entity instead of worldspawn.

 

Delete protection for brushes is not possible; as mentioned, there is currently no way for brushes to store information. This would work for entities, although we'll have to think of a consistent way to handle that. A "editor_readonly" = "1" property could do the trick here.

 

As soon as we've found an elegant solution to store information for each object, we could also implement the often-requested layers and parenting feature.

[sparhawk]

I know it's not an elegant solution, but why not use comments? Since it is only metadata, it shouldn't matter. Like:

// NOTE: saljkdfhasdjkf

// PARENT: asdjsdj

...

[OrbWeaver]

You mean comments in tha map file? That isn't really possible, because the Tokeniser automatically strips comments before passing the token stream to the parser code, meaning that the parser would never be able to retrieve this information. Adding special-case code to the tokeniser to prevent it from stripping comments IF they contain this metadata is a ghastly and unthinkable layering violation IMO.

[Fidcal]

Yes, I see the comment appears on all brushes! Oh well. It should be OK for entities so that will probably cover most situations. It's not needed a lot and most mappers probably never. Unfortunately the odd case I have now will not work if it is an entity.

[sparhawk]

Yeah. Generaly I don't like a comment abuse either, but I don't see many ways which are better. After all, you will need either a seperate mapfile which contains metadata like this (which might not be so bad as it doesn't contain any absolutely information anyway. Or you would have to extend the parser.

[greebo]

I think we can actually change the Doom 3 map parser, the code is in the SDK. Hm, but this sure would break compatibility with DoomEdit and other Quake 4 stuff, which we probably don't want.

[SneaksieDave]

You could probably make a single brush (if that's what you need) into a func_group, and attach a comment to it that way. Func_group is for editor purposes only and is ignored by the game and compiler.

[greebo]

Yes, for primitives this would work, but not for entities. No entities are allowed as children of other entities.

 

edit: Wait, do you mean, the func_group is completely dissolved by the game parser? So that it actually can have entities as children too?

[Fidcal]

You can just add a comment property to any entity so if it does not want to be a static or anything else for some reason, and if func_group is otherwise passive then it works fine on that. Though on mine a func_group is rendered invisible in the grid as black and I can't see how to change it.

 

Just done a search for func_group and it seems it is nothing in the game at all so it is not of any use for this. The purpose of the comment (for me anyway) is to comment on a real item in the game not just a lone comment on the grid that isn't a part of the actual game.

[SneaksieDave]

I thought editor level comments were what you wanted... you want them to appear in game? There's surely a way to do that, but I don't know it. Doubtful with brushes.

 

I use SuperMal - a brush is black, and the func_group is black - no change.

 

edit: Wait, do you mean, the func_group is completely dissolved by the game parser? So that it actually can have entities as children too?

No, I think it's for brushes only; if you try to create an entity (the func_group) when the selection contains a func_*, it isn't an option.

[Fidcal]

I thought editor level comments were what you wanted... you want them to appear in game?

No - I only want them in the editor. What I mean is if I have an actual item - any item - in the map whether it be a brush, an entity, a model, that exists on the grid, a wall, a door, anything, then I might for some reason occasionally want to add a comment to appear in its properties. This can already be done with any entity. A worldspawn brush needs converting to an entity first. The item has a purpose; the comment just makes a remark concerning the item it is placed upon. So on an oddly-placed cupboard I might add:

 

Comment

DO NOT MOVE BECAUSE...

 

Your idea of a func_group entity presumably means create a new separate item in the map with a comment - a stand-alone comment with no other purpose than to be a comment. So that might be used with for example:

 

Comment

REMEMBER TO ADD STATUE X HERE WHEN AVAILABLE.

[SneaksieDave]

The brush itself is made into the func_group, you don't need a new object. Select the brushes, turn them into a func_group, add a comment. It's ignored by the game and compiler so it's editor-only. When you don't need the comment anymore, select the func_group and revert to worldspawn.

[Fidcal]

Mmmm... Just tried it and it shows in the editor but my brush is no longer rendered in the game. It still seems to me to be ideal as a stand alone comment marker in the editor but not to add a comment to something in the game as I described before.

[SneaksieDave]

Serious? Let me try...

 

Sigh, yes, the brush no longer shows up, even when re-compiled. Okay, this is a problem (well, more of a pain than anything serious). This was supposed to be in place for ease of operations (like rotation or selection) on multi-brush groups, without having to turn them into func_static.

 

Anyone know if there's a compiler option to force it to turn func_groups back into worldspawn upon build, or if it's possible this was somehow broken in TDM?

 

Usage: Used to group brushes together just for editor convenience. They are turned into normal brushes by the utilities.

[Fidcal]

Well I think it could be useful as it is. But for me only if I could change its colour from black as it does not show on my black background.

 

I visualize creating a distinctive comment shape - perhaps an asterisk - which can be placed anywhere on the grid as a stand alone comment 'REMEMBER TO PUT TREES HERE' or 'PREVENT GUARDS ENTERING THIS ROOM SOMEHOW' without it affecting the game. One could even have letters of the alphabet to have short comments actually visible in the grid.

[greebo]

You can change the colour of the entities by editing the entityDefs and setting the "editor_color" spawnarg. It's in the darkmod/def/ folder in func.def:

entityDef func_group {
"editor_color"				"0 0 0"	  // change this
"editor_mins"				"?"
"editor_maxs"				"?"

"editor_usage"				"Used to group brushes together just for editor convenience.  They are turned into normal brushes by the utilities."
}

[SneaksieDave]

Editor comments on the map (whether visible at a glance or via click of an object and reading its comment property) sound like a nice idea to me. There are definitely uses for that - personal reminders, explanation to downloaders (like comments in code), etc.

 

Remember whatever editor color may be chosen will affect all other schemes as well, so it's probably best to choose something already established (for instance, similar to the color of func_static).

[Fidcal]

OK, got this now. I have edited the entry in func.def to 0 200 255 to get a bright blue and made a group in the shape of a plus sign from any angle, top, front, or side and added a test comment. And saved it as a prefab Comment.pfb so I can insert it anywhere I need a comment. Maybe a better shape could be thought up than a plus sign but it wants to be the same from any view.

[Fidcal]

Changed this to an asterisk. Probably reduce it in size later.

 

Crossed my mind that an svn update would conflict/overwrite my modified func.def but it didn't seem to take any notice of it when I just updated. I would have expected tortoise to try to sync that. Anyway, surely any later changes to func.def up on svn would overwrite my copy? What would happen if I made a separate def file just for func_group? Which one would be used? I'm just looking for trouble but it does seem odd I can change a file that is common to everyone.

[greebo]

Tortoise would try to merge the changes if the func.def was changed on the server. This is not very likely to happen, as this func.def seems to be a plain copy from the vanilla Doom3 folders. Even if somebody changes anything in that file, the func_group entityDef will not get touched if it is not affected by the changes.

 

Tortoise only touches your func.def file if it gets changed on the server by somebody else in the first place. It won't clear out any local modifications just like that.

 

Don't define the func_group in another def file, this would be a conflict due to a double-definition. Both DEF files would get parsed and Doom 3/DarkRadiant would complain about a duplicate func_group definition.

 

Ah, yes, and don't commit your changed file.

[Fidcal]

Seems there's already a stand alone comment entity called 'text'. Shows as a little arrow you can point and I think optionally the text can appear in game.