taaaki

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

Another way to do the checks would be to actually have the updater client unpack each file in a Zip/PK4 and check if: a.) it is possible to even open the archive, b.) it is possible to extract the file and c.) the extracted CRC matches the CRC value stored in the archive (or do a running sum of extracted CRCs). The Python libraries allow you to extract in chunks to memory so temp files/dir hassles shouldn't be a problem. To some extent the updater already does this after it downloads a Zip file. But doing the full check for all files at the start of the update would probably take a very long time, so maybe make this an option like --deep-check. The main reason for going Python in my mind would be for the GUI stuff. Serps and I seem to have found a reasonably portable gui library for Python so I'm going to start experimenting with that soon.

I've been working on a Python replacement for tdm_update. At the moment it is more or less working the same as the Perl version except for differences with libraries such as the Python zipfile module. All I really need to do is sanitise zip member paths (the Python zipfile module doesn't really make this easy) and test the Windows batch file for restarting the updater. Then I need to test packaging with py2exe for Windows and Python Freeze for Loonix. If it all works out properly (ie. it behaves the same as the current updater in all circumstances), I can look at revamping the file checksum system to use SHA-1 instead. And maybe even look at throwing a GUI on top and supporting multiple download threads (if the mirror hosts have no objections). Edit: the Python rewrite was suggested to me by Serpentine because some people were having issues with Perl libraries on certain Linux distros. I'm not sure if those issues were sorted out using other means or if it really was Perl+distro causing the problem. Also, I needed a side project to keep me coding.

I've found that on certain maps (can't recall which), when you start the mission, there is a smallish number "2" where your currently selected weapon would be. This appears to increase the lightgem brightness until you switch to the blackjack or "put the current weapon away" (even though you don't have one selected). So this might be what you are referring to in 1.

Works properly now. You can delete takinator now. Thanks for all the help