View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002266 | FSSCP | sound | public | 2010-07-19 18:29 | 2012-08-16 05:19 |
Reporter | chief1983 | Assigned To | iss_mneur | ||
Priority | normal | Severity | major | Reproducibility | random |
Status | resolved | Resolution | open | ||
Product Version | 3.6.13 | ||||
Target Version | 3.6.14 | ||||
Summary | 0002266: In new OpenAL code, dense soundscapes cause sounds to intermittently not play. | ||||
Description | I have heard from both Diaspora and FotG developers of instances in which sounds will not play during intense action and lots of sounds. Shade mentioned that flak sounds were not audible periodically when right next to the source, and zookeeper mentioned that his own primaries failed to make sounds when testing some FotG capital ships. | ||||
Tags | No tags attached. | ||||
|
I have this problem on 3.6.12 RC3. (Not sure why 3.6.13 is a reporting option if 3.6.12 isn't even technically released yet, but whatever.) The bug affects game sounds of all types (primary sounds, missile launches, capital ship weapons fire of all varieties, afterburners, and even voice acting lines). This happens across all mods since I moved from RC2 to RC3, and is not specific to any given one. Sometimes when a VA line doesn't play it just produces silence and sometimes Microsoft Sam will take over the line. Occasionally the line won't start at the beginning, but the voice will cut in halfway through it. |
|
RP, it's because there are now nightly builds released that have the fresh new OpenAL code, and if people are reporting bugs in that code they need a proper option. Trunk builds are currently tagged as 3.6.13 as they're development builds for the next stable release after 3.6.12. |
|
Please attempt to reproduce this bug with OpenALSoft and/or -no_3d_sound flag enabled so that we can rule out this being caused by sound hardware that is lying or unable to handle the number of concurrent sounds required. |
|
Even if it is because there are too many sounds required, shouldn't there be a stacking based on relevance, such that sounds emitting from the player's ship, or very nearby it, or very loud sounds would take precedence? And I will admit, OpenAL soft does fix a lot of the issues, but I can't figure out how to use it on my Mac. Having to turn off 3d sound altogether to get any decent sound is kind of annoying. I'm open to suggestions on how to use OpenAL Soft on OS X. |
|
That's the thing. FSO already does that and for most people it seems to work just fine. The problem appears to be that the number of sounds that the sound card can actually process at one time appears to be smaller than the number that FSO thinks the sound card has (which IIRC is queried by FSO when it starts up) this results in the sounds just disappearing when FSO starts using audio channels that the sound card can't use/doesn't have. As far as OpenAL Soft for OS X goes. According to [1] you simply need to download and build the source available from [2] and make it available. Unfortunately I do not have a Mac to test this with. [1] http://code.google.com/p/naev/issues/detail?id=131 [2] http://kcat.strangesoft.net/openal.html |
|
I have built OpenAL Soft, but I can't figure out if it's supposed to work like a drop in replacement somehow like on Windows, or if you have to build the app against it, as it seems the NAEV link above suggests doing. Nothing I have much time to fiddle with right now at least, unless I somehow find myself bored at work again. |
|
From OpenAL Soft's CMakeLists.txt, it looks like you can build a static library by passing -DLIBTYPE=STATIC when you run CMake; that is, the command becomes "cmake -DLIBTYPE=STATIC .." . I've tried this and after running make, a static library (libopenal.a) is generated instead of a .dylib, along with two executables, makehrtf and openal-info. Hope this helps. |
|
Replying to what chief1983 said, my impression is that there's no (straightforward) way to build an OS X Framework from the OpenAL Soft tarball, so we'd probably have to build FSO against the OpenAL Soft library. |
|
Update: after some tinkering with FSO's Xcode 3 project to use libopenal.a instead of OpenAL.framework and also adding -DCMAKE_C_FLAGS=-m32 when running CMake with OpenAL Soft (to force the generated code to be i386 instead of the native x86_64), I now have an FSO build that uses OpenAL Soft instead of Apple's OpenAL, as confirmed in a debug log (see attached logs). It's currently just tied to my local copy of libopenal.a and also it's just i386 with the 10.7 SDK, since I couldn't get the OpenAL Soft build system to use an earlier SDK, let alone generate a PPC build (might not be possible on Lion, even with Xcode 3, dunno). It's a start, though. One odd thing about the build is that when you run it, neither the Dock nor OS X's top menu bar disappears. Not sure how to fix that. Sound plays fine, though. I played partway through a retail mission ("A Lion At The Door") without mods and didn't run into any problems other than the ones mentioned. |
|
|
|
|
|
Try the below link for an RC6 build using OpenAL Soft. I don't notice any degradation, but I haven't tested it to strenuously. https://www.box.com/s/fa9e3d8a1696879ec436 |
|
Played with this for a while today and didn't notice any issues. |
|
|
|
I have added a mission to this ticket that provides a dense soundscape that exhibits this bug. I have also tested different builds with this mission and ... I dunno. With the OpenALSoft build, there is a loud drone that builds as I approach the ships and it fades as I fly away. With the number of sounds that the test mission puts out there, the player gun occasionally makes a sound (where as with trunk the player weapon never makes a sound when you fly though). This drone does not happen with the regular RC6 build, though I am not sure if this is intentional or not. The drone sounds like 100's of guns firing (and it reinforces the danger of flying between two Orions and 4 Aeolus. Can someone confirm or deny these findings? |
|
I know I'm running Linux, which is a bit different, but I thought it might be useful to add what my testing has shown. Firstly, I think that Linux always uses OpenAL Soft, i.e. from fs2_open.log Initializing OpenAL... OpenAL Vendor : OpenAL Community OpenAL Renderer : OpenAL Soft OpenAL Version : 1.1 ALSOFT 1.13 Also, there's an oalsoft-conf utility available, which I've used to set the playback device to "PulseAudio" rather than the default of "ALSA" - doing this stopped a lot of warning messages (from OpenALSoft) appearing when running fs2_open. As for testing with the provided mission: 1) there doesn't appear to be any different between trunk & 3.6.14 RC6 2) without -no_3d_sound a lot of sound gets lost. Even without firing primaries many of the flak bursts do not play, and those that do play seem truncated. 3) with -no_3d_sound fewer sounds get lost. The flak is much clearer all the time, although when you're in the densest part of the flak bath the Subach firing sound plays intermittently. All this is playing on headphones via my SB Audigy, I've got an onboard Nvidia device as well that I'm going to work out how to enable and run some tests with (as well as that GF106 device - whatever that is... I don't have headphones with a HDMI plug though!) Lastly, I've also been experimenting with changing the selected playback/capture devices however none of the different choices have made any difference. FYI - my available choices currently are as follows (as reported in fs2_open.log) Available Playback Devices: GF106 High Definition Audio Controller Digital Stereo (HDMI) via PulseAudio *preferred* ALSA Default *default* HDA NVidia [HDMI 0] (hw:0,3) via ALSA HDA NVidia [HDMI 0] (hw:0,7) via ALSA HDA NVidia [HDMI 0] (hw:0,8) via ALSA HDA NVidia [HDMI 0] (hw:0,9) via ALSA SB Audigy 1 [SB0090] [ADC Capture/Standard PCM Playback] (hw:1,0) via ALSA SB Audigy 1 [SB0090] [Multichannel Capture/PT Playback] (hw:1,2) via ALSA SB Audigy 1 [SB0090] [Multichannel Playback] (hw:1,3) via ALSA PulseAudio Default SB Audigy Analogue Stereo via PulseAudio Edit: removed comments re: wxlauncher - I was running an older version |
|
I've done some more testing with my onboard sound card, a "Realtek ALC892". OS says: 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (oops - I was wrong when I said Nvidia device above...) Anyway - with the following device (Built-in Audio Analogue Stereo via PulseAudio) selected in wxlauncher I get the following: 1) without -no_3d_sound - I get a crackling/popping when loud sounds play like beams / flak bursts. Primaries stop playing intermittently in the middle of the flak 2) with -no_3d_sound - pretty much the same as 1) When I switch wxlauncher over to this device (HDA ATI SB [ALC892 Analog] (hw:0,0) via ALSA), my results are pretty much the same as for when using my SB Audigy as per my previous post (points 2 & 3) Both these results are using 3.6.14 RC6. |
|
Errr.. maybe this is silly, but I bumped MAX_CHANNELS to 256 to match my default configuration of OpenAL Soft, and voila, no more sound-not-playing issues. Do any Windows OpenAL-Soft users have the following config file available? %AppData%\alsoft.ini If so - is there a line like the following, and what is its value? sources = 256 |
|
Here's what I have so far using the test mission: 3.6.14 RC6 using Apple's OpenAL and my version of trunk with OpenAL Soft sound about the same on the test mission. While continuously firing the Subach, there's maybe a few gun sounds while in/near the ring, but it's mostly silent gunfire in that area. I haven't checked the flak or beam sounds, and TBH I'm not entirely sure I remember what flak is supposed to sound like. As for niffiwan's last comment, I found the alsoftrc.sample config file in the OAL Soft source tarball and copied it to my home dir as described in the file, using "sources = 256". I tried bumping MAX_CHANNELS in the code to 256, but then I got that drone sound that iss_mneur described. I then tried adjusting MIN_SAMPLES to 272 (or 256+16, since the original value of MIN_SAMPLES was a hardcoded version of MAX_CHANNELS+16) and still got the droning sound, so loud in both cases that I couldn't hear whether the gunfire sound was playing. More importantly, FSO hangs and then eventually CTDs (wxL says it returned -1) whenever I try to exit this mission or jump out. I can produce a debug log and attach it to the ticket if you want. Just would like to add that I'd especially like to hear from chief or E9 on whether their test results are similar to mine and whether they can reproduce the hang+CTD. |
|
I've been trying to reproduce the drone noise but I can't manage it so far. I've tried using OpenAL Soft 1.14 as a dynamic lib and as a static lib (with & without MAX_CHANNELS 256) - it doesn't seem to make any difference from 1.13 (except for some messages like this "AL lib: alcOpenDevice: Option 'format' is deprecated, please use 'channels' and 'sample-type'"). I recorded a sample of me playing the mission through - I recorded this using the features in OpenAL soft - i.e. set these parameters in ~/.alsoftrc (or %AppData%\alsoft.ini) drivers = wave [wave] file = /tmp/testfileoutput.wav Recording is here: http://www.mediafire.com/download.php?yl48wgo1gdcxynl Does this sound like the drone you're talking about? It's not as clear as it is in game, but it's fairly close - the Subach firing sound is playing the whole way through, it's just hard to hear. FYI - the flak sounds can be found in sparky_fs2.vp, data/sounds/: 8b22k/FlakLaunch.wav 16b11k/boom_4.wav Lastly - and on a slightly different topic, I don't believe that the code to detect the number of available channels is working properly. I tried setting my "sources" in .alsoftrc to 16, but FSO started happily without any warnings. The sound in the test mission was woeful of course. Looking at the code, it seems to just open a single channel and then close it straight away, it does this 48 times for each sound device. I've created a patch (vs 3.6.14, NOT trunk) which I think will fix this detection. Obviously, this will now disable sound completely if FSO can't find any devices that support at least 48 channels. What are your thoughts on this? |
|
mantis2266-channel-detection.patch (1,073 bytes)
Index: code/sound/openal.cpp =================================================================== --- code/sound/openal.cpp (revision 8970) +++ code/sound/openal.cpp (working copy) @@ -197,19 +197,21 @@ static void find_playback_device() // check how many sources we can create static const int MIN_SOURCES = 48; // MAX_CHANNELS + 16 spare int si = 0; + ALuint source_id[MIN_SOURCES] = {0}; - for (si = 0; si < MIN_SOURCES; si++) { - ALuint source_id = 0; - alGenSources(1, &source_id); + for (si = 1; si <= MIN_SOURCES; si++) { + alGenSources(si, &source_id[0]); - if (alGetError() != AL_NO_ERROR) { + const char *error_text = openal_error_string(0); + if ( error_text != NULL ) { + mprintf(("OpenAL error \"%s\" when creating %i sources with device: %s\n",error_text,si,pdev->device_name.c_str())); break; } - alDeleteSources(1, &source_id); + alDeleteSources(si, &source_id[0]); } - if (si == MIN_SOURCES) { + if (si == MIN_SOURCES+1) { // ok, it supports our minimum requirements pdev->usable = true; |
|
Thank you niffiwan for your experimentation. It did help. New patch with a new build that fixes the problem by restoring the behaviour of the sound code to that of 3.6.10. So yes, this does mean we lose some of the richness of the sound environment that taylor was originally trying to allow for when he rewrote this code. Fundamentally there are two ways to fix this bug: 1) The fastest and least disruptive (which is what is being tested here) is to just restore the behavior of the sound code with respect to how it manages and limits concurrent sounds by enforcing the limits as requested by the engine, this is basically an extenstion of the fix for the ear breaking warpins. 2) Basically a rewrite of the sound code from top to bottom because the engine itself is its own enemy. There are many things that can be done in a from scratch rewrite that would make this work much better, sound, and behave much better with respect to these bugs, but this is a huge undertaking and something I don't think SCP has a resouces for at this time. The patch for the new build is attached. The new build can be found here: https://www.box.com/shared/eef20e67b7bbda7c9ae9 ===== Now to answer some of you questions niffiwan. Bumpping max channels did solve the clipping and truncation issue (based on what I was seeing during debugging the test mission used a maximum of about 65 conncurrent sounds. But it didn't fix the problem with the "drone" and unfornatly, its not really a viable solution unless we are going to force OpenALSoft on everyone. No, Windows does not have a %AppData%\alsoft.ini but I did find a sample copy from: http://repo.or.cz/w/openal-soft.git/blob_plain/HEAD:/alsoftrc.sample and placed it. OpenALSoft did see it and use it though apparently the "Generic Software on *" devices do not honor it; I was able to record a wave with the alsoft.ini, but for some reason the drone was not audible. That is close to what I was hearing as the drone, but it was lower pitched and not as clear. I think the drone is the first quarter to first half second of the flakLaunch.wav and Capital5.wav. You are correct, the sources detection code is wrong and honestly while you solution is probably the correct one, I don't know how many hardware sound cards we would find that can actually do 48 voices so I think just disabling the sound if we don't have 48 is not really a valid solution espcially when FSO is actually able to dynamically use a smaller or larger number of max channels. Lets move this discussion to Mantis 2680. @jg18: Please open an new mantis # with an log of the hang attached. It would also be interesting to see a stack trace from that crash if you can. EDIT: Clarified what the patch does. |
|
mantis_2266_fix.take3.patch (3,504 bytes)
Actually do as the comment says and don't play the sound Our fancy OpenAL implemenation needs to be as harsh to the engine as the original sound code and just deny the request just like the old sound code implemenation would. Otherwise all of the fine tuning that :v: did is thrown out and the engine just trips over itself. Index: code/sound/ds.cpp =================================================================== --- code/sound/ds.cpp (revision 8846) +++ code/sound/ds.cpp (working copy) @@ -1408,34 +1408,37 @@ } } - // Make sure that we are not going to play more copies of this sound than we should be - if ( Cmdline_enforce_concurrent_sound_count && (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) { + // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume + if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) { // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound if (lowest_instance_vol <= new_volume) { ds_close_channel_fast(lowest_instance_vol_index); first_free_channel = lowest_instance_vol_index; + } else { + // NOTE: yes we are preventing the sound from playing even if + // there is an available channel because we are over the limit + // requested by the rest of the engine, which means if we do + // not honour its request to limit the count then the engine + // will trip itself up by using all channels without having + // the intention of actually doing so. This means we get + // very loud sounds, missing more important sounds, etc. + // Effectivly the problem is the rest of the engine assumes + // it is still stuck in the 90s with a sound card that only has + // <=16 channels so we need to give it a sound card that + // has 16 channels (though we are actually allowing 32 channels + // just because we can). + first_free_channel = -1; } - } - - if (first_free_channel < 0) { - // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume - if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) { - // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound - if (lowest_instance_vol <= new_volume) { - ds_close_channel_fast(lowest_instance_vol_index); - first_free_channel = lowest_instance_vol_index; + } else { + // there is no limit barrier to play the sound, so see if we've ran out of channels + // stop the lowest volume instance to play our sound if priority demands it + if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) { + // Check if the lowest volume playing is less than the volume of the requested sound. + // If so, then we are going to trash the lowest volume sound. + if ( Channels[lowest_vol_index].vol <= new_volume ) { + ds_close_channel_fast(lowest_vol_index); + first_free_channel = lowest_vol_index; } - } else { - // there is no limit barrier to play the sound, so see if we've ran out of channels - // stop the lowest volume instance to play our sound if priority demands it - if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) { - // Check if the lowest volume playing is less than the volume of the requested sound. - // If so, then we are going to trash the lowest volume sound. - if ( Channels[lowest_vol_index].vol <= new_volume ) { - ds_close_channel_fast(lowest_vol_index); - first_free_channel = lowest_vol_index; - } - } } } |
|
mantis_2266_fix.take3.trunk.patch (2,947 bytes)
Index: code/sound/ds.cpp =================================================================== --- code/sound/ds.cpp (revision 8916) +++ code/sound/ds.cpp (working copy) @@ -1402,24 +1402,36 @@ } } - if (first_free_channel < 0) { - // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume - if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) { - // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound - if (lowest_instance_vol <= new_volume) { - ds_close_channel_fast(lowest_instance_vol_index); - first_free_channel = lowest_instance_vol_index; - } + // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume + if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) { + // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound + if (lowest_instance_vol <= new_volume) { + ds_close_channel_fast(lowest_instance_vol_index); + first_free_channel = lowest_instance_vol_index; } else { - // there is no limit barrier to play the sound, so see if we've ran out of channels - // stop the lowest volume instance to play our sound if priority demands it - if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) { - // Check if the lowest volume playing is less than the volume of the requested sound. - // If so, then we are going to trash the lowest volume sound. - if ( Channels[lowest_vol_index].vol <= new_volume ) { - ds_close_channel_fast(lowest_vol_index); - first_free_channel = lowest_vol_index; - } + // NOTE: yes we are preventing the sound from playing even if + // there is an available channel because we are over the limit + // requested by the rest of the engine, which means if we do + // not honour its request to limit the count then the engine + // will trip itself up by using all channels without having + // the intention of actually doing so. This means we get + // very loud sounds, missing more important sounds, etc. + // Effectivly the problem is the rest of the engine assumes + // it is still stuck in the 90s with a sound card that only has + // <=16 channels so we need to give it a sound card that + // has 16 channels (though we are actually allowing 32 channels + // just because we can). + first_free_channel = -1; + } + } else { + // there is no limit barrier to play the sound, so see if we've ran out of channels + // stop the lowest volume instance to play our sound if priority demands it + if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) { + // Check if the lowest volume playing is less than the volume of the requested sound. + // If so, then we are going to trash the lowest volume sound. + if ( Channels[lowest_vol_index].vol <= new_volume ) { + ds_close_channel_fast(lowest_vol_index); + first_free_channel = lowest_vol_index; } } } |
|
Just attached a trunk version of the patch after several requests about it. |
|
Trunk version of the patch works on Snow Leopard (OS X 10.6) with trunk and my OpenAL Soft build. I can always hear my gun fire, and there's sound from the capships, although I didn't listen to it closely. Well done, iss_mneur! Although FSO still crashes on mission exit, so I'll have to look into that. |
|
I've done some testing with both versions of the patch with OpenAL soft 1.13 & 1.14. Primary sounds always play in the test mission, a fair bit of the flak is missing (as expected) but each instance doesn't seem to be truncated too much, unlike with some other tests at least one flak sound plays to completion fairly often which I think is better than all being truncated. When close to an Aeolus the flak launch sound mostly drowns out the flak detonation, but no big deal. Beam firing sounds seem to be all playing correctly as well. Overall - looking good :) |
|
Okay, good to hear, now to post in the RC6 thread. |
|
Both the regular RC6 and the one with the patch sound pretty much the same on my computer when flying through the ring in the test mission. The patched version seems to be a bit louder, especially the beams. Windows 7 x64 Sound Blaster Live 5.1 or something Generic Software in wxLauncher ps. I'm new to this Mantis thing so bear with me :) |
|
As reported by A8VR the take3 patch causes the voice audio to be cut off when the after burners are struck, but only the the afterburners (so far as I have seen). |
|
Issue has been fixed. Patch attached. It applies on top of the current RC7 trunk (though the changes are so minor that it may work on trunk as well after putting the take3 patch on). |
|
mantis_2266_take3_followup.patch (1,203 bytes)
Index: code/sound/ds.cpp =================================================================== --- code/sound/ds.cpp (revision 9076) +++ code/sound/ds.cpp (working copy) @@ -1401,6 +1401,8 @@ lowest_instance_vol = chp->vol; lowest_instance_vol_index = i; } + } else if ( chp->is_voice_msg ) { + // a playing voice message is not allowed to be preempted } else if ( (chp->vol < lowest_vol) && (chp->looping == FALSE) ) { lowest_vol_index = i; lowest_vol = chp->vol; @@ -1429,9 +1431,10 @@ // just because we can). first_free_channel = -1; } - } else { - // there is no limit barrier to play the sound, so see if we've ran out of channels - // stop the lowest volume instance to play our sound if priority demands it + } else if (first_free_channel == -1) { + // there is no limit barrier to play the sound, but we have run out + // of channels so stop the lowest volume instance to play our sound + // if priority demands it if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) { // Check if the lowest volume playing is less than the volume of the requested sound. // If so, then we are going to trash the lowest volume sound. |
|
A build with the patch against RC7: https://www.box.com/shared/0586fed47e1963ece31d |
|
Fix committed to trunk in revision 9113 |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-07-19 18:29 | chief1983 | New Issue | |
2010-07-19 19:36 | Renegade Paladin | Note Added: 0012246 | |
2010-07-19 19:37 | Renegade Paladin | Note Edited: 0012246 | |
2010-07-19 19:50 | chief1983 | Note Added: 0012247 | |
2010-08-05 20:09 | chief1983 | Target Version | 3.6.13 => 3.7.2 |
2011-03-31 16:55 | chief1983 | Target Version | 3.7.2 => 3.6.14 |
2012-01-27 19:58 | chief1983 | Assigned To | => iss_mneur |
2012-01-27 19:58 | chief1983 | Status | new => assigned |
2012-05-20 03:52 | iss_mneur | Note Added: 0013570 | |
2012-05-20 03:52 | iss_mneur | Reproducibility | always => random |
2012-05-20 03:52 | iss_mneur | Status | assigned => feedback |
2012-05-20 21:38 | chief1983 | Note Added: 0013584 | |
2012-05-20 21:38 | chief1983 | Status | feedback => assigned |
2012-05-20 21:39 | chief1983 | Status | assigned => feedback |
2012-05-20 22:42 | iss_mneur | Note Added: 0013586 | |
2012-05-21 00:49 | chief1983 | Note Added: 0013587 | |
2012-05-21 00:49 | chief1983 | Status | feedback => assigned |
2012-05-21 00:49 | chief1983 | Status | assigned => feedback |
2012-05-27 14:02 | jg18 | Note Added: 0013613 | |
2012-05-27 14:02 | jg18 | Note Edited: 0013613 | |
2012-05-27 14:03 | jg18 | Note Edited: 0013613 | |
2012-05-27 14:25 | jg18 | Note Added: 0013614 | |
2012-05-27 14:25 | jg18 | Note Edited: 0013614 | |
2012-05-27 16:03 | jg18 | Note Added: 0013615 | |
2012-05-27 16:04 | jg18 | File Added: fs2_open.osx.3614rc6.log | |
2012-05-27 16:05 | jg18 | File Added: fs2_open.osx.openalsoft.log | |
2012-06-11 06:47 | iss_mneur | Note Added: 0013659 | |
2012-06-21 20:37 | MjnMixael | Note Added: 0013696 | |
2012-06-28 04:14 | iss_mneur | File Added: Mantis_2266.fs2 | |
2012-06-28 04:17 | iss_mneur | File Deleted: Mantis_2266.fs2 | |
2012-06-28 04:17 | iss_mneur | File Added: Mantis_2266.fs2 | |
2012-06-28 05:22 | iss_mneur | Note Added: 0013732 | |
2012-06-28 10:02 | niffiwan | Note Added: 0013733 | |
2012-06-30 09:59 | niffiwan | Note Edited: 0013733 | |
2012-07-01 09:26 | niffiwan | Note Added: 0013755 | |
2012-07-02 12:46 | niffiwan | Note Added: 0013792 | |
2012-07-04 07:42 | jg18 | Note Added: 0013817 | |
2012-07-04 07:43 | jg18 | Note Edited: 0013817 | |
2012-07-04 11:51 | niffiwan | Note Added: 0013818 | |
2012-07-04 11:52 | niffiwan | File Added: mantis2266-channel-detection.patch | |
2012-07-05 02:08 | iss_mneur | Note Added: 0013825 | |
2012-07-05 02:09 | iss_mneur | File Added: mantis_2266_fix.take3.patch | |
2012-07-05 02:09 | iss_mneur | Relationship added | related to 0002680 |
2012-07-05 02:31 | iss_mneur | Note Edited: 0013825 | |
2012-07-05 03:34 | iss_mneur | File Added: mantis_2266_fix.take3.trunk.patch | |
2012-07-05 03:35 | iss_mneur | Note Added: 0013827 | |
2012-07-05 04:07 | jg18 | Note Added: 0013828 | |
2012-07-05 04:09 | jg18 | Note Edited: 0013828 | |
2012-07-05 11:56 | niffiwan | Note Added: 0013830 | |
2012-07-06 01:48 | iss_mneur | Note Added: 0013836 | |
2012-07-18 18:12 | ZeroDivision | Note Added: 0013870 | |
2012-07-18 18:15 | ZeroDivision | Note Edited: 0013870 | |
2012-07-31 03:42 | iss_mneur | Note Added: 0013888 | |
2012-07-31 05:23 | iss_mneur | Note Added: 0013889 | |
2012-07-31 05:23 | iss_mneur | File Added: mantis_2266_take3_followup.patch | |
2012-08-01 02:41 | iss_mneur | Note Added: 0013891 | |
2012-08-16 05:19 | iss_mneur | Note Added: 0013912 | |
2012-08-16 05:19 | iss_mneur | Status | feedback => resolved |