greebo

I will take a look at it. Have you tried to use "//game/filtersystem//filter"?

Yes, the game settings are already stored in the registry, you can use the registry() method for access game information from now on. I did not change anything of the "old" CGame* interface, so there exist both possibilites at the moment. edit: There is a debug method called registry().dump(), which outputs all XML content of the registry to the console, if you ever need it.

I can imagine that if we add new toolbar buttons in a new DarkRadiant release the changes won't take an effect unless the user's own XML is deleted. I also thought of adding a version tag somewhere in the install/user.xml so that DarkRadiant can check whether the user.xml is possibly stemming from a previous DR install, and it can take the appropriate actions (i.e. delete the user.xml or merge it with the new settings or at least notify the user). But I guess this will not be a major problem as long as we have a hand full of DR beta mappers. Till we're in the situation of having hundreds of DarkRadiant users and we plan to release a new version, we sure will come up with some solution. Ah, didn't know that one! Well, I'm learning something new every day...

I gave Ubuntu a shot last week and the installation was very easy. The look and feel is fine and the installation of new packages is also quite easy (as long as you don't need any exotic packages, but if you actually need them you are probably able to figure out where to find on your own...). And even then it's a matter of some mouse-clicks. I'm not very impressed by the multitasking performance though, it runs quite lame on my system - my linux installation seems to eat more memory than my Windows XP. During DarkRadiant compilation and especially during linking it's a pain to use Firefox for surfing the web. If I had more experience in configuring a Linux system I would probably find a way to improve the performance, but I'm somehow not very motivated to dig into the OS, as I have to use my spare time wisely these days (for posts like this for example ). I also have to say, that inspite of being easy to install, there is still some work to do before ubuntu can really claim to be the linux distro of choice for Windows-fugitives - there are still too many console commands to copy out of ubuntu forum threads hidden on the web if you dare to leave the predefined path of using the preinstalled Openoffice.org apps. (I remembered my first Linux installation in the year 1993 or 1994, which was definitely a challenge those days. Take the huge amount of 20 3.5" floppy disks and nearly NO documentation and try to compile this piece. Anyways, it was kind of pointless for me, as I couldn't use it for anything back then. Ha, things have changed I guess)

Ok, this sounds simpler than I thought. The radiant source code doesn't look like a good place to learn such stuff by code-reading. One question though: can the class RadiantCoreAPI inherit from a struct or is this a typo? Nevertheless, I've committed all the changes now, including the removal of the texture menu. One note on the registry behaviour: You may already have noticed that whenever the install/user.xml changes, one has to delete the user.xml in the user settings folder, otherwise the changes would get buried under the user settings (they are added above the default values).

Yes, I realised this as soon as I read through my above post and thought of the same solution (except for passing a reference) No, the pointers are not the problem, it didn't take me long to figure this out - it's those template cascades that really give me the creeps... How would such an implementation of an abstract base class access radiant's core assets like the XMLRegistry? Would a reference need to be passed to the implementation by the plugin loading system?

Am I getting this right? namespace xml { class xmlRegistryWrapper { static XMLRegistry _xmlRegistry; public: XMLRegistry* getRegistry() { return &_xmlRegistry; } } } // namespace xml xml::XMLRegistry* registry() { return xml::xmlRegistryWrapper::getRegistry(); } and within RadiantCoreAPI: m_radiantcore.registry = &registry; or could the RadiantCoreAPI "link" directly to the class method? Like this: m_radiantcore.registry = &(xml::xmlRegistryWrapper::getRegistry);

Is there another possibility for the GlobalRadiant().registry() function (and other functions) to obtain the XMLRegistry instance other than a global variable that is defined in the radiant core environment? If yes, we sure could join these two (although the simple xmlRegistry variable would be much shorter to type, but this is more of cosmetic nature). I'm not sure about what can be done in C++ and what not, that's why the above question may sound a bit trivial...

Ok, the changes are committed now, I also changed the ToolbarCreator to use the XMLRegistry (ui.xml has been embedded into the user.xml). User settings (at the moment just the state of the ShowAllLightRadii, which is off by default now) are saved at DarkRadiant exit and reloaded on startup. The XMLRegistry interface for plugins has been changed as well, so that all plugins can access the whole registry by using GlobalRadiant.registry.get("") or any other function that the registry class provides. I also updated the documentation of XMLRegistry, but it's quite straight forward to use, I think.

Well then, I'll do it that way. I will do some tests the next few days and the commit will hopefully follow on the weekend.

Don't know if we need to distinguish between "static" ui settings and ui-specific things that should be saved, like the state of the showAllLightRadii button. Dropping the globals would indeed make sense, as everything stored in the registry is global by default... maybe we should create a node like "ui/state" where all ui user settings go? User settings that override default settings need to have the same path, otherwise we would have to write additional code that queries both (separate) paths.

A thing that will definitely need a bit of tweaking is the actual XML hierarchy, i.e. what is stored at which place. At the moment I have the top node with two children: and , each of which may have several substructures like /darkradiant/ui/toolbar or /darkradiant/globals/ui/showAllLightRadii. I think it makes sense to add another node named which stores all the information from the doom3.game file and other game-specific things. Overall, I think this will grow and evolve over time. I have also implemented an export function that allows to export a specific node (and all its children) into a file. This way we can save a whole tree of user settings and load them again into the right place at DR startup. I tested this with the showAllLightRadii switch and this works fine.

Just wanted to drop a note here, that I'm still working on the XML library. I could hardly make some progress as my free time was too fragmented :-), but I could go some small steps forward this evening. I reorganised the interface of XMLRegistry making the naming hopefully more intuitive. Newly imported XML files are internally added "on top" of the existing XML data, so that keys imported at a later time during startup actually overwrite previously existing keys. I extended the functionality of the import method, so that one can specify at which point in the XML tree the keys are imported (the file becomes a child of the specified node, defaults to TOPLEVEL_NODE of course). More to come, stay tuned ;-)

Ok, good to know. Looks like a hard-to-find bug for me...

This has to be the all-time record. Thanks for fixing this, what was the problem after all?

I just checked: the Tree view does not appear within 30 seconds, memory usage stays constant. As soon as I right-click into the white space, DR starts eating memory. This does not appear under Linux, the tree view appears almost instantly, maybe there is some problem with the paths (slash direction or something like that)? Looks not bad, by the way. Do you intend to add a preview for the selected textures as you highlight them in the view? Can they be added to the texture view by double-click in addition to the context menu?

ad 1) I didn't wait too long, but the tree did not appear in that time. How long does it usually take to load the tree? (If this normally takes more time than the average mapper is inclined to wait, we should have something like "Loading Texture Tree - please wait" appear in the window instead.) Don't know if the memory usage went out of hand before or after clicking the context menu. Will check that when I get home. ad 2) There was certainly nothing selected, as I couldn't select anything. There was just a blank white space spanning over the whole tab content. Maybe this is related, but I can't say. The context menu worked however. If you can't reproduce it on your system I will try to debug this on my system.

No, forgot to say that this is on my Windows partition, Doom 3 is working just fine. I checked the radiant.log file but there doesn't appear anything suspicious. Can't you reproduce it on your Windows installation?

My Media Browser tab is just white and empty. I see the context menu when I right click into the white space, but then DR hangs and starts to eat up my memory (went up to 600 Megs till I terminated the process).

Hm, that's true. I'll not spend too much energy on this then.

Ah, so there is my problem. I will try and experiment, which assets are "minimal" for DarkRadiant operation by copying them from my Windows install to my Linux partition. Maybe I can assemble a copyright-free minimum package that will be sufficient for Level Editing with DarkRadiant.

I just did a full, clean compile and it still produces this error (I am on rev. 389 too). Can't reproduce the error under Windows (also after a fresh compile), so there is something odd going on here. I will try and investigate this problem, perhaps there is something wrong with the modules. Do I need a working Doom 3 install in Linux for DarkRadiant to work? I just left the Engine Path at "usr/local/doom3", as I don't need any shaders or such. Does DR rely on any light-specific assets from the D3 folder?

Ok, now this is new to me: I just right-clicked the orthogonal view and chose "Create Light..." and DR crashed saying: terminate called after throwing an instance of 'EntityCreationException' what(): Unable to create entity "light", no brushes selected Aborted If I create a brush and then the light entity of this brush, it works. Has this changed lately? I did not need to have any brushes selected in my Windows build.

Doesn't work (package is not found/known) , that's why I compiled it myself in the first place. I will do a search on ubuntu forums and see if there is anything useful. The Synaptic package manager doesn't list anything like that either. edit: Ok, I found this package on a debian site and could install it after installing the dependent gtkglext1 package. DarkRadiant is booting now, seems like I can be coding again soon.

Hm, I did not check that but I remember that the file was green-coloured (if that tells anything). And it was approx. 32 kiB in size. I will double-check that though as soon as I'm home again.