OrbWeaver 709 Posted January 18, 2007 Report Share Posted January 18, 2007 I look forward to seeing the next Bonehoard iteration. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 131 Posted January 18, 2007 Author Report Share Posted January 18, 2007 I just received the DarkRadiant test mail you sent, in case you want to know . Quote Link to post Share on other sites
OrbWeaver 709 Posted January 19, 2007 Report Share Posted January 19, 2007 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? Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 131 Posted January 19, 2007 Author Report Share Posted January 19, 2007 No, I subscribed some months ago and never received any commit notifications. Quote Link to post Share on other sites
greebo 131 Posted January 21, 2007 Author Report Share Posted January 21, 2007 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. Quote Link to post Share on other sites
OrbWeaver 709 Posted January 21, 2007 Report Share Posted January 21, 2007 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. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 131 Posted January 21, 2007 Author Report Share Posted January 21, 2007 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? Quote Link to post Share on other sites
greebo 131 Posted January 21, 2007 Author Report Share Posted January 21, 2007 Resolved. The boost::filesystem method was throwing exceptions, which was a little unexpected for me. Quote Link to post Share on other sites
OrbWeaver 709 Posted January 21, 2007 Report Share Posted January 21, 2007 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. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 131 Posted January 21, 2007 Author Report Share Posted January 21, 2007 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. Quote Link to post Share on other sites
greebo 131 Posted January 21, 2007 Author Report Share Posted January 21, 2007 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... Quote Link to post Share on other sites
OrbWeaver 709 Posted January 21, 2007 Report Share Posted January 21, 2007 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. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 131 Posted January 21, 2007 Author Report Share Posted January 21, 2007 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. Quote Link to post Share on other sites
OrbWeaver 709 Posted January 21, 2007 Report Share Posted January 21, 2007 Compiles and runs fine. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
OrbWeaver 709 Posted January 21, 2007 Report Share Posted January 21, 2007 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. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 131 Posted January 21, 2007 Author Report Share Posted January 21, 2007 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. Quote Link to post Share on other sites
greebo 131 Posted January 23, 2007 Author Report Share Posted January 23, 2007 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? Quote Link to post Share on other sites
OrbWeaver 709 Posted January 23, 2007 Report Share Posted January 23, 2007 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. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 131 Posted January 23, 2007 Author Report Share Posted January 23, 2007 Off it goes then Quote Link to post Share on other sites
greebo 131 Posted January 24, 2007 Author Report Share Posted January 24, 2007 I moved the UndoSystem into its own module. One piece less in the main Radiant code... Quote Link to post Share on other sites
SneaksieDave 40 Posted January 26, 2007 Report Share Posted January 26, 2007 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. Quote Link to post Share on other sites
greebo 131 Posted January 26, 2007 Author Report Share Posted January 26, 2007 -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. Quote Link to post Share on other sites
sparhawk 17 Posted January 26, 2007 Report Share Posted January 26, 2007 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. Quote Gerhard Link to post Share on other sites
OrbWeaver 709 Posted January 26, 2007 Report Share Posted January 26, 2007 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. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
New Horizon 557 Posted January 26, 2007 Report Share Posted January 26, 2007 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. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.