OrbWeaver

Exactly. Take a load of macho men with large balls and small brains, give them deadly weapons, send them into a foreign country, kill a few of their mates and then act shocked when they start mistreating civilians (particular when you add a bit of racism into the equation).

"Tasteless" is an interesting way of putting it.

OK, that's fine. I thought if you had multiples you would have to use "/darkradiant/ui//toolbar", but if it works OK without having to explicitly use this then that shouldn't be a problem. I think a single path is more logical, it is what you would use when accessing keys in the Windows Registry, for example.

You probably won't be surprised to learn that CVS/SSH are massively easier under Linux as well.

That's an interesting idea. I was thinking mainly along the lines of dividing things into /game and /user (probably a better name than /ui), but leaving the door open for additional config files sounds like a good design. I'm not so keen on having two UI nodes though - is it possible to merge the nodes by adding all of the children of the new one onto the existing one? This way you could use unique XPaths rather than having to search by attribute. I agree that separate get and set functions would be the best way of doing this; I was a bit concerned that my original suggestion of just passing the xml::Document would give modules too much ability to screw up the registry. I wouldn't split out the name like that however - getXmlRegistryValue("/ui/state/showLightRadii") would be easier to use. I presume this was because the second text string was the name attribute to search for?

She? I'm offended that you left the UK off the American Bitch-Slave List.

You probably don't need to "merge" two nodes as much as append both nodes to a common parent node (maybe "/darkradiant" if XML requires a single named toplevel node). Yep, there is no urgency there. Once this is done it should be a huge step forward because we can put EVERYTHING in the XML registry - colours, UI state, window positions, basically anything that is either non-persistent, non-configurable or uses the Radiant preference system (which seems to be an ugly reimplementation of std::map) could use the new system.

No problem. It will be quite a large task because there is a lot of code that uses CGameDescription in some way.

Wow that was quick. At this rate DarkRadiant will be finished soon... When you were examining the render code for the lights, did you get any idea of how difficult it would be to create a function to overlay light falloff textures on their 2D volume renderings? I thought this might be a nice feature to help people line up lights without relying on the render view, but I don't know how difficult it would be.

At the moment the XML is a bit of a hybrid - the CGameDescription is used by legacy code but an xml::Document is retained for allowing XPath lookups. An entirely new class is probably not needed - if the GlobalRadiant module had a single method getXMLRegistry() to return the xml::Document& corresponding to both ui.xml and doom3.game appended under a common root node (so you would have "/ui/blah" and "/game/blah" in the same Document), then modules could simply use the relevant xmlutil methods on this document to lookup XPaths, examine children etc. Eventually CGameDescription could be removed altogether, with the existing keyvalues looked up as additional XPaths. Obviously the xmlutil library will need new methods to do things like append a child node, change node content etc.

You know what the saddest thing is? When I was reading that, I was actually pleasantly surprised that the agents only questioned her for 15 minutes, rather than handcuffing her and chucking her in a jail cell for 15 hours. Every time I start getting angry with Tony Blair and the UK's obsession with anti-terrorist crap, I just read some stories from the USA to learn what a police state really is.

I thought you might run into that. As you have noticed, the lights are rendered by the entity plugin which has no access to the state of the toolbars or other Radiant config widgets. There are three solutions which spring to mind: 1. Use some horrible "extern" global variables that can be accessed by both entity.dll and DarkRadiant itself. I don't recommend this (I have never done it and wouldn't know how to) but sharing variables between DLLs like this is an option. You might also run into problems with calling conventions across platforms (underscore versus no underscore in symbol names et.c) if you do this. 2. Add an extra function to the Radiant Module interface (include/qerplugin.h) to allow modules to query the state of the UI, just like I did with getXPath(). 3. Merge the ui and game XML trees like we discussed, so that modules can get UI state by looking up paths like GlobalRadiant().getXPath("/ui/state/showAllLightRadii") in the same way they can look up game paths. In the long run I think (3) would be the best, but if the merging of XML structures is not so easy then (2) would be acceptable.

Nobody ever tried to implement the Internet 60 years ago and found it to be impossible, it was just never envisioned. People could, and did, envision computers with human-level intelligence 60 years ago but the problem is no closer to being solved even with technological advances. The Internet is purely a technological issue. Strong AI is a philosophical issue which would coincide with the complete understanding of human consciousness, which may well never happen.

Excellent. That's the best bet.

All GTK widgets are owned by GTK, so you don't need to free them manually (except in certain cases). They use something called "floating reference counting" which means that although they start off with a reference count of 1, this reference is automatically owned by the parent widget as soon as they are packed (and hence will be destroyed with the parent widget). Yep. Never use const char*, ever. The only reason to use this is for GTK functions which require it, but in this case you should convert to char* at the last minute by calling the c_str() function on the string. I didn't mean in one file, I meant that the code could merge the two trees into a single in-memory tree. I haven't investigated in depth whether libxml2 can do this, although I suspect it can. One file is certainly what we don't want - it would mix up the user-specific UI settings with game-specific options that are not touched by the user.

OK, some preliminary comments in decreasing order of importance. Overall, the code structure is well-commented and readable, which is good. You seem to be allocating the toolbar creator on the heap with new but never deleting it. You should never do that in C++, it is a memory leak. If you only need the object for the duration of the function, allocate it on the stack as follows: toolbar::ToolbarCreator toolbarCreator(GameToolsPath_get()); This way it gets destructed automatically at the end of the scope, and doesn't cause a leak. UI code should be in the ui namespace, rather than an individual namespace like toolbar Don't write functions to take const char* as arguments -- make them take const std::string& which can be implicitly created from const char* without having to code an explicit cast. Your ToolbarCreator::ParseXml() function is taking an xml::Document by value rather than by reference, which means that the object will get copied when the function is called. This doesn't actually matter in this case because xml::Document only contains a pointer, but for larger objects this may be a problem. In fact, if I had written xml::Document properly it would actually "own" the entire XML document tree, which means that a pass-by-value would result in a complete traversal of the XML tree in order to copy it. I don't think ui.xml should be in the doom3.game folder, as it is not game-specific. I would put this in the main DarkRadiant install folder. Functions should start with lowercase letters, so that they can be distinguished easily from objects which have capital letters (i.e. ToolbarCreator::getToolbar() not GetToolBar()) You don't need to indent everything within a namespace -- most new code should be in a namespace and this would cause you to lose 4 characters for everything. Good work in all though, this should set the stage for greater UI customisability in future. I wonder if it is possible to merge the UI and game XML trees so that you could call GlobalRadiant().getXPath() with either a "/ui/blah/bleh" or "/game/blah/bleh" from other code.

I haven't yet seen any evidence that any breakthroughs in AI have been made which don't involve some combination of pattern-matching and curve-fitting. We are no closer to human-level intelligence (with creativity, self-awareness etc.) than we were 60 years ago, we just have massively faster computers to experiment with. Make no mistake, there's a lot you can do with pattern-matching and rule-based systems, but in this case the power of the system is a function of the rules entered into it by the human operator. We simply don't know how many of the creative, "human" characteristics arise, which makes developing algorithms to simulate them extraordinarily difficult.

Well it compiles, runs and the toolbar looks OK, so it's looking good so far. I will look at the code in more detail tomorrow.

The problem is that you are rewriting something which is already entwined with legacy Radiant code, rather than adding an entirely new feature which does not require any interaction with the Radiant Template Crap . You can always take an SVN diff of your changes, archive it and then work on something more localised if the rewrite seems to be getting too complex.

That would seem to me to be exceedingly difficult. What you describe is essentially radiosity in reverse, which I imagine is a similar order of complexity to reconstructing the original brushes from the processed geometry.

This is certainly possible in DarkRadiant, you can edit the worldspawn like any other entity by selecting a brush. I assume that Doom 3 must support it as well hence the keyvalues appearing in ascottk's map. I also think that this would be a good way of storing global state; it might even be possible to use "editor_xyz" keys to store editor-specific state such as the last part of the map you were viewing in the editor.

I'm not sure it would even be possible, because Doom 3 has no support for lightmaps. How would you simulate this, by autogenerating decals and overlaying them on geometric surfaces? I guess it could be done, but would be phenomenally complex when people could just play Thief.

Fixed in rev 376

The problem seems to be that the worldspawn Doom3Group is being considered a model (func_static) because the "model" key (which is unset) differs from the "name" key. I have corrected this by adding a separate exclusion for "worldspawn" in Doom3Group::updateIsModel() which solves the worldspawn issue, but now there is another problem with the entity named "trigger_hurt_2" which contains both child brushes and has a model key equal to the name key. EDIT: Never mind, got it the wrong way round. Model == name means NOT a model entity.

Exactly. People seem to view legacy Thief levels/FMs as some kind of holy grail that will look wonderful in any engine and be superior to anything created from scratch, without realising just how primitive the Dark Engine is compared with modern games. The Thief games were great, but it's time to move on.