Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

  • Replies 1.9k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Since I've stumbled over the same issue (and even tracked a needless bugreport), I've just commited the following:   Index: def/tdm_mover_base.def ===================================================

That's a pretty ambitious project that will require almost every trick in the book. I can sort of envision how you might use fences, skyboxes, and archways to assist with compartmentalization but over

I'd say it is perfectly doable if you make it almost planar, or with only mild height differences. The images below show how I would do it:   See how the mountains and houses always block the view f

Posted Images

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. :)

Link to post
Share on other sites

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.

Link to post
Share on other sites

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?

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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. :)

Link to post
Share on other sites

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?

Link to post
Share on other sites

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. :blush:

post-58-1169827572_thumb.jpg

Link to post
Share on other sites
-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. :blush:

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.

Link to post
Share on other sites
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.

Gerhard

Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...