Tels

The missing letters need to be "painted" on the texture for the menu font. And the font needs to have the coordinates for them. In addition, the http://wiki.thedarkmod.com/index.php?title=Font_Patchermust be used to make the font file have a correct coordinates for the new letters. The files for that should be on SVN (which I no longer can access).

The rules about the "notability header" are new, they didn't exist a few years back when the articles where written. I knew that, because I wrote many articles before the header was even invented. (And as far as I know, the notability header doesn't exist on the german wikipedia, yet.). It's good to know it's now fixed - until the next rule change comes along. And that's not a critism on you or TDM, but on the stupid rules of wikipedia. Edit: Btw, where exactly is this "notability header"? I cannot find it in the source code of the english article. Is this something that is stored elsewhere or goes into the talk page?

Well, so much for that idea I guess unified global logins are a master technology, that human kind hasn't invented yet... (that was sarcasm...

Yeah, my point was that the rules are ever changing and we almost lose the article once a year. First it was something about "has to be released", then "mentioned in a print magazine", then the mysterious header (of which I never knew until today) and next month its another insane rule that didn't exist a few days ago. The funny thing is, the german article was "automatically approved" back then, because I created it, and my account was a couple of years old and had thousands of edits. I guess nowadays even that wouldn't count (Fun fact: The article exists in 4 different languages. Each of these sub-wikis has it's own rules what is notable, and what not. TDM being notable in Germany doesn't count for English and vice versa...) The articles on wikipedia are quite old, but it's a constant pain to defending them from the deletionist. One of the reasons I stopped contributing there, it's just so much hassle without gaining anything but keeping the statue quo.

Just in case the link is missing from wikipedia: http://www.bloodgate.com/mirrors/tdm/pub/pcGamer_tdm.jpg

The Wikipedia "noteability" stuff is just insane. Our project exists since at least 2007, was release in 2009 and reviewed/printed in numerous magazines. And yet, somehow we are in danger of being "not noteable?" Edit: And the most insane thing is the same discussion seems to happen every damn year... end of edit. And to top the insanity off, they have "unified" all the usernames on the wikipedia different language pages. This means that now https://en.wikipedia.org/wiki/User:Tels~enwiki(formerly Tels) is mangled. How do I prove to them that it's the same account that it was before? The one surviving is the one in the german wikipedia... Forgot to add: I wrote parts of the english and german wikipedia TDM articles, but w/o the ability to login couldn't even find myself in the history. Damn meddlers...

I can see that Amazon want's just to avoid returns (it costs them) and by improving the shooping experience, they can do this better than by banning users. Their message sounds ok to me, especially the last one. I wouldn't get to upset about it. However, I too see the "cheap stuff from China, which is broken on arrival, never works, or is simple wrong in the first place". Stuff arrives dent, or has the wrong color (entirely red instead of red/black like on the image), light bulbs that are clear while being advertised as frosted etc etc. There is so much junk, missing information etc. that it is quite hard to buy just want you want. Clearly Amazon can improve here a lot.

Termintator-Thief: "I need your clothes, your boots and your horse." Pipe-smoking Rider: "You forgot to say please..." I guess wether the feature is shown in GUI, or with sound would be something that could be optional, either. Although a thief that catches his breath... might be funny if guards would hear it and comment on it. Guard Albert: "Huh, what was that?" Guard Betram: "What?" Alfred: "Did you hear that rasping sound?" Betram: "Must be the wind..."

I tend to disagree. It would add some resource that is limited (like oxygen under water) and needs proper resource planning by the thief. Some people would enjoy that feature Maybe if it can be optional. It's like "always run" in shooters. At first you only occasionally did run, nowadays everyone is sprinting at superfast speed through everything. IMHO the stealth genre is exactly the place where we'd want to dial that back and take the speed out of it once more and make players plan ahead. So the meter shouldn't be that sensitive that you can't cross the street without getting out of breath (you are a thief, after all), but it shouldn't be possible to bunnyhop for 10 minutes and then still jump and mantle up a wall like you just started the day. Edit: As for swimming: running etc would only ever take away 80% of the bar, and then you just slow down a bit. So you still have something left for swimming, but it's you fault (or desperation) if you spring 100m and then jump into the canal to swim to your freedom

It is 2015 and still almost every texture looks like wet plastic... except when it is blood on plastic, then it looks like glossy nail polish...

No you are not, this is the current thinking with software manufactures. LG pushed an update to my TV with a new data and privacy statement. I declined it, and they disabled all the apps on my TV. Ok, I didn't have any, but if I had any, even bought ones, they would have stopped working... It's the new "Nice software you have here, shame if something happened to it..." extortion er I mean business model.

First point: This wasn't a request, a sin() looks very close to a linear equation, and both are only approximations, anyway. I was just noting it and wondering if you couldn't simplify the equation in the function somehow. Second point: My RL practical experience seems to disagree with you (and your formula used for damping the sound when the angle is bent, too People are (sometimes a lot) harder to understand if they talk away from you - especially in loud environments. Also, not always is there a wall rightin front of the speaker. It's a bit like light - sure, it eventually bounces back to you, but a spot light shining away from you has a lot less power compared to shining in your face (unless you stand in front of a mirror, of course Sure, we can't simluate the full frequency, but making things a bit less loud would already improve the impression IMHO. Plus, you formula penalizes sound that goes through a, say, 90° angle. But if the AI speaks aways from a door, it is as loud as if it speeks directly through the same door. Compare this to the AI speaking at 90° to the door and it is suddenly less loud than the two other cases. Ideally, it would be dampened at 90° and even more at 180°, regardless on wether it is behind a visportal, or not. Otherwise, the player would also hear a difference between being right in front and right behind the visportal in the 90° case. (if player & AI in the same leaf => no sound reduction, if player steps through portal, suddenly the 90° are taken into account). So I'd say it would only be consistent if the first leg takes the angle into account, too. And that might improve localisation of AI a step. (I can do some drawings to illustrate my point, in case the descriptions above are not clear enough).

Looking at the code, it seems the current formula uses a linear intepolation between 0 and s_diffractionMax. Shouldn't that be some sin() or cos()? It probably does not make much of a difference in praxis, tho. And thanx for implementing it! One more question: Does the code take into account the direction the speaker/AI is facing? E.g. is an AI facing away from the player less loud than one facing the player? Or does the code simple take the full volume for the first leg in all cases? If so, that might be another cheap improvement - vary the volume by s_diffractionMax depending on the angle of "forward" vs. "direction of first leg".

Yes, but that still does "only" account for how the sound "sounds", but not where it comes from and how loud, which is what grayman spoke of. If you have a hallway with two open windows onto a yard and a guard walks along the hallway, you need to locate him without seeing him. If the sound system does not provide this accurately (or fake) enough, the impression of "the sound is wrong" is created. The same is f.i. with ligh. The moving shadows make it possible for a human to predict where the guard is, even if you don't see him. Is the shadow suddenly halting? Is it still moving? Moving backwards? I guess the sound problems are that the sound emitted by the guard (whistling, footsteps) is not equally 3D locatable as the shadow/light/visual stimuli, which leads to the odd "hm, this sounds wrong" sensation people have. Not playing with good headphones makes the problem worse, and not having EAX/EFX hall/reverb etc. effects also makes it worse. However, if the virtual speakers aren't computed properly, no headphones and EAX/EFX effects will save you.

I've returned home quite a bit later than anticipated Next weekend (25.9-27.9) I need to help a friend move, but the weekend after that I'd have time. Is there now a consens on location and/or date?

Is EAX/EFX really provide better 3D audio if the underlying computations of sound locations are not complete? I though it provides only effects (e.g. hall, reverb), looking at wikipedia I don't see how it would solve some of the issues. E.g. maybe EAX allows you to "dampen" the sound (simulating the reflection of it around a wall) and to delay it (simulating a longer path), but the computation of the sound source/location and multiple paths don't see to be part of EAX/EFX: https://en.wikipedia.org/wiki/Environmental_audio_extensions Basically, the audio engine would still need to have a primitive 3D mapping (which we simulate coarsely with visportals) to determine which sound can be heard from where, and EAX only provides a means to make the hardware manipulate the sound according to the current environment. At least that's how I understand it.

Technically, if you have f.i. 3 small windows, one would hear the same sound three times with different delays from each of the windows. If TDM only places one virtual speaker at the average position, you hear the sound only once. This difference might be in some occasions very noticable, as the delay (and frequency changes) are what humans are trained to notice. A test for that would be to place a walking AI behind some wall with openings and let him walk along and see if you can pinpoint his location by sound only, or if the location seems to jump or is unclear. With one average speaker, this might be more difficult to do than with three virtual speakers. (although I'm not sure if TDM does even simulate the delay for each virtual speaker? Is the sound always played without delay?) The same might be true for the typical "you are in a room and an AI walks by the open door" scenario. Without the "sound gets muffled by angle" adjustment, it might be hard to know what the AI is doing by listening only. Does he walk from left to right, or right to left? So, there are a few things that might be changed, roughly in order of difficulty: * the "muffle by angle" as you already noted (I fear frequency changes are out of our league, tho). This would mean the AI gets progressively louder as he walks to the door opening, and then gets less loud again. * delay the sound by distance (even small delays might be noticable). * represent multiple sound paths by multiple speakers, each one muffled and delayed accordingly We could also just re-used a 3D sound engine, if possible, but not sure if there is one available for free, and it's the same order of difficulty like "replace the physics engine".

Here is another case where an int gets assigned NULL instead of 0: Index: framework/Common.cpp =================================================================== --- framework/Common.cpp (revision 6532) +++ framework/Common.cpp (working copy) @@ -2626,7 +2626,7 @@ GetGameAPI = (GetGameAPI_t) Sys_DLL_GetProcAddress( gameDLL, "GetGameAPI" ); if ( !GetGameAPI ) { Sys_DLL_Unload( gameDLL ); - gameDLL = NULL; + gameDLL = 0; common->FatalError( "couldn't find game DLL API" ); return; } @@ -2651,7 +2651,7 @@ // Tels: The game DLL does its own check, and exits, so this check is probably never run. if ( gameExport.version != GAME_API_VERSION ) { Sys_DLL_Unload( gameDLL ); - gameDLL = NULL; + gameDLL = 0; common->FatalError( "wrong game DLL API version" ); return; } @@ -2683,7 +2683,7 @@ if ( gameDLL ) { Sys_DLL_Unload( gameDLL ); - gameDLL = NULL; + gameDLL = 0; } game = NULL; gameEdit = NULL;

There are a lot more oddities: /* =============== StringCRC =============== */ ID_INLINE unsigned int StringCRC( const char *str ) { unsigned int i, crc; const unsigned char *ptr; crc = 0; ptr = reinterpret_cast<const unsigned char*>(str); for ( i = 0; str[i]; i++ ) { crc ^= str[i] << (i & 3); } return crc; }Should ptr be used instead of str, or just removed?

I've looked into producing a better patch, will post this in a minute. But there are indeed some more troubling warnings from the compiler: sound/snd_emitter.cpp:181:15: warning: converting to non-pointer type ‘ALuint {aka unsigned int}’ from NULL [-Wconversion-null] openalSource = NULL; ^ sound/snd_system.cpp: In member function ‘virtual void idSoundSystemLocal::Shutdown()’: sound/snd_system.cpp:449:28: warning: converting to non-pointer type ‘ALuint {aka unsigned int}’ from NULL [-Wconversion-null] openalSources[i].handle = NULL; ^ sound/snd_system.cpp: In member function ‘ALuint idSoundSystemLocal::AllocOpenALSource(idSoundChannel*, bool, bool)’: sound/snd_system.cpp:1221:10: warning: converting to non-pointer type ‘ALuint {aka unsigned int}’ from NULL [-Wconversion-null] return NULL; ^ sound/snd_system.cpp: In member function ‘void idSoundSystemLocal::FreeOpenALSource(ALuint)’: sound/snd_system.cpp:1235:41: warning: converting to non-pointer type ‘ALuint {aka unsigned int}’ from NULL [-Wconversion-null] openalSources[i].chan->openalSource = NULL; ^ sound/snd_world.cpp: In member function ‘void idSoundWorldLocal::AddChannelContribution(idSoundEmitterLocal*, idSoundChannel*, int, int, float*)’: sound/snd_world.cpp:1923:53: warning: passing NULL to non-pointer argument 3 of ‘void alSourcei(ALuint, ALenum, ALint)’ [-Wconversion-null] alSourcei( chan->openalSource, AL_BUFFER, NULL ); Basically, openalSource is an integer, not a pointer. Setting it to NULL can't be right. Maybe it was supposed to be 0 instead? And: sound/snd_emitter.cpp: In member function ‘void idSlowChannel::GenerateSlowChannel(FracTime&, int, float*)’: sound/snd_emitter.cpp:1180:24: warning: variable ‘orgTime’ set but not used [-Wunused-but-set-variable] int i, neededSamples, orgTime, zeroedPos, count = 0; This patch removes orgTime (zeroedPos fills its role already): Index: sound/snd_emitter.cpp =================================================================== --- sound/snd_emitter.cpp (revision 6532) +++ sound/snd_emitter.cpp (working copy) @@ -1177,7 +1177,7 @@ void idSlowChannel::GenerateSlowChannel( FracTime& playPos, int sampleCount44k, float* finalBuffer ) { idSoundWorldLocal *sw = static_cast<idSoundWorldLocal*>( soundSystemLocal.GetPlayingSoundWorld() ); float in[MIXBUFFER_SAMPLES+3], out[MIXBUFFER_SAMPLES+3], *src, *spline, slowmoSpeed; - int i, neededSamples, orgTime, zeroedPos, count = 0; + int i, neededSamples, zeroedPos, count = 0; src = in + 2; spline = out + 2; @@ -1190,7 +1190,6 @@ } neededSamples = sampleCount44k * slowmoSpeed + 4; - orgTime = playPos.time; // get the channel's samples chan->GatherChannelSamples( playPos.time * 2, neededSamples, src );

Hm, I still think the area around cologne, bonn, koblenz would be better due to the cologne airport. Maybe we could do a list of people who could/want to attent and their locations, to see what the minimum travelling would be. If it is near me, I can offer accomodation, and getting 3 people from/to the airport or train station. If it is near Erfurt, I might be able to offer a lift for 3 people from the Cologne/Bonn area, but that depends a bit on the exact location and date. Also, end of september might be a bit cold for camping, what are the options for people to stay? I guess that it must be overnight, since people travel quite a few hours.

But if the list can be sorted by clicking the top headers, and one of them is "marked for download", then a single mouse click gives you the currently selected list. Also a "deselect all", "select all" button could help. With the seperate list and only a handful entries, this list needs to be made scrollable, which is a lot more work (than not having a second list SeriusToni: The programming of the GUI needs to be done partly in the GUI files, which specify what element goes where and what happens if you mouse over it or click it. The rest has to be done in C++, which specifies what happens when you click something. Having only one list is definitely easier. But programming time it costs in both cases.

Would it be possible to just mark the "selected for download" missions with a * or ✓? Then we wouldn't need two lists.

libx11-6:i386 is already installed here, so that can't be it.

Maybe this a small contained project one could tackle? Are there any specifications on what should be changed and how? Or is it more or less still at the "hm, it should be better" stage?