taaaki

Well, it's probably a bit late now for pre-testing the update, but we'd like to know about any issues when running TDM 2.01 on Linux.

It's been a while since I've looked at the differences between doom3gpl and dhewm3, but the big ones are 64-bit builds, OpenAL improvements, move from MFC to SDL (more for the devs: I think this means that you can use the free version of Visual Studio without issues), and several other smaller fixes/improvements.

We may want to wait to see how this pans out before taking anything further: http://www.kitguru.net/channel/jon-martindale/valve-may-kill-off-greenlight/

Serpentine has had a few weeks of Internet trouble, which is why he has been rather quiet. He's still working on the dhewm3 merge, but he hit a snag with some renderer bug from the merge. Unfortunately, working on TDM takes a backseat when he has paying work (which I think he has quite a lot of at the moment). Don't worry, we'll get there eventually. If he says that he doesn't have any time to work on it, I might ask him to pass his current work my way so that I can look at finishing it.

The fact that it didn't automatically create the Darkmod.cfg file is a bit strange. Is there a "config.spec" file? Where is Darkmod currently installed? Stab in the dark here (don't even), but if it is in Program Files, you might run into issues with Windows UAC or whatever it was that causes issues with applications creating files directly to their application directory. If this is the case, maybe try moving it to something like C:\games\darkmod

GCC 4.8.2 is pretty new, so I suspect that other distros probably haven't updated to it just yet. Most of our release builds are done with Debian/Ubuntu, which are usually a bit behind.

The -m32 is needed since we have to target 32-bit bins. There is still some work required to get the source up to scratch for 64-bit builds. We're already moving away from project-provided libs to local OS shared libs, but there are local modifications to some of the libs, particularly the image libs, for compatibility with the D3 engine (and some of these "local copies" were brought in by Doom3 source).

Make sure that you are in TDM src directory and execute: % touch scons.signatures.dblite Then try again. If that doesn't work, then try: % scons -j2 BUILD_GAMEPAK=1 NO_GCH=1 BUILD=release --debug=explain "$@"

Patch applied and appears to do the job. Thanks Zbyl

Regarding the 3rd party libs: yes. If all goes well with the branch that serpentine is working on, it should be possible to support native 64-bit builds, which should make that less of an issue.

Open the console ( ~ key ) and type 'condump yourfilename.txt' and then provide the content of the dump here. The most likely culprit is a lack of s3tc (we use texture compression) support. What graphics card do you have and which driver are you using? Also, this thread might help: opensuse forums

Are you able to generate patch files for review and inclusion in the tdm svn?

Nice work. Given your feedback above, is there anything I can do from a path perspective that will make this just a simple case of having someone with a Mac to compile the binaries or is it already like that?

Done http://bugs.thedarkmod.com/view.php?id=3599

Well, I'm hoping to resolve the lack of SSL support in CURL before the next release. If I can do that, I will add your workaround. Anyway, thanks for all your efforts I'll need to ask for more details regarding the current mission db system to see what can be done to add better hash support etc. I'm not sure if versioning is actually required since we can assume that the hash supplied by the mission db is always the latest one (in theory).

Merged the supplied code minus the pieces of code that would exclude https links. I'd rather fix the https problem with the downloader than just avoid it. Also busy adding an extra legend ("# Translation") to the mission downloader gui just below "* Update". Will commit code and gui + strings updates when I am done. Edit: on the topic of the mission hashes, etc., I think a bit more work can be done on the mission database to make this easier. Ideally, it would be nice if there was an interface to submit a mission (or an update of a mission), have the mission submission page calculate a SHA256 hash and include the hash in the mission details db so that clients can easily compare the local hash to the one provided by the master server (remember that the mission db is only provided by one server, while the actual mission packages themselves may be distributed).

I guess I can have a look when I get home from work.

I'm not really that clued up regarding the OS X path setup routines, but you might have to change the Default*Path methods to be more in line with the Linux ones. I don't really know much/anything about OS X path conventions, but if you can give me a primer, I will try to fix the paths for MacOS as best I can.

You don't need Doom3 at all since TDM 2.0 is completely standalone. You can move the "darkmod" directory anywhere you want provided it is still named "darkmod". Since you snipped most of the GL_ info from the console dump, it's hard to tell for certain, but you will likely need to install and enable s3tc support. I assume that the lib you mention above provides that, so you should be good to go after that.

Hi amisch, Details regarding your PC would be helpful. Could you please provide your system specs and what OS you are running (Linux - what distro, Windows - which version, 32bit/64bit)? Hopefully we can get the bottom of the issue and get you playing

If you are able to provide the console output (condump filename.txt) after running the path command, I'd appreciate it.

The key ghosting effect (where one or more keys don't register when multiple keys are pressed) is more to do with the keyboard matrix (but the interface type, USB/PS2 does place additional restrictions). So it could very well be that your particular keyboard(s) aren't designed in such a way as to allow your preferred run-jump key combo. When you talk about ~gaming~ devices like gaming keyboards, they will usually implement some form of anti-ghosting by optimising the key matrix around common key combos. Unfortunately for you, this usually means the WASD cluster. You would probably need full keyboard anti-ghosting/NKRO. Mechanical keyboards are typically better at this.

(or replace Apache with nginx and see if it tanks the traffic any better - CloudFlare uses nginx as far as I am aware, so that's a pretty good endorsement in my eyes)

No worries. We'd rather have these issues out in the open than having people hit these snags, get frustrated and subsequently dismiss TDM without giving us the opportunity to fix the the issue(s). One of the other team members is taking a stab at merging TDM with the dhewm3 codebase, which should then allow x64 build targets. If this is successful, issues like this will hopefully be resolved (for amd64/x64 hosts at least).

Just looking at the VS project, the "Game" project that generates gamex86.dll is set to compile with "Enable Large Addresses: Yes (/LARGEADDRESSAWARE)"