taaaki
-
Posts
1020 -
Joined
-
Last visited
-
Days Won
8
Posts posted by taaaki
-
-
-
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.
-
BUT - I decided to try some more key bindings. I found that assigning the jump function to the / key will cause the run jump to work correctly - so it's not the keyboard after all unless they have some odd settings that just deal with the Spacebar key.Yeah.. you are talking about the Horrid " normally accepted" keyboard layout using WASD keys to walk plus the left ctrl key for your jump function. Horrid for me that is.. I hate having my hand on the left side of the keyboard, so i use the arrow keys plus the right shift key for Run.
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.
-
1
-
-
Um, don't run it like this: /home/ubuntu/darkmod/tdm_update.linux
I think the updater works off your PWD and not the executable path.
Do this instead:
cd /home/ubuntu/darkmod ./tdm_update.linux
-
That doesn't look like a complete download. Run the updater again to see if it still has stuff to download. Also, it mustn't be in a hidden folder. Just rename it to "darkmod" -> ~/darkmod/
-
I'm working on the "darkmod" folder issue at the moment. We didn't see it as a priority since the instructions were pretty clear, so it was left for 2.01. However, we didn't expect the massive demand and subsequent server downtime and creation of torrents. So yeah, we're aware of the issue and will rectify it as soon as possible.
-
1
-
-
What graphics card / OS?
Also, make sure that the folder you installed TDM into is named "darkmod" exactly like that.
-
I was able to get the list, queue a few downloads, and start them.
However, the Details.xml files are not available and the downloads are INSANELY slow.
Yeah, we've just got basic functionality going until we get past the initial surge. Hopefully we can start restoring the original site etc. soon. Also, like Bikerdude mentioned, you might just have landed with a slow mirror for that download.
-
Hey
When was the last time you tried the mission downloader? We've made a temporary plan with the servers that should allow the game to pull the mission list.
Regarding the quicksave issue, what path did you install Darkmod to? Make sure that you have it in a folder named "darkmod" as there are some limitations with the current filesystem implementation that prevent other directory names from working correctly.
Call for TDM 2.0 Mac builds
in TDM Tech Support
Posted
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?