Itches, Glitches & Anything Else...

[OrbWeaver]

I look forward to seeing the next Bonehoard iteration.

[greebo]

I just received the DarkRadiant test mail you sent, in case you want to know .

[OrbWeaver]

Oh, that's interesting, I didn't get it and I don't get any of the SVN commit emails, so I wasn't sure if it was set up correctly.

 

Do you get SVN commit emails to that list?

[greebo]

No, I subscribed some months ago and never received any commit notifications.

[greebo]

Seems like I need some assistance here, as this is new to me:

 

I want to make use of the boost::filesystem libraries, but they obviously need to be compiled separately, as you did with the boost::regex library.

 

What is the best way to do this? I know that I could go through all the boost documentation and half the web to learn this, but maybe there is a faster way to learn it, because I don't want to spend the rest of the weekend doing just this.

[OrbWeaver]

I don't think that I had to compile the regex library myself, I think there is a precompiled Win32 binary available. Try downloading the .exe installer from here:

 

http://sourceforge.net/project/showfiles.php?group_id=7586

 

and see if it has the correct .lib inside it. If so, you should be able to drop it into the boost.w32/lib directory in the tree and then add it into the build scripts as an extra library.

 

However I could be wrong, and it may be that the library does have to be compiled. I have done this in the past, it is not all that difficult but I don't remember the exact steps unfortunately.

[greebo]

I needed to build the lib manually, and now it's linking successfully. But now DarkRadiant is crashing as soon as I access my boost::filesystem method.

 

Is it essential to build the library from the same boost version or are the headers identical?

[greebo]

Resolved. The boost::filesystem method was throwing exceptions, which was a little unexpected for me.

[OrbWeaver]

Is it essential to build the library from the same boost version or are the headers identical?

 

I don't know for sure, I would imagine that using the same version is generally a good idea though. You should also make sure you are using the right library subtype, since boost makes a series of different libraries IIRC (for multithreaded, singlethreaded, dynamic vs static etc.).

 

EDIT: never mind.

[greebo]

I'm stuck now with the exception when trying to create a boost::filesystem::path class out of the map filename:

boost::filesystem::path: invalid name "C:" in path: "C:/Games/Doom3/darkmod/maps/empty.map"

WTF? I guess I will have to do some further googling.

[greebo]

I could resolve this one as well. You have to instantiate the path class with the "native" name checker, otherwise the library refuses to recognise this path.

 

This boost library is not that convenient to use, I have to say, but I'm slowly getting there...

[OrbWeaver]

That does make some sense, it looks like the path object is designed to represent platform-independent paths, which means that windows-specific things like "C:" would not be valid.

 

It does make you wonder what the point is, when you have to use such things on Windows otherwise it cannot find the file.

[greebo]

I committed a new AutoSaver class and removed the old autosave.h/autosave.cpp files.

 

The libboost_filesystem-gcc-1_33_1.lib is now in the boost.w32 folder and I added the according useBoostFilesystem() method to Sconstruct. Could you check if this is compiling under Linux as well? I put boost_filesystem into the Linux part of Sconstruct, but I don't know if that's appropriate.

[OrbWeaver]

Compiles and runs fine.

[OrbWeaver]

I moved the constants and typedefs from AutoSave.h to AutoSave.cpp, along with the boost #include. It is preferential to keep the .h file as minimal as possible, to avoid lengthy compile times and excessive cascading includes (when one header includes another which includes another which includes another...). It also means you won't have to recompile so much if you want to change an implementation detail, such as a key name.

[greebo]

Ok, I thought I left them there to enable other files to use the key constants, so I don't have to define them twice and maintain duplicates. But I agree that they can be moved at that time as well, so I'm perfectly fine with the change.

 

I will keep that in mind.

[greebo]

What about the files radiant/glwidget.cpp & glwidget.h? The header file is empty and the stuff in glwidget.cpp appears to be not used anymore (I commented everything out and DarkRadiant is still running fine, it seems).

 

As I'm not very familiar with the GTK GL methods: is it safe to remove this / is this already replaced by other classes?

[OrbWeaver]

If it's not used and DarkRadiant runs fine without it, you might as well remove it completely. Perhaps this was a precursor to the gtkutil/glwidget.* code.

[greebo]

Off it goes then

[greebo]

I moved the UndoSystem into its own module. One piece less in the main Radiant code...

[SneaksieDave]

I don't know if I should be using this thread for this or not... in fact, in the immediate time surrounding a new drop, do we want every little possibly-misunderstood-but-possibly-a-problem thing to be tracked? Or would it be better to discuss them before formally tracking them? Anyway, the latter is what I'm assuming with this post at least for the moment.

 

A few unsures and possible problems I've run into in a little bit of checking out 0.8:

 

-can't seem to set game mode to darkmod; has this been made unnecessary? (i.e., darkmod is default, even if it says Doom3)

 

-cubic clipping; (1) is there a way to turn it off completely? (2) when I was seeking the on/off, I found Ctrl-- and Ctrl-+, but when I zoomed it all the way out with Ctrl--, it now seems stuck out there and won't come back.

 

-the camera mode constant (or was it RMB hold?) mouseview mode; I'm not sure, has that been implemented? No problem either way, I just thought it had been, but I'm getting a required toggle in and out of mouseview mode (the original method), and wondering if maybe I have to change a setting.

 

-a couple of assertions I'm trying to reproduce so far. One was after opening the texture tree and then trying to close DR. I don't remember the message. For the second (image below), I believe I had just switched out of render mode and maybe toggled out of mouseview as well at the same time. Trying to repro, sorry I wasn't paying closer attention, I wasn't explicitly looking for probs.

[greebo]

-can't seem to set game mode to darkmod; has this been made unnecessary? (i.e., darkmod is default, even if it says Doom3)

This is strange and should not happen. We haven't changed the fs_game handling. Hm.

 

-cubic clipping; (1) is there a way to turn it off completely? (2) when I was seeking the on/off, I found Ctrl-- and Ctrl-+, but when I zoomed it all the way out with Ctrl--, it now seems stuck out there and won't come back.

There should be a button in the top toolbar and there is an option in the preferences as well.

 

-the camera mode constant (or was it RMB hold?) mouseview mode; I'm not sure, has that been implemented? No problem either way, I just thought it had been, but I'm getting a required toggle in and out of mouseview mode (the original method), and wondering if maybe I have to change a setting.

RMB hold for camera movements has not been implemented yet.

 

-a couple of assertions I'm trying to reproduce so far. One was after opening the texture tree and then trying to close DR. I don't remember the message. For the second (image below), I believe I had just switched out of render mode and maybe toggled out of mouseview as well at the same time. Trying to repro, sorry I wasn't paying closer attention, I wasn't explicitly looking for probs.

Which version of DarkRadiant have you been using before? As a general trouble solver, I suggest renaming your local user.xml (the one in C:\Documents and Settings\blah\...) and restarting DarkRadiant.

[sparhawk]

I don't know if I should be using this thread for this or not... in fact, in the immediate time surrounding a new drop, do we want every little possibly-misunderstood-but-possibly-a-problem thing to be tracked? Or would it be better to discuss them before formally tracking them? Anyway, the latter is what I'm assuming with this post at least for the moment.

 

IMO when in doubt, we should post here and then we can still decide wether something needs to be tracked, or was just a user error.

[OrbWeaver]

I can confirm two defects:

 

* Activating mouselook with RMB, then switching between render modes, then right-clicking again gives an assertion failure ("free-move was already enabled"). This also messes up the mouse pointer -- I think there is a strong case for disabling the toggle mode and using a rightclick-drag mouselook that does not intercept mouse events.

* Browsing some textures in the media browser and then closing DR causes an "Orphaned shader still referenced" assertion.

 

I haven't had any problems with switching between mods however.

[New Horizon]

Just posted a bug in the bug tracker about the Entity inspector. I'm testing this under windows. Pressing 'N' only flashes the inspector briefly...you have to use the 'View' menu before it works.