taaaki

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)"

I pretty much agree with you on this. There were some non-apparent quirks with the way the filesystem is used in the game that caused some issues along the way when we were going standalone and shifting where the game bin was executed from. I can't recall off the top of my head what they were exactly, but I meant to go through all the usages of the FileSystem functions and check them for sanity to try and resolve them at the root cause. I got part of the way through that exercise but ran into a situation where I didn't have time to work on TDM for quite a while. Now that I've got some time in the evenings, I'll be working on this and trying to further simplify the FS usage in the various parts of the game. Maybe even for 2.01 If you're interested, the background behind this can be found here: http://bugs.thedarkmod.com/view.php?id=2966

Rename your TDM directory to "darkmod". This is fixed in the source now, so it should be ready for release in 2.01 whenever that is. But for now, you're going to need to rename it.

I don't recall r_mode having anything to do with sound (r_ refers to renderer settings)? What hardware are you running on and which distro+version?

He shoots .... he scores! Could you (or one of the forum mods) please update the title of thread and add [solved]

Do you have the ia32-libs package installed? Also, you can try: #apt-get install libxxf86vm1:i386 If that doesn't help, could you please provide the output of: # ls /usr/lib/i386-linux-gnu/libXx*

I am currently responsible for most of the filesystem related issues in TDM (so yes, you can probably blame me for this and the hardcoded "darkmod" thing - which is being worked on - slowly). Regarding the games file/path handling: the path system is a bit convoluted, but it has been simplified a bit compared to the original Doom3 code (we've stripped out CD Paths and tried to centralise certain things like screenshots). I'd also like to say that the filesystem can be fragile at times since it has to cope with differing uses cases between normal play and the workflows used by mappers for building missions and then release testing them (I've broken things in the past, so I know how annoyed people get - dmap can be a bit sensitive). We explicitly moved all the files into a single directory structure to assist with moving away from Doom3 (which had settings in ~/.doom3/ and game files /opt/doom3 or /usr/local/games/doom3). There are also a few team members who like the fact that everything is in one directory and can be relocated easily. Now that we don't have to drag around the D3 baggage (and can essentially run the TDM bin from anywhere), we may look at adhering to the norms from a Windows and Linux directory structure perspective. But this will need to be discussed by the team as it complicates the updater and various other functions within the game. An example would be the missions. Where should these be stored? They're essentially part of the game files (once downloaded) and should be shared between users, but they're also dynamic in a sense, so one can argue that they belong in the user's homedir (along with their associated saves and such). I also don't think that this is a priority from our side, but if enough users take issue with the current structure, we can probably address it sooner. The other point is that I'm even sure that the team is interested in having installer packages for Windows or Linux distros. My opinion is that this may lead to support issues for the (small) team if the package maintainers for different distros don't keep up or go AWOL and we are stuck trying assist users with outdated packages.