greebo

Whoopsie, this should be the problem. I edited the paths via find/replace, and as the path names can be very long, I didn't notice that the trailing quotes were missing. Obviously it doesn't harm the Doom3 importer, which made me believe everything was fine with the model... However, thanks for finding this out!

I can't believe no one has noticed yet: Happy Birthday to our AI wizard!

This is happening in every view, the model appears fine in-game, btw. You've got mail

Next bug: I was working on my bonehoard entrance model, which I export from Blender into ASE using Goofos exporter script. After splitting the model into separate objects (still within the same ASE), some parts started disappearing in DarkRadiant, and finally the model doesn't appear at all. I suspect that the number of subobjects is the cause here, is there a limit concerning the maximum number of objects or textures within a single model?

Could this be related to the shader normal map stuff you changed recently?

Phew, I'm glad it was just that. For a moment I thought I've messed up something again. Recompiling now...

Point me in a direction, it's most probably my EventManager module...

Reproducable on my system. Damn. I will also look into this.

That's a good move. What else is missing for a 0.8.0 release? I'm currently working on the CommandList Dialog, but that is not a very vital feature, because it's always editable through the input.xml file.

Well, then I will possibly be sued for aiding and abetting the crime

I committed another fix for the "feature" that caused XYViews to stay on top even if the main window got minimised. The original GtkRadiant code did implement this and I took the relevant part and packed it into the TransientWindow class.

Fixed. There was a problem with an uninitialised member variable in Doom3LightRadius.h. I don't know if I should laugh or slap myself in the face. It was damn hard to find, because usually the lightCenterChanged() method gets called immediately after instantiating a light, but in some cases it does not. I've no idea, why this is the case, but it seems to be random and it therefore appeared more often in large maps. Linux seems to be more stable with these things as well, maybe there is some compiler-specific initialisiation of member-variables? Anyway, we can kick that one off the list...

There is some documentation on the XMLRegistry on DarkWiki now. Maybe this is of some help for namespace. http://www.thirdfilms.com/darkwiki/index.p...ant_XMLRegistry

As I'm returning a larger AABB than the standard one, I would assume that the lights don't disappear at all (even when they're not visible, but this is obviously not the case).

Ok, I could make the map visible again by reverting the code, so the big problem is solved. As expected the light center is only draggable when within the small light "diamond", so I will try to fix this in a different way.

Yeah, I know that code, I have been there before. I don't think I will change anything here, as this would affect all other instances as well, and I certainly don't want to do change anything on that scale. I'm still compiling the new revision, hopefully I can make the map visible again by reverting the localAABB() code. This will break the light_center dragging, but I will find some way around this.

Namespace, what are your plans/ideas for DarkRadiant? Or have you and Orbweaver already talked about this?

Some news on this: as we suspected, it's the Light::localAABB() method that I had to adapt to make the light_center touchable when placed outside of the light volume. I will further look into it what exactly can be done about this. At the moment there are three methods (I think) that return various types of light-AABBs, so I will have to figure out, which one of these is used by the renderer. It's a single line that got changed, so hopefully I can work with the current SVN build as well. This would make merging the fix into the codebase easier.

I normally mean and try to keep the commits small and separate too, but sometimes this is hard to do, because a small change entails a bunch of other changes and I don't want to commit un-compilable code or at least a non-working DarkRadiant version. Admittedly, this was not entirely the case in the light_center commit, but with some of the brush disentangling and such. I could have done better and I will keep this in mind in the future, the lesson is learned .

Ok, we've located the error: the bug appears first in revision 554, which is my commit concerning the draggable light_center. Revision 553 is working well. Which sucks, because commit 554 is large and there are quite some changes that cannot be disentangled easily. I'm afraid that I will have to re-do the whole thing until I know what change exactly is responsible for the mess. I will look into it tomorrow, as I have to leave now.

Still, leaving a user.xml in the local folders should not lead into a segfault. It's not really obvious too, as I check for empty strings before passing them to addAccelerator(). So I'm a bit lost why this could happen. However, I already added some debug possibilites into the EventManager class and I will commit them, they might come handy.

Hm, so far no crash. I will try to dump the output during the accelerator load process and see if there is something weird in it.

We're currently setting up the development tools on angua's notebook, so we can sweep over this twice as fast. Latest SVN is at revision 740, DarkRadiant 0.7.1 was around revision 546. So we're going to check if rev 546 works, and if yes, we will split the intervals in half and track down the bogus version.

Could you send me your user.xml and your input.xml to greebo@angua.at? I think this is related to loading the accelerators, as this is the only way the addAccelerator() method gets called.

I extended the AABB of the light, otherwise the selection test would never return something positive. Only visible lights are tested against selection. It may well be that these changes are responsible for this, although I have no idea why. I tend to do the following (after I resolved the other crash ): I will go back the SVN history in steps of, say 20 revisions and make some snapshot builds. Angua and me will go through this and narrow down the revision that is responsible for that crap.