greebo

I've implemented your suggestion as follows: The XMLRegistry has now two RegistryTree instances, namely the standard tree and the user tree. The Registry interface (iregistry.h) stayed nearly untouched, the commands are passed in such way to the subtrees that only the user tree eats the write accesses and the default tree is treated as read-only. A Tree enum value can be passed to the import() method so that the client can choose which tree the file should be imported into. I've tested it with a few settings and so far it seems to work without complaints. Maybe there will some issues come to the surface during the future testing, but the overall behaviour is ok. edit: oh, and I sent the upgradepath code to sleep into a separate file, so it's inactive at the moment. I can reimplement it should we need it in the future. I will leave the existing upgradePaths for the moment being.

I'm currently changing the XMLRegistry to use two trees (it turns out to be quite straightforward, so I'll be finished soon). Feel free to create a dialog, I've got some other tasks assigned in the bugtracker as well.

Ok, the info_player_start eclass name is stored in doom3.game along with the two editor_drLastBleh keys. I tweaked the handling of these editor-specific keys such that they are removed as soon as they have been parsed and therefore won't bother the user while editing the map.

Merged and committed as we speak. The overlay module and the camera position restore is now in trunk. The camera restore could do with a bit of polishing (moving the player start entity key names into doom3.game and so on). The current camera position is saved under editor_drLastCameraPos. Should I move this key name into doom3.game or leave it hardcoded as a constant (as it's not exactly game-specific)?

I merged your last commit into the branch, so it should be up to date. How do I merge the branch back into the trunk? Can this be done by choosing "Merge" from TortoiseSVN's menu or should I do this manually / in another way?

Ok, I will try to implement the dual-tree solution then >> opened an issue on the bugtracker.

It definitely sounds feasible, with some testing this should be implemented quite quickly. Parts of our problems could be (or could have been) solved via the upgradepaths I implemented a while ago, but admittedly not all of them. I could think of two more approaches additionally to the one you suggested: 1) Instead of maintaining two separate trees in the memory the written values could be tagged with a "dirty" flag, which will have them exported at DarkRadiant shutdown. This would require a minimal algorithm change at the point where the files are exported, as we would delete all the nodes without the dirty flag. I haven't thought entirely through this, but it may offer some advantages. 2) We think about what values are going into the user.xml (and therefore into the local copy) in the first place (and which are not). Definitely there are some values that have to be kept (like last opened maps, for example, or cubic clipping or the background image), and some others can be categorised as "advanced" DarkRadiant tweaking like changing the size of the ModelPreview window or changing the toolbar arrangements. In short, some values are more "worthy" being saved and kept over DarkRadiant upgrades, and some are not (and are more likely to be overwritten at the next release). This would be a distinction of "DarkRadiant State" or "Preferences" (MRU, Cubic Clipping) and "DarkRadiant Configuration" (sizes, toolbar arrangements, etc.). Users that want to fiddle around with configuration settings can do this as well in the main configuration files, as those values aren't accessible via an interface anyways (so it technically doesn't make large a difference which file they edit). If they are willing to mess around in XML files, they might do it a second time as well after they upgraded their DarkRadiant. These are my first thoughts about this, it can well be that a hybrid approach of all the above could be realised and covers most of our problems.

Orbweaver, can I already merge the changes from the overlay_plugin back into the trunk (now that 0.8.1 is released) or do you want me to wait with that?

My ISP just sent me an email (Sunday, 17:00 - before I contacted them ) and they told me that they will move my account to a better server (it sounded like it was their own server, so let's hope this improves things a lot).

I know. This is getting really on my nerves. I will contact my ISP again tomorrow.

A triple hooray for ascottk (and one for the builder priest too)! Looks really good!

I turned the zooming option on by default and increased the maximum image scale, so that the image can be magnified over a large part of the map. The commits from trunk are all merged into the overlay_plugin branch - I will just wait for Orbweaver to wave the flag before I move the new features into the trunk.

Fixed on latest SVN (trunk & overlay_plugin branch). The GlobalModelSkinCacheModuleRef inheritance was missing in SkinChooser.h Edit: I discovered another issue, maybe this is reproducible on your system as well, Orbweaver? I described how to reproduce the problem in the Bugtracker (maze1.map, try to give the AI in the upper left corner a skin). edit2: I seem to be stuck. I left a note on the bugtracker where this error occurs. Maybe you could look into it, Orbweaver?

Reproducible on my system. I'll open a bug and will start looking into it. edit: found the problem, fix is in progress.

What steps does it require to produce this crash? Did you just open it? Did you choose a skin via the Modelselector or via the Entity Inspector?

I committed another feature to the overlay_plugin branch: the camera position and view angles are now saved to the worldspawn entity on map save. I tested it with maze1.map and it seems to work. If the custom entity keys are not found, DarkRadiant falls back to the ordinary GtkRadiant behaviour (info_player_start is used as camera position).

Yep, this was on my end too and it's fixed now. Also on SVN: the image is zoomable together with the orthoviews, just toggle the checkbox in the preferences.

No problem, if there are some more useful buttons, this won't be much of a problem. A few changes in the GlobalXYWnd class and the toolbar is there. The quad has 3D coordinates, which are being calculated and passed by the XYView render function. If we're going to position the image at absolute map coordinates, this could impose some problems, because the texture it's not draggable or anything, hence you'd have to enter the coordinates by hand (or we find a different solution). Another problem with the absolute position would be that the coordiantes would have to be recalculated everytime the XY viewtype is being changed to XZ or YZ (I think). As for the zooming: each xy view has its own scale variable, which could be passed to the Overlay module. The scaling could be added to the other scaling - I think this would work. BTW, the "Keep Proportions" setting is now on the latest branch SVN.

I would dislike adding a toolbar to the orthoview, because it would decrease the effective working size just for one single icon. I'd rather place it on the top toolbar, there should be enough space left. However, this requires to create a separate dialog, but this should be feasible. I've been thinking several times about creating a new interface to enable plugins to easily create and show dialog windows / message popups / etc. Fit to window is the default right now (scale = 1.0), I will add the other one. The sliders are measured relatively to the image size. An X shift of -1.0 would mean that the texture is completely shifted out of sight to the left. This way every possible position is easily accessible without going into pixels, but I can change it, if you want me to. I know that one. Blender is also resizing the image when zooming in/out. Is this wanted behaviour for DarkRadiant? Mr. Mike originally suggested this feature, so what does he say about this?

You are compiling under Linux, I guess? Perhaps there is the boost multi_index package missing on your system? I needed this for the MRU menu refactor a few weeks ago.

I merged in the changes from the trunk into the overlay_plugin branch. The changes were orthogonal (apart from a small change to user.xml), so this wasn't a problem. However, I'm performing a fresh compile to double-check.

Ok, I've got a working version of the Overlay module and I would like to merge my changes back together with the TexturesMap refactor. Do you want me to wait until after the bugfix release (0.8.1)?

I somehow need an LoadImageCallback as well to incorporate it into the current TexturesMap class, so this has to be placed somewhere as well.

Ok, I wrote my own GdkImageLoader now and it works. It's slow as I transfer the RGBA values one by one (takes about 1 sec. for a 8 megapixel image on my system, so I guess it's ok). Where should I put this loader? Should I attach it to the existing image modules and name it "GDK", so that other modules can make use of it as well? Or should I leave it as helper class in the Overlay plugin?

I played around a bit more with the image modules and now it's getting weird, because if I specify a BMP, the image gets loaded fine, but that's the only format that is successfully loaded. All the others (TGA, JPG, DDS) fail to load and can't seem to fill their ScopedArchiveBuffer properly. This bugs me... edit: I found the problem, it seemed that the ScopedArchiveBuffer cannot be used more than once as the filepointer doesn't get reset to the start of the inputfile. I can work my way around this, I think. Still, I could implement an own imageloader making use of GdkPixBuf as well.