taaaki

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.

What graphics card / OS? Also, make sure that the folder you installed TDM into is named "darkmod" exactly like that.

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.

Before going that route, try the in-game downloader again. We've configured an additional server to take on the load (hopefully). If it still doesn't work, you might just need to wait a bit longer for DNS to update.

Can you guys try using the in-game mission downloader now? It shoooould work.

Yeah, TDM is going to have issues running from a folder named anything other than "darkmod". I'm in the process of rectifying this, so hopefully we won't have this restriction with 2.01.

There ought to be a Darkmod.cfg file alongside your thedarkmod.x86 file. I think the config file is only generated if you change the config in some way (in-game).

I'm busy looking into fixing the downloader (tels has already logged an issue on the tracker: http://bugs.thedarkmod.com/view.php?id=3418)

I'll have a look at this since its likely something FS related that I overlooked.

I'm busy using the non-commercial license for Intel C++ Composer XE 2013 (includes C/C++ compiler, Amplifier [new name for VTune], Inspector and Advisor + all the performance and threading libs). You can get to it here: http://software.intel.com/en-us/non-commercial-software-development You can only use it for projects where you receive no income for your efforts. If you get the hang of the tools, they can be really useful (far better than many of the free tools). Amplifier/VTune is the profiler, Advisor looks for parallelisation opportunities and Inspector is used to detect memory and threading errors.

I'll have a look later this evening

Are you running thedarkmod.exe directly from the darkmod folder or are you using a shortcut?

Yep, it currently needs to run from ~/.doom3. However, I'm fairly certain that I implemented a fix to make sure that it crashes more gracefully if the 'fms' folder doesn't exist instead of the nasty Boost exception way.

The new engine shouldn't even know that doom3/saintlucia exists. EDIT: the only time that it would try and look for something in doom3/saintlucia is if +set fs_mod saintlucia was used, but fs_mod is currently read-only and hardcoded to "darkmod".

That is exactly what I want to achieve and what I was alluding to with the removal of fixed paths. This will be a lot cleaner for all Linux users once we go full standalone, but in the meanwhile, we may just have to rely on symlinks or manually setting fs_basepath.

You can ignore that (I forgot to suppress the warning before release). fs_mod is the new name for fs_game_base (i.e. the actual mod/game). I made it default to 'darkmod' and set it read-only so that we don't have to worry about it users running into issues if they change it for whatever reason. At some stage, when we are sufficiently happy that TDM is mature enough to support mods, we can unset the read-only flag on fs_mod.

You can also call the thedarkmod.x86 with +set fs_basepath . The symlink route should work as well. The problem you are experiencing is most likely due to us moving the executable into the "darkmod" folder instead of running through tdmlauncher. I'll have a look into the searchpath initialisation for Linux (I made some minor changes in the searchpath initialisation code to allow thedarkmod.x86 to run from darkmod/ but I didn't do extensive testing on Linux) and see if I can't make it more flexible. We are aware of the problem with the fixed paths in Linux (and there is an issue tracker entry related to this). It's targeted for 1.09 though, but if I get a bit of time, I will get this implemented sooner (and then we can probably release a mini patch for Linux). It isn't hard to remove the fixed paths, but we decided that we didn't want to tackle this right before the release of 1.08.

I think I have resolved this for JPEGs (in SVN). If you have SVN access, grab the latest revision and give it a spin. AluminumHaste: If you could provide me with the call stack when it crashes with PNGs, that would be great.

I quite like the idea of finely crafted accessories like compasses, eyepieces, small telescopes, watches, and other timepieces. I don't think it would be hard to identify such pieces as loot since they would typically look out of place amidst other plain belongings. They also contrast the typically clunky and large steam/electric technology. These would obviously be more common in wealthy areas, but such items can be dropped/misplaced and picked up by passers-by. I wouldn't know how to value them though (maybe between 1-3 gold).

serpentine: I have a Club3D Radeon HD5870 1GB DDR5 PCIe 2 x16 with reference HSF. Hope that helps. Also, m8, have you seen this: http://imgur.com/gallery/IV3KY

1. TBH, I don't really think this is a good idea and I don't agree with the statement. In my personal experiences, I've found first person to be far more natural than third person. In my opinion, third person feels too much like you are controlling a puppet using strings and ends up being "clunky". The player's model also obscures what is in front of you and the 3rd person view doesn't allow you to examine the environment as easily as first person where you can get up close and personal with everything. Third person works better in more action orientated, games such as Prince of Persia, where the details of the environment don't really matter. Whereas in TDM, you want to be able to search the room and find a key hidden under a flower pot. The zoomed perspective of third person wouldn't really suit this. It would probably also mess with the wonderful object frobbing/manipulation in TDM since your body would obscure the object. I've also found that the brain learns the dimensions of the player very quickly. Just take an example such as jumping from a ledge at the very last second to maximise the distance of your jump. I was terrible at this when I first played the training mission, but it took half an hour at most for me to get it right every attempt. 2. Multiplayer is a biiiig can of worms in a thief-like genre. Co-op: do you split loot/pickups or have a shared loot/pickups? saving and loading (do you allow it and if you do, how do you synchronise saves with minimal disruption to play)? It will get a bit frustrating if the other player is a dunce and keeps alerting the guards while you are trying to carefully sneak by a guard post undetected. It also affects the way mappers design their maps. Thief vs. guard: to me, TDM is a slow-paced game, so I would imagine this could get rather boring for either of the parties. 4. The mirror reflection does look a bit daft, but overall, this is a very minor complaint and I tend to just chuckle and move on.

Yeah, sorry about the lack of progress on this. I've been swamped with uni work and will probably only get time to implement all my extensions such as GUI and multiple thread downloading in December. I just want to integrate my improved zipfile handling (the Python Zipfile module is prone to directory traversal) and clean up some of my experiments. I'll finish that off this weekend and upload it somewhere. I can't guarantee that I've accurately translated all of the Perl die statements (ie. the updater may exit when it shouldn't etc.).