OrbWeaver

I believe sparhawk is talking about the "Create entity" dialog not the Entity Inspector. As you will have noticed, this dialog is just a flat list with everything in it, rather than a tree with entities structured by purpose.

I almost wonder if the best way to display the keys would be to have a flat list, rather than a categorised list (hence minimising clicks and displaying more information at once), but have an "Add" button/menuitem which allowed you to select a key to add from a hierarchical menu (like Dromed), as well as text boxes to enter the keys by hand if preferred, and the key-specific property editor at the bottom. The categorised view does have a certain "cool factor" but it seems like for actual use by mappers it might be more of a burden than an enhancement.

Yes, you'll note that the DefTokeniser constructor actually takes a list of delimiters but does nothing with it. Really it should take two lists (kept and non-kept) and pass them down to the DefTokeniserFunc. I think this code exists from when I was initially trying to use a standard Boost tokeniser (which takes a list of separators) before realising that I had to write my own. Excellent, I look forward to seeing the result.

The RenderableAABB adapter class is now in, and math/aabb.* no longer requires OpenGL so hopefully this should work OK now.

That is perfectly possible to implement, if that is the direction we want to go in terms of specifying the entity hierarchy (and it sounds reasonable enough to me). I would suggest a key like "editor_entityBrowserPath" since I am pretty sure than anything starting with "editor_" is ignored by the game (which actually gives us a potentially unlimited amount of editor-specific information storage).

Would these issues be improved by modifying the All Properties dialog so that you could enter a number of keys just by typing and pressing Enter (like Venus said)? I actually agree that the categorised entity list may need some improvement, for the simple reasons that I hardly ever use this method to examine keys - "too many clicks" I think is the problem. It is not obvious what to do about this: although a simple Doom 3 interface could be used, I don't want to lose either the newbie-friendliness of making all the available keys visible, or the key-specific editing interfaces (like the color selection button for "_color" keys). I wonder if the two interfaces could be combined in some way, bearing in mind the screen space is limited. I guess as a last resort a simple preferences option to select one of two interface styles would be sufficient, but I don't really favour this kind of thing because it requires twice as much maintenance, and doesn't encourage the development of a "good" interface which should be usable by all.

Not really, a manual merge is the only real way to do this. Fortunately SVN makes it very easy to get a repository-wide diff of each revision, and using patch on Linux I can merge in changes without too much effort. Obviously this will get harder as the two codebases tend to separate, and patches for GTKRadiant will no longer work - fortunately most upstream fixes are irrelevant to DarkRadiant (like enhancements for Enemy Territory support, or bugfixes in code that I have already replaced) so this won't be too much of a problem. The "enhanced texturebrowser" functionality is similar to what I was intending for the media browser, except that it limits space by combining the tree and the texture view in a single window, and also only allows single-level browsing of texture "families".

I guess it just refers to matter which is expelled outwards at less than the required escape velocity - there will be a point where this matter loses its outward momentum and forms a boundary of some sort.

I haven't actually removed any key shortcuts to my knowledge, but these might be additions to GTK since the start of DarkRadiant. It may be possible to merge these features into the codebase if they are upstream. The idea is that all of the keys mappers need to use will be in the tree list (this mirrors the Dromed and T3Ed methods, and is more user-friendly than requiring mappers to memorise key names). There are a lot of keys still to be added which is why you need to use the All Properties dialog, but this is not the intention in the long run. You shouldn't have to deselect a key before using the Add button however, this may be a bug.

My journey ends there.

Yes, that's something that needs doing. I will add a task to upgrade the filter system to allow arbitrary objects to query whether they should display arbitrary textures, and then it is a simple matter of getting the model rendering code to use this function.

I think many amateur "web designers" simply don't realise that adding size information to an image still results in the whole large image downloading to the browser, so they never bother to scale it properly. Perhaps if they did have to manually scale, they would realise how stupid using tiny images is (or maybe they just have 640x480 screens and their 210x130 image actually looks quite large).

If they are not relied upon by Doom 3 code, strip them. If they are required in this way, consider rewriting the Doom 3 code so as not to use them, although this may well involve more work and is not necessarily required.

The strange thing is, the object file generating the error (aabb.o in libmath.a) only has undefined symbols for the underscore versions - _glVertex3f@12 etc. These match the exported symbols from libopengl32.a, which means they should match - which they do in entity but not md3model.

Have a go if you like; however I don't think it is something worth spending too much time on (also I have a feeling the Cygwin + GTK = nastiness). I was tempted to use an adaptor class to start with anyway - OpenGL rendering is not an integral part of the representation of a bounding box and therefore there is a good argument for not having the math library depend on this. What I will probably do is add a class RenderableAABB in radiant/ui/common, which will implement the OpenGLRenderable interface (irender.h) to draw the bounding box (and if that doesn't link, I'll give up programming altogether and become a pastry chef).

Well spotted, that's a bug. Actually I forgot to add code to set the "skin" parameter when you finish with the modelviewer and create a model. The fix is in SVN for the next release. Eh? It does render skins - are you referring to the problem New Horizon mentioned above? Very possibly, I would be surprised if undo did work correctly with texture alignment and other mathematical transformations. Can you be more specific? Does it just not do the save, or save to an unexpected place, or what? You can choose a different pixel size if the "constant size" option is enabled. This can be configured in the Preferences dialog.

I give up. This makes no sense whatsoever. The md3model and entity build environments are IDENTICAL apart from the source filenames, but one will link these symbols and the other won't. Just blank out the body of AABB::render() in libs/math/aabb.cpp for the time being, and I will find some other way of making the AABB renderable, perhaps using a separate adaptor class in the ModelSelector itself (which may be a better idea anyway - rendering functions are not a natural part of a math library).

That's what I thought. Which raises the question, why in this case has GCC decided to look for symbols WITHOUT a leading underscore? The only thing unusual about this case is that it is the first time I have made OpenGL calls from within a static library. Maybe there is some special treatment that is given to libraries that causes the symbol naming convention to be changed.

I'm using MinGW. I can recreate the error, but am at a complete loss as to what is causing it. Running nm on the MinGW version of libopengl32.a reveals that all of those symbols do exist, but they have leading underscores (_glBegin@4 etc.). At first I thought that this problem was caused by having the -lmath option after the OpenGL linker options, but changing this doesn't solve anything.

That won't solve the problem with ordering though. All of the glass may get drawn, but not necessarily in the right order.

If it's a new class, yes. If you are editing an existing class, don't worry about extracting it (although you are welcome to if you wish).

I don't understand that linker error, all of the relevant GL libraries appear in the link commandline. I will have to try building on Windows and see if I can replicate the error. Emulating the existing coding style is good idea, but make sure you emulate the style in my additions (anything under radiant/ui) rather than the existing GTKRadiant codebase. I want to move away from some of the ugliness in the legacy code, like using C-style functions and char* arrays rather than C++ objects and strings. The naming conventions are basically Java-style - capitalised class names, variables and methods start with lowercase, one class per file pair (e.g. MyClass.h / MyClass.cpp) and class methods rather than C-style functions (Vector3::scaleBy(float factor) not Vector3_scale(const Vector3& self, float factor)). I'm not too bothered about indentation and spacing as long as it is readable and consistent, although I would prefer 4 spaces rather than 2.

Cool. I guess I'd better write up some coding standards for DarkRadiant now we have a couple of people working on it.

The X850XT is considerable faster than the 9800XT (they are both top of their respective generations, but the X850XT is a generation newer). It has 6 vertex shaders and 16 pixel shaders as opposed to the 9800XT's 4 vertex and 8 pixels (IIRC), and allows me to play Doom 3 at 1280x1024 with antialiasing at full framerate, whereas before I would generally have to use 1024x768 with little or no antialiasing to get a smooth display. I suspect the 7800GS would be better though, if the cost is not too great. With that you will at least get Shader Model 3.0 and proper Linux support.

Fixed. I had forgotten to add useOpenGL() to the math libary build options when making the AABB renderable. Unfortunately I tend not to see these errors on Linux because everything is located under /usr/include, so include paths don't need to be specified, but obviously on Windows this doesn't work.