taaaki

Thanks

Attachments should work again. Also, I think I've resolved the 3 issues with the mobile version of the site (Full Version button didn't work, usernames on New Content view showing as "Array", and quotes not displaying correctly), but could someone please confirm for me.

It doesn't appear to like the # character. Looking at the web server config files now to see if I can resolve this.

Yeah, it's GPL. But it isn't all that straightforward to port the multi-threaded renderer over (and the other improvements). And there will likely be some issues with trying to rebase TDM onto BFG since the tools, etc. aren't there. So until a more "dev/mod friendly" branch is available with the tools and all, we might need to "watch this space". But there are people working on it (e.g. RBDOOM-3-BFG ) Edit: and people making some moves to port stuff from vanilla to BFG like nbohr1more stated above.

And the performance of the opensource driver isn't quite there yet. Just getting back to your issue hammadnadeemx, you probably don't need to go to the latest beta driver, so see if you can dial it back a version or two. Just so long as it's a newer version than the one you're currently using.

From the backtrace, it looks like the segfault is in the AMD driver (or at least that is where it is bubbling up from). My (very) brief google search didn't pick up any other reports of this though. I'm assuming that your packages are all up-to-date and that you've installed 32bit versions of the various X libraries (I'll have to check which ones are required when I get home from work) using the ":i386" suffix on the package name? Could you perhaps provide the output of 'dpkg -l' (maybe just dump it in a private pastebin and link here). Edit: actually, I found someone experiencing the same error as you: http://forums.x-plane.org/index.php?showtopic=75908&page=2&do=findComment&comment=817274 and it appears to be a driver bug. His next post indicates that the bug is fixed in a later version of the driver (see his next post here with the solution - http://forums.x-plane.org/index.php?showtopic=75908&page=2&do=findComment&comment=817285 ) Hope that helps

That's not really "running the entire codebase inside LLVM". clang is a C & C++ front-end for LLVM, which is just a compiler infrastructure. Using clang doesn't mean that your code runs inside a VM as the "VM" in LLVM might suggest. The resulting object files and executables are normal Windows / Linux / Mac executables, just like if MSVC or GCC was used as the compiler (although, the generated assembly code will likely be different due to different optimisations etc.) The benefit that clang brings is pretty hardcore code analysis and warnings. From what I've seen, performance of the resulting bin can be lower (or higher) than GCC depending on the nature of the code, so we'd have to evaluate that in the TDM case. clang also tends to compile much faster, so you don't sit around waiting for builds quite as long if you are making lots of small modifications followed by a new build each time.

Hi hammadnadeemx We're likely going to need a bit more info to diagnose this. What graphics card do you have (I assume that you're on laptop, so it will be one of the integrated options from Intel/Nvidia/AMD)? And are you using the proprietary/blob driver or the opensource driver for AMD/Nvidia (RadeonSI for AMD, Nouveau for Nvidia)? If you have 'gdb' installed, could you please give us the output of: gdb '/home/hammad/darkmod/thedarkmod.x86' run backtrace quit

Ah, I think I'm getting the right end of the stick now (yesterday was a bit of a long day, so I apologise for my lapse of braining). That shouldn't be too hard. It could likely just be added to missions.tdminfo or something.

Yeah, I saw that the latest LLVM had implemented some Windows/MSVC compatibility features. Definitely very useful for static analysis of the codebase. However, that's quite different to the earlier LLVM discussion where we'd likely end up replacing the current idCompiler/idLexer/idParser with a LLVM front-end and a suitable back-end.

Yeah, I'm not sure I follow either. I'm fairly certain that we only want to give the voting ability for a particular mission to people who've actually played said mission. And the exact method of uniquely identifying a player is the problem at hand here. Any other kind of system would be open to abuse and vote rigging (either to "trash" a mission or push one to the top of the ratings).

At first, I just want to get it working nicely and relieve some of bikerdude's mission admin headaches. I guess we can handle the renaming when we migrate the missions to the new db. Player ratings were discussed and we're keen to do it. I don't think that we settled on exactly how. We can pre-populate certain mission ratings based on the ratings from the forums threads, but it would be nice to allow players to rate a mission after playing it. But there are some issues with collecting player ratings like ensuring that each user only gets 1 vote, etc. (maybe try some SSO thing and link it to forum account). But yeah, I'm trying to make the system extensible enough to cater for these requirements.

I updated libcurl and changed from openssl to polarssl in 2.02, so I'd like to investigate if I broke anything with the in-game downloader. My testing didn't pick up any issues though. If you have any further info to help debug this (OS & version, 32bit/64bit, etc), I'd appreciate it. I'll also have a look at that mission you mentioned when I get some time.

I'm already building the updated backend for the mission db stuff (using SHA1 instead of MD5 but that's just an implementation detail). Lots of the mission db administration is fairly manual at the moment, so I'm trying to include some automation. The mission db admin should be able to upload a mission once, have the hash calculated automatically, and have the mission pushed out to the mirrors with one click. At the moment, there is no hash, the fm has to be manually uploaded to each mirror and then links added to the db one at a time. I also want the primary server to be able to check for mirror availability and toggle mirrors on and off if they are no longer accessible or have out of date missions (for whatever reason).

My initial interest is in the script interpreter to LLVM idea was more for improved error-checking and warnings and not so much on the performance side. Like I said, it isn't on my current todo list, so I haven't given it too much thought. So yeah, don't expect anything from me on this topic until after I've finished off some other stuff and have some time to think about it properly (assuming someone else doesn't take up the task).

Heh, that is actually an idea I had a while back (using LLVM for the script interpreter). I don't have any LLVM experience, but I do have a wee bit of (university) compiler development experience, so I was going to use this as a learning project. It's not on my current todo list though (which has been delayed trying to get a complete and correct SVN to Hg conversion going).

Just delete the Darkmod.cfg and it will be re-created from defaults the next time you run TDM.

modprobe is used to load kernel modules (like the _oss modules). I don't think snd_seq_oss is required (it was mentioned for Arch, but it doesn't seem to exist on my Debian system). After using modprobe, you should be able to see the oss modules that have been loaded by running: lsmod | grep _oss If that command gives you some output with snd_pcm_oss, chances are that /dev/dsp now exists and you should be able to use oss in TDM. I've shown what my Debian box does when loading these modules: # ls /dev | grep dsp <no output - dsp device doesn't exist> # lsmod | grep _oss <no output - oss not running> # modprobe snd_pcm_oss <no output - this is good> # modprobe snd_seq_oss FATAL: Module snd_seq_oss not found. <this probably doesn't matter> # lsmod | grep _oss snd_pcm_oss 28671 0 snd_mixer_oss 10461 1 snd_pcm_oss snd_pcm 47226 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd 34399 6 snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer # ls /dev | grep dsp adsp dsp That being said, it might be better to try and get native ALSA working as discussed in the thread I linked earlier.

I seem to recall being able to alt-tab in Linux if you open the in-game console (ctrl+alt+`) and then alt-tab. Will test it again a bit later. The crash on exit worries me a bit. There was a segfault on exit in 2.01 that was resolved (temp fix addressed the immediate issue - at least to my knowledge - see http://bugs.thedarkmod.com/view.php?id=3579) and confirmed as resolved by some of my test subjects. Are you able to provide the console log by any chance?

PulseAudio is meant to automagic your audio so you don't really have to worry about the details of ALSA, etc. If you remove the options that I said you should add to the config and just use PulseAudio, it shooould work (you will get sound), but there is a known issue with Doom3 and its variants (e.g. TDM) that results in delayed audio. The 'oss' trick is one workaround. Another option mentioned here: http://forums.thedarkmod.com/topic/12245-linux-launching-tdm-with-pasuspender/page__view__findpost__p__264879 Just regarding the oss workaround. From my recent experience with Arch Linux, it seems that recent versions of udev don't autoload the oss kernel modules at boot. Try this with the oss settings (with alsa-oss installed): modprobe snd_seq_oss modprobe snd_pcm_oss modprobe snd_mixer_oss

Hi Garrett Is this with TDM 2.01 or 2.02? Did you perhaps quicksave in 2.01 and then update to 2.02?

The dynamic libs that will need :i1386 versions are: > ldd thedarkmod.x86 linux-gate.so.1 => (0x00992000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x007a2000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x00831000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x00464000) libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0x00711000) libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0x00110000) libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0x00244000) libXxf86vm.so.1 => /usr/lib/i386-linux-gnu/libXxf86vm.so.1 (0x00efe000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x00256000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x0054a000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x0033b000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00993000) /lib/ld-linux.so.2 (0x00f0f000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0x00359000) libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0x00850000) libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0x0036f000) libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0x00373000) libcurl is statically linked now (and is itself statically linked to polarssl).

Yeah, don't expect anything for Serpentine on that front. Last time I spoke to him, he was a bit caught up in dose of "life", so he's pretty much dumped his side projects. I've been looking at doing the merge myself since it has to be done at some stage, and grayman and the rest of the active coders are working on the game side of things and renderer improvements (and it's probably best for them to stick to that). I can't really use Serp's old merge attempt since it wasn't in source control and back-patching recent changes into it would be a hassle. Unfortunately, the merge is going to take a while longer since the TDM+D3GPL merge was perhaps a bit premature and some of the changes (directory structure changes, etc., include paths, modified GPL header and SVN revision tracking) make a semi-automated merge quite difficult. And we are going to have to change the build system to CMake since I don't really feel like trying to get Scons scripts updated to work with the merged result (shouldn't be a problem for Windows since CMake can just spit out a Visual Studio project file). I'm currently working on some back-end improvements for things like mission db admin page and release process, but I should be able to get stuck in again soonish since I'm starting a new job next month closer to home and less hours a week (and more pay ), so I'll have more free time to work with.

And regarding this: I'm not seeing errors in the webserver logs and I've seen this happen with another one of the mirrors, so I'm starting to suspect that it has something to do with the updater. I'll have to check whether or not it has timeout and resume logic (if not, I'm sure that it's something that can be added).