Itches, Glitches & Anything Else...

[greebo]

@New Horizon: I'm about to commit some changes, please try again in a minute. Don't know if that resolves the crash though, but it's worth a try. If that doesn't help, try wiping your local user settings, the preference system is being completely overhauled, maybe there is some old setting causing the crash.

 

@OrbWeaver: I've hit some POSIX-specific code again in qe3.cpp. Does it compile under your Linux or did I miss something again?

[New Horizon]

Nope same error. Wiped my user settings and did a clean checkout. Still getting the same error as I posted on the last page. Something about line 253. Weird.

[greebo]

That's a NULL pointer assertion, I'll have to look at that. You get this right after a fresh start? No splash screen, nothing?

 

I'll be away for a few hours for Volleyball now, I'll check back later.

[New Horizon]

Just double checked, I'm getting it almost immediately after the splash screen appears. Pretty snappy.

[OrbWeaver]

It works, but I keep getting a "Directory does not exist" error when I select "darkmod" as the game. I suspect this is because the mod is not installed in /usr/local/games/doom3/darkmod but in ~/.doom3/darkmod

[greebo]

Hm, isn't the mod supposed to be located under the doom3 base folder /usr/local/games/doom3? I'll have to check the code, as I assume that it worked fine before.

 

edit: ah, got the error.

[OrbWeaver]

Hm, isn't the mod supposed to be located under the doom3 base folder /usr/local/games/doom3? I'll have to check the code, as I assume that it worked fine before.

 

No, in Linux you can put the mod in your local directory. This is a huge plus, because you have write access here and can sync with SVN without needing to use sudo.

 

The actual resources are fine, it is just that new dialog which doesn't pick up the local copy.

[greebo]

These paths seriously need some organisation, it's really a mess. Currently we have:

• the application path
  
• the settings path
  
• the home path
  
• the maps path
  
• the bitmaps path
  
• the engine path
  
• the user engine path (for *nix)
  
• the basegame path
  
• the usergame path
  

I realised too late that Linux is doing something completely different here, so I'll have to redesign the initial dialog along with the check. Either that or I drop the check completely, but this shifts the responsibility to the user.

 

At least I have the possibility to define a standard "fs_game" in the user.xml file now, which will make the next release easier for people to setup. Only the engine path is required, the rest can be predefined/derived.

[greebo]

OrbWeaver: How's the folder structure organised in Linux? I know that there is a ~/.doom3/dakmod folder in your home directory and the engine is located at /usr/local/games/doom3/.

 

Where is the base game located? Is it at /usr/local/games/doom3/base or is there a base folder in your home path at ~/.doom3/base as well? Or both?

 

edit: Anyways, I tried to mimic the legacy code as good as I could, it should be resolved now. Could you give it a shot, Orbweaver? You probably have to rename/wipe your settings to test the initial startup stuff.

[OrbWeaver]

It seems to work OK for me, at least I don't get the error message any more.

 

Basically you have to merge the contents of ~/.doom3 and /usr/local/games/doom3 as if they were one large directory. You can put a file in either one and it should show up in the VFS.

[greebo]

That should be ok then. DarkRadiant's VFS is/was setup to search both paths (the ~/.doom3/ one and the /usr/local/games/doom3 one, which are identical on Win32), although it does not search the whole tree, but the ./base and ./ folders relative to that.

 

Obviously it's possible to place assets in four different folders in POSIX-based systems, DarkRadiant should find them.

 

The search order is as follows (just for the record here, I already added an empty Wiki article for that):

 

- user engine game path (aka modpath) (~/.doom3/darkmod)

- engine game path (/usr/local/games/doom3/darkmod)

- user engine base path (~/.doom3/base)

- engine base path (/usr/local/games/doom3/base)

 

I forgot to search the second for POSIX-systems in the last commit, but that's already fixed in latest SVN. The first two are searched only if the fs_game string is not empty. Quite a hassle to get this right for both systems, if you ask me.

[greebo]

Ok, after this little Odyssey it's time to post here what I've done:

• The Preference Dialog has been rewritten and can be populated using a path-like key like the MenuManager. This way it's possible to add settings to existing preference pages from different places in the code. Search for PreferencesPagePtr in the code to see an example of how this can work.
  
• The Game handling is completely new and replaced a bunch of globals and other stuff. The game is auto-selected if only one .game file is available. "darkmod" is the default value for the fs_game to avoid confusion at initial startups.
  
• All preference settings have been migrated to use the XMLRegistry.
  
• The old xml-parser/writer stuff used by the PreferenceDictionary is gone, and the preferencesystem.h interface is cleaned up. No more StringImportCallers or other callbacks, just registry keys. The PreferencePages are allocated using boost::shared_ptrs.
  
• The GroupDialog has been refactored in the same sweep, because the window position relied on the old system.
  
• The "regular" and "regular left" window layouts have been tidied and are using the registry as well to save their settings.
  
• The ProjectSettings dialog has been replaced by the new PreferenceDialog (which can be used as modal or non-modal dialog, btw.)
  
• The IRadiant interface has been cleaned from all unnecessary stuff like getGameMode() etc.
  
• The global.pref/local.pref preference files are no longer necessary, which leaves the settings path a bit cleaner (just the radiant.log and the XML files).
  
• Removed over 20 occurrences of CopiedStrings.
  

and a bit of cleanup here and there. The code should be smaller and cleaner now.

 

@New Horizon: Can you try once again, if a fresh build with a wiped user settings folder still crashes? If it still persists, we're gonna hunt that one down.

[greebo]

Orbweaver, is the texture preview combo in the Media Browser showing up correctly on your end? It doesn't on mine, but the light browser and the find&replace shader selectors are working.

[OrbWeaver]

No, the preview is blank (the text information seems OK).

[greebo]

Hm, I could swear it was working after introducing the ShaderChooser/ShaderSelector stuff. I'll see what may be the cause here.

[greebo]

Fixed. I don't know exactly what it was, perhaps the GL viewport. I copied over the code from the ShaderSelector and adapted it, should work now.

[OrbWeaver]

I notice that the sizing info lines appear when you select more than one entity, measuring the Manhattan-distance between the two origins. Is this intentional? I can't imagine this would be all that useful, and it does look a bit odd.

[greebo]

No, not intentional. Should I remove it?

[OrbWeaver]

No, not intentional. Should I remove it?

 

If it wouldn't be too much work, I suggest it is removed. I think this would only serve as a source of confusion.

 

In trying to determine what happens when an RXGB DDS file is loaded, I have noticed a couple of design problems with the DefaultConstructor functionality:

 

1. It inherits both TextureConstructor and ImageConstructor which are identical interfaces defined in different files (iimage.h and ishaders.h). I am not entirely sure what happens when you define a virtual method which exists identically on more than one parent class, but whether or not this is defined behaviour it isn't good practice to have identical interfaces like this (duplicate code + confusion).

2. Each DefaultConstructor has its own ImageLoaderModulesRef. This means that each of the image loader modules is instantiated and released for EVERY DefaultConstructor used (check the Radiant Console to see how much this happens when you load a large map). I tried to fix this quickly by adding a static method to return a singleton instance of the ModulesRef, but this only partially worked so this may need deeper investigation.

[greebo]

I'll have to look into the Constructor inheritances again, I don't remember exactly if one of these isn't a legacy inheritance that could be removed. I noticed the problem with the module load/release as well, and I meant to report it but I eventually forgot.

 

Btw: I went through a clean install of my machine today and I had a chance to complete the DarkRadiant Compile Guide on the Wiki. It should be complete now.

[greebo]

OrbWeaver, how far are is the objectives editor from completion? I'm very close to finishing the S/R editor, so maybe we can start thinking about the next release? (As people are getting curious and my number of posts like "it's fixed in the development version" is increasing steadily )

[OrbWeaver]

Given our respective rates of work, I suspect the S/R editor will be completed long before the Objectives Editor, so I suggest we can release 0.9.0 with just the S/R editor (that was actually my original plan anyway -- 0.9.0 needs ONE of the new DarkMod editors but not necessarily both) at this stage.

[greebo]

Ok, I'll finish my piece and switch to bugfix mode till the weekend. It will be nice to get feedback about the S/R system, given that beta mappers will be able to download the latest mod version from SVN as well.

 

It's likely anyways that we will have to push out a bugfix release 0.9.1 short time afterwards as we had to with the 0.8.0 release.

[sparhawk]

I downloaded the latest version to take a look at the S&R which definitely looks nice. But it seems that DR got a bit of Alzheimer since it became older now. It always forgets where my Doom 3 location is and asks me everytime I run it, giving me the default path.

[greebo]

That's probably because of your user.xml. Please send it to greebo@angua.at so that I can make sure that your configuration gets correctly updated, as others are likely to have a similar one.