| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 3021 | [FSSCP] tables | minor | always | 2014-03-17 03:02 | 2022-06-10 21:53 |
| Reporter: | Spoon | Platform: | |||
| Assigned To: | DahBlount | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | assigned | Product Version: | 3.7.0 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | "target requires fov" flag does not take $Turret Base FOV: in account | ||||
| Description: | Causing turrets to remain idle instead of firing at an other valid target within range. | ||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Attached Files: |
basefov.png (424,955 bytes) 2014-03-17 03:40 https://scp.indiegames.us/mantis/file_download.php?file_id=2337&type=bug |
||||
| Notes | |
|
(0016747)
DahBlount 2015-06-14 18:57 |
I did some searching and perhaps adding a flag that makes a turret ignore the target radius would be a good solution here? The flag would most likely take effect somewhere around aiturret.cpp, line 1448. Anyone else have an opinion on this? |
|
(0016748)
DahBlount 2015-06-14 23:16 |
https://github.com/scp-fs2open/fs2open.github.com/pull/184 Pull Request |
|
(0016749)
FUBAR-BDHR 2015-06-15 02:06 |
Already a flag for this: "only target if can fire" |
|
(0016750)
Spoon 2015-06-15 02:26 |
"only target if can fire" is useless and doesn't do anything in this case. |
|
(0016752)
FUBAR-BDHR 2015-06-15 03:50 |
Well maybe there is a bug in the existing flag because that flag along with the advanced fov edge checks were added for exactly this purpose. The were put in so the Sobek turrets would pick a new target if the existing target went out of the fov. |
|
(0016753)
DahBlount 2015-06-16 18:14 |
From looking at the code, it seems that "target requires fov" ultimately results in the SSF_FOV_REQUIRED flag being. The flag works as intended except that it does not make the turret switch targets if its current target passes out of the turrets FOV. |
|
(0017142)
MjnMixael 2022-06-10 21:53 |
Might no longer be an issue. EatThePath to check with Warmachine. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 1119 | [FSSCP] multiplayer | feature | always | 2006-10-20 02:28 | 2020-11-19 23:55 |
| Reporter: | FUBAR-BDHR | Platform: | |||
| Assigned To: | FSCyborg | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | assigned | Product Version: | |||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Game ends in TvT if team leader leaves | ||||
| Description: | I know this isn't a bug but can anything be done about it. I can see the point of having it in squadwar or if host has option set to only allow order by team leader. In a normal TvT game it is a pain in the rear. | ||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Attached Files: | |||||
| Notes | |
|
(0008968)
karajorma 2008-03-15 01:42 |
Is this happening in-mission or just if the player drops during mission load? |
|
(0009036)
FUBAR-BDHR 2008-03-26 03:40 |
It does not happen in-mission just during briefing. Did notice one related problem. If all the players on one team drop then the host gets a message window with just "Decline" in it instead of a valid status message. |
|
(0009044)
taylor 2008-03-28 05:03 |
I don't actually plan on looking into this one myself, so perhaps someone else will decide to take it on (someone like karajorma ;)). |
|
(0014012)
karajorma 2012-11-03 08:20 |
I'll probably end up looking at this one eventually. Till then, sticking it back in the unassigned pile. |
|
(0017030)
FSCyborg 2020-11-01 15:25 |
Targeting as a 2021 upgrade |
|
(0017040)
taylor 2020-11-19 23:55 |
This is pretty clear in multi_team.cpp => multi_team_handle_drop(). There may be some issues reassigning teams during the sync stages, plus the ui stuff for the captains during briefings, which is probably why this particular check exists. Otherwise I don't see anything particularly wrong with that code. For briefings I think we would actually have to re-init the briefing UI for all players in order to make this work. I /might/ be possible if we set it up such that we can post a briefing event, while in a briefing, and reinit everything for everyone. It could be more trouble than it's worth though. But trying to do anything during a sync state should be a no-go. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 2389 | [FSSCP] multiplayer | minor | always | 2011-01-31 06:04 | 2020-11-01 15:39 |
| Reporter: | bigchunk1 | Platform: | |||
| Assigned To: | FSCyborg | OS: | |||
| Priority: | urgent | OS Version: | |||
| Status: | assigned | Product Version: | 3.6.12 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Multiplayer fighters with ballistic primaries spawn with negative ammo counts | ||||
| Description: |
This has happened in multiplayer missions for Blue Planet and Wings of Dawn. Player fighters carrying ballistic primary weapons spawn with ammo counts with very large negative numbers. Numbers like -1907842398426 Or something obscenely large but negative. Upon firing, the weapon does not respond. Upon respawning, the player's ballistic weapon gets reset with the intended ammunition count and works as if nothing was ever wrong. The bug is only an issue on the first spawn, but seems to be consistent enough to make me consider replacing ballistic primaries with energy draining alternates. |
||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Attached Files: | |||||
| Notes | |
|
(0013992)
karajorma 2012-10-26 07:14 |
Is this still an issue? |
|
(0017038)
FSCyborg 2020-11-01 15:39 |
Need to investigate before year's end!! |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 2012 | [FSSCP] multiplayer | major | always | 2009-10-29 00:01 | 2020-11-01 15:37 |
| Reporter: | FUBAR-BDHR | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | urgent | OS Version: | |||
| Status: | feedback | Product Version: | 3.6.11 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Reinforcements not working for clients in TvT | ||||
| Description: | They work if they are enabled at mission start but not if they have an arrival after that. Attaching test mission. Same one as the send-message-list bug. You will receive a message when the teams reinforcements should be able to be called. | ||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | 3.6.11 r5620 | ||||
| Attached Files: |
2multibug.fs2 (7,930 bytes) 2009-10-29 00:01 https://scp.indiegames.us/mantis/file_download.php?file_id=1337&type=bug |
||||
| Notes | |
|
(0014591)
karajorma 2012-12-30 15:34 |
When you say this doesn't work do you mean that the option to call in the reinforcement never appears in the comms menu, or that it does but selecting it does nothing? |
|
(0015486)
chief1983 2013-12-02 03:07 (Last edited: 2013-12-02 03:08) |
Ok, so the client, or second team, should have had the option to call in reinforcements after the 12000 ms mark? I did not see it appear as an option for the client at any point during testing this mission with 2 PCs. |
|
(0017037)
FSCyborg 2020-11-01 15:37 |
Need to investigate before year's end!! |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 1904 | [FSSCP] multiplayer | feature | always | 2009-03-26 22:32 | 2020-11-01 15:31 |
| Reporter: | FUBAR-BDHR | Platform: | |||
| Assigned To: | FSCyborg | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | assigned | Product Version: | 3.6.9 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Weapons in loadout screen not filled in with valid choices if default is not available. | ||||
| Description: | Noticed this one in TBP today. One mission has bombers (Badgers) available but their default primary for bank one is not available. When the player switches to this ship this results in the bank being left empty instead of being filled in with a valid one from the available list. | ||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | 3.6.10 RC1 Inferno. Mission was Isolation Phase 2.fs2 from Vidmaster's Operations 2.0 campaign pack. http://www.hard-light.net/forums/index.php/topic,55792.0.html Zathras patch for TBP here: http://www.fubar.org/TBP/Zathras.rar | ||||
| Attached Files: | |||||
| Notes | |
|
(0017032)
FSCyborg 2020-11-01 15:31 |
Targeting for 2021 upgrade |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 3200 | [FSSCP] user interface | minor | always | 2017-10-20 23:13 | 2017-10-20 23:20 |
| Reporter: | frsp2op | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | normal | OS Version: | |||
| Status: | new | Product Version: | 3.8 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Unix/Linux/BSD: program can never get focus when run on pure xorg xserver | ||||
| Description: |
when program is started with dedicated xserver, without using a desktopenvironment (like gnome or KDE) and without any window manager (like openbox or fvwm), then it is not possible for this program to receive input focus. And therefore the program can not receive user input, it is impossible for the user to control the program nor quit the program. I expected the program to get input focus and be usable. |
||||
| Tags: | |||||
| Steps To Reproduce: |
1.) Login in into an Linux terminal (a real tty! Like the one you get, when pressing CTRL-ALT-F1 at the same time) 2.) be sure you have no ".xinitrc" file in your home directory 3.) change path to Freespace 2 Open installation directory. 4.) then start freespace with dedicated xserver via command: $startx ./fs2_open |
||||
| Additional Information: | |||||
| Attached Files: | |||||
| Notes | |
|
(0016911)
frsp2op 2017-10-20 23:20 |
it does not matter if program is run in fullscreen or windowed mode |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 3167 | [FSSCP] HUD | minor | always | 2015-06-24 04:02 | 2015-06-24 04:02 |
| Reporter: | Yarn | Platform: | x64 | ||
| Assigned To: | OS: | Windows 7 | |||
| Priority: | normal | OS Version: | |||
| Status: | new | Product Version: | 3.7.3 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Offscreen indicator does not stay on center monitor | ||||
| Description: | Revision eff6d40 from June 18 added my fix for triple-monitor setups (thread here: http://www.hard-light.net/forums/index.php?topic=89262.0). However, one thing that my fix didn't do is keep the offscreen indicator on the center monitor, simply because I couldn't figure out how to do this. This means that players using such setups may need to look far to the left or right to see the offscreen indicator, regardless of how much of the screen area is actually used by the HUD. If FSO is to support triple-monitor setups properly, this bug will need to be fixed. | ||||
| Tags: | |||||
| Steps To Reproduce: |
It's possible to test this issue with a single standard monitor: Use the -center_res parameter with a resolution that has an aspect ratio that's narrower than that of the screen resolution. So, for example, if your screen resolution is 1920x1080 (a 16:9 resolution), you can use "-center_res 1440x1080" to limit the HUD to the center 4:3 area. After you've done that (or if you are using a triple-monitor setup), load any mission that lets you target something (almost any mission will do). The HUD gauges should utilize only part of the screen width, leaving empty space on the sides. Target something, then turn your ship so that your target goes off the left or right edge of the screen. The offscreen indicator is supposed to stay in the HUD area; instead, it leaves that area and goes to the edge of the screen. |
||||
| Additional Information: | |||||
| Attached Files: | |||||
| There are no notes attached to this issue. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 2638 | [FSSCP] speech | feature | always | 2012-04-13 04:20 | 2015-04-23 17:39 |
| Reporter: | gereedy | Platform: | |||
| Assigned To: | Echelon9 | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | code review | Product Version: | |||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Support speech on OSX | ||||
| Description: | This patch implements text-to-speech for mac os x. | ||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Attached Files: |
macspeech.patch (5,716 bytes) 2012-04-13 04:20 https://scp.indiegames.us/mantis/file_download.php?file_id=1828&type=bug macspeech2.patch (5,747 bytes) 2012-04-13 19:54 https://scp.indiegames.us/mantis/file_download.php?file_id=1829&type=bug macspeech3.patch (5,999 bytes) 2012-08-14 14:16 https://scp.indiegames.us/mantis/file_download.php?file_id=1932&type=bug macspeech4.patch (4,887 bytes) 2014-06-30 22:20 https://scp.indiegames.us/mantis/file_download.php?file_id=2435&type=bug macspeech5.patch (5,020 bytes) 2015-04-23 17:09 https://scp.indiegames.us/mantis/file_download.php?file_id=2703&type=bug |
||||
| Notes | |
|
(0013464)
gereedy 2012-04-13 19:54 |
Oops, I forgot to release the strings. Here's an updated patch. |
|
(0013479)
Echelon9 2012-04-23 14:08 |
I've got this cleanly compiled into a build, but at a bit of a loss to actually get it working in game. Is there a system-wide setting (i.e. in Preferences) that I need to set before this will work. Using OS X 10.7 here. |
|
(0013490)
gereedy 2012-04-30 04:26 |
Oh yeah, I had to edit the fs2_open.ini file in ~/Library/FS2_Open and add the following lines: SpeechTechroom=1 SpeechBriefings=1 SpeechIngame=1 SpeechMulti=1 I've not seen any other way (launcher or in-game) to set these. |
|
(0013492)
Echelon9 2012-04-30 15:30 |
Hrmm, I've tried setting those as well as setting them to 0, as per the code. Across Debug and Retail, no luck getting this working... |
|
(0013515)
gereedy 2012-05-04 03:00 |
I think the 0 in the code is the default value if none is set, they need to be 1 to activate speech. How are you building? The only thing I can think of is that you're building without FS2_SPEECH defined. FYI, I'm on Lion as well and used the Xcode 4 project. The patch include the changes to the project file to turn that define on. |
|
(0013530)
chief1983 2012-05-09 19:07 |
Huh, and here I thought we'd need to be using Festival across the board. |
|
(0013905)
Echelon9 2012-08-14 13:51 |
Okay, by using this patch and forcing speech at startup with the -query_speech command line option, I hear part of the initial testing "Welcome to FS..." before Freespace crashes. Looks like there's some memory corruption going on. // fs2_open.log ------------------------------------------------------------ Initializing OpenAL... OpenAL Vendor : Apple Computer Inc. OpenAL Renderer : Software OpenAL Version : 1.1 Found extension "AL_EXT_float32". Sample rate: 0 (44100) EFX enabled: NO Playback device: Built-in Output Capture device: Built-in Microphone ... OpenAL successfully initialized! Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] // Crash reporter ------------------------------------------------------------ Thread 3 Crashed: 0 FS2_Open-Inferno (debug) 0x0057bb00 _vm_free(void*, char*, int) + 128 (stubs.cpp:687) 1 FS2_Open-Inferno (debug) 0x000035cb operator delete(void*) + 43 (fsmemory.cpp:19) 2 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b3e4f0 MTBEDelayedNotifier::ForwardUnit() + 102 3 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b3bcbe MTCBSegmentProducer::NextSegment(MTMBSegment*) + 582 4 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b3b98e MTMBSmoothSegment::NextSegment(MTMBSegment*) + 90 5 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b6b488 non-virtual thunk to MTMBSmoothSegment::NextSegment(MTMBSegment*) + 27 6 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b3b873 MTMBChangePitch::NextSegment(MTMBSegment*) + 145 7 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b6b2b5 non-virtual thunk to MTMBChangePitch::NextSegment(MTMBSegment*) + 27 8 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b3b27a MTMBBlend::NextSegment(MTMBSegment*) + 160 9 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b6b368 non-virtual thunk to MTMBBlend::NextSegment(MTMBSegment*) + 27 10 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b3b079 MTMBChangeAmplitude::NextSegment(MTMBSegment*) + 35 11 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b6b403 non-virtual thunk to MTMBChangeAmplitude::NextSegment(MTMBSegment*) + 27 12 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b3ac71 MTMBSpeechRateModifier::NextSegment(MTMBSegment*) + 211 13 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b6b5fe non-virtual thunk to MTMBSpeechRateModifier::NextSegment(MTMBSegment*) + 27 14 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b3aa15 MTBEPhraseProcessor::GenerateSamples(MTBESoundOutput*, int*) + 277 15 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b2b52f MT3BEngineTask::Execute(void*) + 337 16 com.apple.speech.synthesis.MacinTalkSynthesizer 0x07b06cce MTBEWorker::ExecuteTasks() + 384 |
|
(0013906)
Echelon9 2012-08-14 14:16 |
A more recent patch version is attached (macspeech3.patch) |
|
(0015977)
chief1983 2014-06-30 22:18 |
Checked back up on this patch. Only takes two line additions of FS2_SPEECH to the Xcode project now I think, both added below the only two occurences of APPLE_APP. Ran it, no speech. fs2_open.ini in ~/Library/FS2_Open looks like: [Default] VideocardFs2open=OGL -(1024x768)x32 bit TextureFilter=1 OGL_AnisotropicFilter=0 OGL_AntiAliasSamples=0 SoundDeviceOAL=Built-in Output CurrentJoystick=99999 EnableJoystickFF=0 EnableHitEffect=0 NetworkConnection=LAN ConnectionSpeed=Fast LastPlayer=chief_work SpeechTechroom=1 SpeechBriefings=1 SpeechIngame=1 SpeechMulti=1 SpeechGame=1 [Sound] PlaybackDevice=Built-in Output CaptureDevice=Built-in Microphone [PXO] FS2OpenPXO=1 I added SpeechGame as I saw it in my Windows registry list as well. Debug build log looks like: Initializing OpenAL... OpenAL Vendor : Apple Computer Inc. OpenAL Renderer : Software OpenAL Version : 1.1 Found extension "AL_EXT_float32". Sample rate: 0 (44100) EFX enabled: NO Playback device: Built-in Output Capture device: Built-in Microphone ... OpenAL successfully initialized! Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] STUB: speech_set_voice in /Users/cliff.gordon/fs2open/code/sound/speech.cpp at line 280, thread 63763 -query_speech doesn't seem to change anything for me. |
|
(0015978)
chief1983 2014-06-30 22:21 (Last edited: 2014-06-30 22:22) |
I've uploaded a new patch version with tweaked project files. I also added the FS2_SPEECH define to configure.ac, however that file doesn't affect Xcode to my knowledge. That also made me wonder how ApplicationServices is being loaded into the Xcode builds then, or if it was needed at all. This doesn't fix it, it's just a more up to date starting point for anyone looking at it. |
|
(0015981)
Echelon9 2014-07-01 00:26 |
Thanks, I'll take another look at the memory corruption here. Looks like another double free. |
|
(0016000)
Echelon9 2014-07-01 12:08 |
You shouldn't need to set SpeechGame=1, see further the table of speech types in the array FSSpeech_play_id[] in fsspeech.cpp |
|
(0016002)
chief1983 2014-07-01 13:57 |
Well, I wasn't sure, but removing it doesn't change anything. I don't get any crashes, I just enter the tech room, and I don't hear any TTS. |
|
(0016003)
Echelon9 2014-07-01 14:11 |
Same here. I spent some time testing and debugging this evening. Whilst no crashes, also no spoken words on 10.9. I can confirm the text is being passed to the SpeakCFString() API call, just nothing happens after that. |
|
(0016004)
chief1983 2014-07-01 14:36 (Last edited: 2014-07-01 14:36) |
Like I said, I wonder if that's because the ApplicationServices framework isn't actually being added as an App resource in the Xcode4 project. It was added to configure.ac for some reason but that has nothing to do with Xcode builds. But I would probably expect more warnings/errors if that were actually the problem. |
|
(0016005)
Echelon9 2014-07-01 15:09 |
I did a quick test with otool -L on the resultant binary, and it looks like ApplicationServices.framework was linked in. |
|
(0016654)
chief1983 2015-04-23 15:16 |
So any other thoughts on this? If the framework is linked in, why is there no speech? Something needs to be configured in System Preferences or something? |
|
(0016655)
chief1983 2015-04-23 17:06 (Last edited: 2015-04-23 17:09) |
I applied the macspeech4.patch to current trunk and tried again, after adjusting some settings in the VoiceOver configuration. Also tried the -query_speech flag. No voice in tech room, nothing from query_speech either. Edit: Attached an updated version of the patch with the chunks in the right places and some whitespace goofs fixed. |
|
(0016657)
chief1983 2015-04-23 17:39 |
Log excerpt: ... OpenAL successfully initialized! Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] Why are you trying to free a NULL pointer? [fsmemory.cpp(19)] STUB: speech_set_voice in /Users/cliff.gordon/fs2_open_git/code/sound/speech.cpp at line 280, thread 6729 Initializing OpenGL graphics device at 640x480 with 32-bit color... |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 2720 | [FSSCP] graphics | feature | N/A | 2012-10-30 08:53 | 2015-04-16 04:22 |
| Reporter: | The_E | Platform: | |||
| Assigned To: | The_E | OS: | |||
| Priority: | low | OS Version: | |||
| Status: | assigned | Product Version: | 3.6.16 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Loadout screen does not show external weapon models | ||||
| Description: | Which it really should, for immersion value and stuff | ||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Attached Files: | |||||
| There are no notes attached to this issue. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 1775 | [FSSCP] graphics | major | always | 2008-09-23 16:31 | 2015-01-03 18:05 |
| Reporter: | chief1983 | Platform: | |||
| Assigned To: | Goober5000 | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | assigned | Product Version: | 3.6.11 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Fix in Xt: Reminder: Include Texture replacement bugfix from Xt diff in 3.6.11 | ||||
| Description: | Taylor's Xt diff includes a bugfix for texture replacement so that a previously unloaded texture can be used in a replacement. This bugfix should be included as soon as possible, the rest of the texture replacement code will be included when someone can sort through the rest of the Xt branch. | ||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | More info here: http://www.hard-light.net/forums/index.php?topic=48398.msg1143016#msg1143016 | ||||
| Attached Files: | |||||
| Notes | |
|
(0009898)
chief1983 2008-10-09 17:02 |
Bumping another one that should hopefully get pulled from Xt before release if someone can get to it. |
|
(0010221)
phreak 2008-11-18 15:40 |
What was changed in the XT builds with respect to texture replacement? Which files need to be merged into the trunk? |
|
(0010222)
chief1983 2008-11-18 15:48 |
That's what someone was going to have to figure out. And it's probably not whole files, but likely an individual set of changes to a few files. It may not actually make it for 3.6.10 though. |
|
(0010418)
phreak 2008-12-14 16:12 (Last edited: 2008-12-14 16:13) |
I can take a look at this, but I don't think it would be ready until after 3.6.10. To make it easy, I can merge the changes in with my personal branch so it can be tested independently. I can probably do some SVN magic to have the changes in my branch saved off and start with a clean build. When everything is merged in successfully, we can merge my branch in with the main one. |
|
(0010419)
chief1983 2008-12-14 19:53 |
This really isn't too big of a deal for 3.6.10, I had just hoped someone to get people looking through the Xt branch diff we got from Taylor if nothing else. For the next release we'll probably be pulling in a lot more from that branch than just this fix though. |
|
(0010445)
chief1983 2008-12-20 19:53 |
If no one plans on getting to this for this release, it might just not get done separately and go in with the rest of the code. |
|
(0011229)
chief1983 2009-11-10 03:25 |
Assigning to goober since phreak hasn't been around much and he wants this one done. |
|
(0016434)
Goober5000 2015-01-03 18:05 |
I've been working through Taylor's texture_set code and the last bit has turned out to be pretty tricky. Most of it is done except for a few last bits. However, I committed an interim fix that makes ship-class texture replacement work via a different method, so this is no longer a constraint to 3.7.2. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 1982 | [FSSCP] gameplay | feature | always | 2009-08-23 00:08 | 2014-06-30 15:47 |
| Reporter: | FUBAR-BDHR | Platform: | |||
| Assigned To: | Sushi_CW | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | assigned | Product Version: | 3.6.11 | ||
| Product Build: | Resolution: | reopened | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 3.6.11 | ||
| Target Version: | |||||
| Summary: | Ships with no afterburners call afterburner_start and afterburner_stop | ||||
| Description: |
Found this the other night and was discussing it with Wanderer. Adding it here so it doesn't get forgotten about. Basically saw a bunch of warnings about ships not having afterburners when I ran into this crash: http://scp.indiegames.us/mantis/view.php?id=1980 so I checked to see what was causing them. Basically there is no check for ships actually having afterburners before afterburner_start is called and a time delay is set in several functions. This results in afterburner_stop being called which throws the warning. It probably wasn't much of an issue in the past but with the new glide features afterburners are used by the AI a lot more. I believe this is called in 14 places that would need updated. There is also a reference to it in the multiplayer packet code but that should never be hit if checked in the first place. |
||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | 3.6.11 r5524. I don't have the exact line number but it's easy to find. Just do a search for "does not have afterburner capability". | ||||
| Attached Files: |
0001982 .patch (3,489 bytes) 2009-11-10 22:57 https://scp.indiegames.us/mantis/file_download.php?file_id=1342&type=bug |
||||
| Notes | |
|
(0011160)
karajorma 2009-08-26 05:52 |
Wouldn't it be smarter to just have Afterburner_start do a quick exit if the ship doesn't actually have an afterburner? :D |
|
(0011162)
FUBAR-BDHR 2009-08-26 07:05 |
That's what it does now but the routines that call it set a timer which causes the call of afterburner_stop. Basically they are all kind of like this: if ((dist_to_enemy < 400.0f) && ai_maybe_fire_afterburner(Pl_objp, aip)) { afterburners_start(Pl_objp); aip->afterburner_stop_time = Missiontime + 3*F1_0; } A check in ai_maybe_fire_afterburner would be another idea but not all of the routines call that either. |
|
(0011166)
karajorma 2009-08-28 00:05 |
I've changed things a little so that ai_maybe_fire_afterburner only evaluates to true if the ship actually has afterburners in the first place. See if that fixes anything. :) |
|
(0011199)
Sushi_CW 2009-09-28 22:30 |
There are a number of places that use afterburner without ai_maybe_fire_afterburner, so it's not a comprehensive fix. afterburners_start silently bails if it is called on a ship with no afterburner. afterburners_stop is the one that complains, then bails (without breaking anything) To be honest, I'd just as soon remove the warning from afterburners_stop. I don't think it serves any useful purpose at all, and IMHO it makes more sense for the "doesn't have afterburners" case to be entirely encapsulated in afterburners_start and afterburners_stop. So that's my suggestion: just remove the useless warning. If/when we do remove the warning, however, we should remove the check that Kara put in ai_maybe_fire_afterburner just to keep things clean. |
|
(0011200)
FUBAR-BDHR 2009-09-28 23:39 |
Well if the timer for afterburner_stop wasn't set in the first place then it wouldn't get called. Isn't calling 2 routines unnecessarily extra overhead to begin with? Also are any of the places where the AI attempt to use afterburners being done instead of another maneuver (slide for instance) thus making ships without afterburners "dumber" then those with them? |
|
(0011228)
pedro 2009-11-09 13:04 (Last edited: 2009-11-09 13:06) |
karajorma told me to fix this bug. I would like to propose a fix. (BTW: kara, now you can assign this bug to me, if you want.) An AI could have different strategies when the controlled ship has afterburners or not. I think an IA should never try (and fail) to use afterburners on a ship which is not equipped because it encourages the IA to pilot every ship the same way. That's why I propose to continue the karmajora correction by adding ai_maybe_fire_afterburner call every time it's necessary. Here is my proposal: 1- afterburners_start modified bails with a warning message "Ship type %s does not have afterburners". The check is moved before the snd_play statement. The warning will help to detect earlier, abusive call to afterburner_start. Note that when a player start the afterburner on an unequipped ship,afterburners_start is never called, so there will be no warning logged. 2- afterburners_stop modified to bails with a warning message "Ship type %s does not have afterburners" according to Sushi_CW comment. 3- IA never start afterburner when ai_maybe_fire_afterburner return 0. Theses modifications causes IA to use less the afterburners. For instance ia of class 0 never use the afterburner. 3.1 - evade_ship() modified to check ai_maybe_fire_afterburner 3.2 - ai_big_strafe_glide_attack() modified to check ai_maybe_fire_afterburner (I have an svn patch available, if needed.) I don't know how to be sure the change in IA behavior doesn't introduce new bugs. What do you think about it ? I addition, I don't know how to reproduce the incident on my computer in order to check the correction. I definitely need help on that point. Thanks for your help. |
|
(0011241)
pedro 2009-11-10 22:57 |
Patch uploaded. Waiting for approval. |
|
(0011277)
karajorma 2009-11-14 09:51 |
Looks fine to me. Committed. |
|
(0011282)
Sushi_CW 2009-11-14 15:22 |
Aw, CRAP. Sushi drops the ball again. This patch has gameplay-changing effects. It makes it so that places where afterburner was once fired for ALL ships now depend on the AI class (ai_maybe_fire_afterburner returns different values for different AI classes). This means that after this patch, AI ships will sometimes NOT use afterburner where they always did before, specificially when evading collisions, and avoiding shockwaves. (Glide strafe is affected too, but since it isn't an official feature yet, it's not as big of a deal.) Totally mea culpa for not looking closer at this sooner. I'm sorry, Pedro. You posted your patch well in advance and I had plenty of time to make sure it wouldn't break anything, and I utterly failed to do so. :( P.S. I still think that this warning is basically useless and would be better off removed completely. |
|
(0011288)
pedro 2009-11-16 09:42 |
No problem. I understand well that changing IA behavior would cause unpredictable bug in the game. I suppose the patch should be rollbacked. Should I provide a "rollback" patch plus a warning removal ? |
|
(0011289)
chief1983 2009-11-16 15:56 |
Please do them independently of each other if you do, first the rollback and then warning removal if it's agreed upon. |
|
(0011290)
FUBAR-BDHR 2009-11-16 22:05 |
Warning removal doesn't really solve the problem though. You have AI ships that believe they have fired their afterburners when they haven't. So you may have situations like following: Missile fired at ship Ship decides to use afterburners to evade Ship doesn't have afterburners but there is no check for that Timer is set no evasion occurs Ship takes direct hit by missile Now if the ship is checked for afterburners before the call the ship may then skip that routine and decide to use side thrust instead. Of course all this is theoretical and I really don't know how that would or play out. If it is possible you are ending up with extremely dumb AI just because they don't have afterburners. |
|
(0011296)
Sushi_CW 2009-11-17 23:10 |
True, but the warnings don't prevent those situations: they just announce the problem. Presumably to inform the coder that they are starting up afterburners without first verifying that the ship has afterburners. But what if, in the code, you want the ship to do what it's doing anyway, and just add afterburner if they're available? This is the case in most places, at least, and I don't see the point of adding explicit checks for the existence of afterburners on the ship when the calling code doesn't really care whether they have them or not. If the calling code needs to do something different for ships without afterburners, it needs to make that check and branch itself (which is already the case both before and after this patch). Whether or not we keep the warnings, though, calling ai_maybe_fire_afterburner to make sure they're invoked is the wrong approach, since ai_maybe_fire_afterburner has other effects as well. I suppose you could have a new function that is in charge of checking for the existence of afterburners before firing them (and administering a firm warning if they aren't there), but I still don't really see the point. :) |
|
(0011298)
chief1983 2009-11-18 02:00 |
Well if you're certain that situations like FUBAR described can't actually occur, then there is no point, otherwise you're not listening to him :) |
|
(0011920)
Sushi_CW 2010-05-01 20:38 |
Patch reverted in trunk rev 6083, since it has side effects that change AI behavior. The underlying issue should probably still be resolved. |
|
(0015953)
Goober5000 2014-06-30 03:21 |
Is the issue in fact resolved? If it is, we should resolve the ticket. |
|
(0015962)
Admiral MS 2014-06-30 10:03 (Last edited: 2014-06-30 15:47) |
I don't have a working test case but when looking at the code the issue should still occur. I'll see if I can create a patch that keeps the warning but prevents calling afterburners_stop when there is no afterburner (simple check for SIF_AFTERBURNER or PF_AFTERBURNER_ON flag). PF_AFTERBURNER_ON can only get true when SIF_AFTERBURNER is true so both flags are equal for this check. I would keep the warning cause it hints that a specific case may have been overlooked in AI code that somehow leads to an afterburner_stop where it shouldn't. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 3044 | [FSSCP] graphics | minor | always | 2014-05-16 13:42 | 2014-05-16 13:42 |
| Reporter: | fightermedic | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | normal | OS Version: | |||
| Status: | new | Product Version: | 3.7.2 RC1 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Thruster-Jets for non player ships not rendering reliably | ||||
| Description: |
thrusters do not show up on a ship that doesn't belong to the player's wing, but even then they don't most of the time furthermore, it appears "roll right" and "bank right" are switched in their functionallity, same goes for the left ones |
||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Attached Files: | |||||
| There are no notes attached to this issue. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 1983 | [FSSCP] multiplayer | feature | sometimes | 2009-08-23 07:15 | 2014-04-21 07:00 |
| Reporter: | FUBAR-BDHR | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | normal | OS Version: | |||
| Status: | feedback | Product Version: | 3.6.11 | ||
| Product Build: | Resolution: | reopened | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 3.6.13 | ||
| Target Version: | |||||
| Summary: | Discussion: Hand off nebula rendering to clients completely from standalone | ||||
| Description: |
Debugger call stack and variables attached. Basically your_basic_hot_sauce is turning up null along with start and strike. |
||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | 3.6.11 r5524 | ||||
| Attached Files: |
hot_sauce.txt (3,692 bytes) 2009-08-23 07:15 https://scp.indiegames.us/mantis/file_download.php?file_id=1319&type=bug |
||||
| Notes | |
|
(0011152)
Wanderer 2009-08-23 09:41 (Last edited: 2009-08-23 09:41) |
Fairly likely cause seems to be the neblightning.cpp line 621 which does not explicitly prevent standalone servers from running that function even though the Neb2_cubes[][][] as not stuffed for standalone builds. |
|
(0012735)
The_E 2011-06-28 19:48 |
Fixed in rev 7288 |
|
(0012737)
The_E 2011-06-28 21:32 |
Reminder for self: Okay, not actually fixed, just no longer causing warnings. What this apparently needs is a bit of a rethink regarding how to handle nebulas for multi. The server needs to generate lightning for all players, then send that data over in order to get the desired effect, which is a bit complicated for standalones due to them not having data like the player position and orientation available. A correct fix would be to get the position/orientation data for player 1, and use that. |
|
(0012739)
The_E 2011-06-29 09:24 |
Okay, so after thinking about this, it might be worthwhile to think about handing nebula rendering (and more importantly, lightning rendering) off to the clients completely. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 2972 | [FSSCP] graphics | minor | always | 2013-12-03 23:44 | 2013-12-03 23:44 |
| Reporter: | Droid803 | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | normal | OS Version: | |||
| Status: | new | Product Version: | 3.7.1 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Inconsistent Thruster Particle Generation | ||||
| Description: | Thruster particles (and possible other particles) are being affected by a hard-coded cutoff that results in somewhat inconsistent generation when utilized on AI ships. | ||||
| Tags: | |||||
| Steps To Reproduce: | Set large, obvious thruster particles (for example, a long smoke plume) that are visible from far away/the front of the ship. They will not be rendered from certain angles/distances from first/third person view, but will be rendered if external camera is centered to the ship emitting the particles. | ||||
| Additional Information: |
Likely due to optimization, rendering all thruster particles forever and always would probably do more harm than good, but being able to control render conditions via thruster particle table entry would allow mod makers to bypass the default/harcoded conditions if necessary. According to Wanderer: "Looking at the code that should affect all particle emitter calls (but not particle create). The actual cut off is set in the function starting from line 498 in particle.cpp." |
||||
| Attached Files: | |||||
| There are no notes attached to this issue. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 2924 | [FSSCP] graphics | minor | always | 2013-09-22 16:16 | 2013-10-20 16:24 |
| Reporter: | fightermedic | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | normal | OS Version: | |||
| Status: | new | Product Version: | 3.7.0 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Team Color not applied to Cockpits and LODs | ||||
| Description: | Team Colors are not applied to cockpits and all LODs that have no shaders rendered on them | ||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Attached Files: | |||||
| Notes | |
|
(0015337)
zookeeper 2013-10-20 16:24 |
I think r9929 probably fixed the issue for LODs. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 1654 | [FSSCP] gameplay | tweak | always | 2008-04-03 18:19 | 2013-03-26 04:26 |
| Reporter: | ARSPR | Platform: | DELL Dimension 9200 | ||
| Assigned To: | OS: | Windows Vista | |||
| Priority: | normal | OS Version: | Ultimate 32-bit | ||
| Status: | new | Product Version: | |||
| Product Build: | From SVN trunk 2008-04-03 on | Resolution: | open | ||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | Crazy movements at the begining of the autopilot run when not leading it. | ||||
| Description: |
This is a "spin-off" from 0001520 and I feel a tweak would be fine in autopilot code. As the root problem of 0001520, Taylor has fixed the different object vs. wing order which caused pretty strange behaviours. Now, the object order in the fs2 file doesn't matter anymore. Now the autopilot run is lead by the first wing ship (ie. by Alpha 1). But then a tweak is needed in old autopilot code, (not cinematic autopilot): + When player's ship doesn't lead the run, (the player is not Alpha 1 but Alpha n), it makes crazy movements before stabilizing itself in formation with the wing first ship. These movements should be dampened somehow. |
||||
| Tags: | |||||
| Steps To Reproduce: | |||||
| Additional Information: | You can test with any of the two missions from 0001520. (Now they behave exactly identical). | ||||
| System Description |
Core 2 Quad E6600 nvidia GeForce 8800 GTX 2 GB RAM |
||||
| Attached Files: | |||||
| Notes | |
|
(0010688)
Woolie Wool 2009-02-23 23:12 |
Bumping this to call attention to the serious bugginess of autopilot in recent builds. |
|
(0010852)
chief1983 2009-04-29 20:50 |
Here's some info on some builds which were around some possible autopilot-breaking commits: http://www.freespacefaq.com/Misc-Downloads/Builds/Old/Team_Loadout_Build.7z (Jan 26 2008 Stable Branch, before a bunch of Feb autopilot commits) http://fs2source.warpcore.org/exes/latest/20080312-Goober5000.7z (March 12 2008, I think stable branch, right before the below one if so) http://fs2source.warpcore.org/exes/latest/C03162008.zip (March 16 2008, right after WMC committed some scripting stuff) http://wwwcsif.cs.ucdavis.edu/~chos/fs2_open_trackir.zip (March 5, 2008, another one before the last one if the goober one turns out to be the HEAD branch or something) There was also a commit on August 30, but that's since I started the nightly build system so you should be able to find a build from that time frame easily, before and after r4773 I sent this info to Woolie over IM but thought adding it to some mantis reports would be prudent. If some testing with those builds could be done, it might help. They should all be trunk/stable branch, not Xt stuff, so if any of those do/don't work it will help more in tracking down the problem. |
|
(0010856)
taylor 2009-04-30 22:16 |
Have the commits from me on March 20, 2008 been ruled out yet (both with "1520" in the description)? There were several commits which were made to address all of these autopilot bugs. The code was tested by ARSPR before commit and I tested using original and cinematic autopilot missions as well. I don't know how something passed through so much testing on a single feature, but it's possible that something was b0rked in the commit (something missing from the Xt tree) or that so other commit broke it later on. Also, the changes that I committed were NOT what I wanted to go with. There was a post in the SCP internal concerning the issue with special_ship and how the AI handled wing formations with the player not being the wing leader (if special_ship != 0). That original code was given the ok by ARSPR but then rewritten to be what eventually made it into SVN to fit with Goober's explanation of how it should work. |
|
(0010857)
chief1983 2009-04-30 22:31 |
Actually, according to Woolie, the autopilot stuff he's using worked fine in the March 16 build. So I don't know what the commits on March 20 were suppposed to fix. But according to him, the mid-August build is broken, so something between March 16 and mid-August broke whatever he's been checking. So, if http://fs2source.warpcore.org/exes/latest/20080321-Goober5000.7z could be tested that would help eliminate that set of commits. That's one of the first released SVN trunk builds and should have what taylor is referring to. |
|
(0010858)
Woolie Wool 2009-04-30 22:53 |
The 3/21 build is broken. We may just have our culprit. |
|
(0010859)
taylor 2009-04-30 23:16 |
The code was seriously broken before, but depending on how the mission was set up it might not have been obvious. The part dealing with this particular bug, the movement problem at wing formation start, is due to the AI code always assuming that the player ship is the wing leader. The formation code has always been wonky movement wise, but since the order bug was fixed it is now painfully obvious that it is really screwed up, because the player gets bunched in with the AI on formation rather than being the leader of said formation. This is the exact reason that I wanted the code to make the player always be the wing leader, the AI formation code simply wasn't set up to be "nice" otherwise. |
|
(0010865)
chief1983 2009-05-01 15:34 |
I'm not sure whether it was this bug specifically being tested, but Woolie was trying the same test with several builds, and whatever he was testing worked fine in a pre-SVN March 16 build, that I think was mostly stable trunk code, but didn't work in one of the first SVN trunk builds from March 21. I was thinking that should help narrow down some problems somewhat. |
|
(0012400)
The_E 2010-10-08 10:46 |
Is this still current? Or was it fixed together with the other autopilot stuff? |
|
(0012406)
chief1983 2010-10-08 15:05 |
Probably fixed, maybe Woolie could vouch for it. |
|
(0012449)
The_E 2010-11-11 13:26 |
Not fixed. The AI still does some pretty violent maneuvers when getting into position. |
|
(0014839)
Woolie Wool 2013-03-26 04:24 (Last edited: 2013-03-26 04:26) |
Bumped to report even more autopilot weirdness. If you autopilot to an asteroid field and are NOT the wing leader, and are using cinematic autopilot, you will never be able to autopilot away as you will be instantly teleported back where you came from. This does not happen if you are wing leader. Autopilot code seems to assume that the player is the wing leader. This is not a wise assumption to make. Discovered this tonight while FREDing a mission for Twist of Fate. Will create proof of concept for regular FS2 tomorrow. EDIT: This could really be changed to "autopilot does not work correctly if player is not wing leader" and bumped in priority because this can totally break a mission. It's not a minor thing. |
| View Issue Details | |||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 2680 | [FSSCP] sound | minor | always | 2012-07-05 02:03 | 2012-07-06 01:47 |
| Reporter: | iss_mneur | Platform: | Homebrew PC | ||
| Assigned To: | iss_mneur | OS: | Microsoft Windows | ||
| Priority: | normal | OS Version: | 7 x64 Ultimate | ||
| Status: | assigned | Product Version: | 3.6.14 RC6 | ||
| Product Build: | Resolution: | open | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | |||
| Target Version: | |||||
| Summary: | FSO does not correctly detect a sound card that does not support MIN_SOURCES | ||||
| Description: |
FSO does not correctly detect a sound card that does not support MIN_SOURCES (currently 48 sources). Attached is a patch to fix it in a different way than Niffiwan proposes in Mantis 2266. |
||||
| Tags: | |||||
| Steps To Reproduce: |
Using OpenALSoft set the channels to 47 in alsoftrc (see http://repo.or.cz/w/openal-soft.git/blob_plain/HEAD:/alsoftrc.sample) and notice that FSO does not fail the sound card. Note you will have to look in the debug log because the "Generic Software" devices on windows are not affected by the settings in alsoftrc. |
||||
| Additional Information: | Was noticed by Niffiwan in mantis 2266. | ||||
| System Description |
AMD Athlon 64 X2 5600+ 2.80GHz ATI Radeon HD4800 |
||||
| Attached Files: |
openal_sources_checking.patch (2,189 bytes) 2012-07-05 02:03 https://scp.indiegames.us/mantis/file_download.php?file_id=1908&type=bug |
||||
| Notes | |
|
(0013826)
iss_mneur 2012-07-05 02:10 |
My justification for the different implementation in Mantis 2266: "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." |
|
(0013831)
niffiwan 2012-07-05 12:57 |
I like the approach, however it doesn't seem to work properly so far. ALsoft 1.13 doesn't seem to generate the same error codes as 1.14 (sigh). When testing with sources=25 in .alsoftrc I get lots of this in the fs2_open.log: SOUND: sound/ds.cpp:1441 - OpenAL error = 'Invalid Value' When testing with ALSoft 1.14, it seems to cap MAX_CHANNELS too early. i.e. I get this in the log: SOUND: Ran out of sources too soon. Capping MAX_CHANNELS to 12 (was 32) This is with sources=25 in .alsoftrc so I thought it should cap at 25. In two other tests, it capped once at 11, and once at 12. Could it be possible that they are sounds which are started without respecting MAX_CHANNELS? Would that be the original reason for setting MIN_SOURCES to 32+16? FYI, if I set the default sources=256 then no errors are logged (as would be expected). I wasn't sure which branch the patch is based on (r8846 was antipodes?), and I couldn't get it to apply cleanly to 3.6.14, antipodes or trunk (kept complaining about line 28 being invalid?) so I applied this by hand to trunk, r8983. Lastly, with dynamic channel detection in place, would it be worthwhile either removing the initial setting of MAX_CHANNELS, or setting it to something very high, so that those people running ALSoft could make use of all those extra channels? :) (ps - how can you find out how many channels a sound card supports? I had a bit of a google and couldn't find the info for the Xi-Fi - which is just the 1st card I picked to look for) |
|
(0013835)
iss_mneur 2012-07-06 01:47 |
I have no doubt that there is stuff using sources that don't use the channels array (which is where the capping is coming from). I know for sure that the built in but disabled multiplayer player-to-player voice stuff just calls alGenSources directly. Also, as far as I know, the music system also bypasses ds.cpp. That is probably the reason that min sources is 32+16. The patch was against the 3.6.14 branch with the patch from 2266 applied, sorry about that. I have no idea. I also tried googling and it doesn't seem to be something that they (Creative at least) give away freely, I would have thought it would be listed on the spec sheets. You may have more luck googling for the number of "voices" that the card can do, which is how I found that a Creative Card (some X-Fi) does 128 in software, but there was no information about what the hardware could actually do. |