View Issue Details
3203 [FSSCP] scripting crash have not tried 2018-02-12 15:33 2018-02-12 15:33
sbmavroleon  
 
urgent  
new 3.8  
open  
none    
none  
   
Unrecoverable crash at end of first part of a mission
During Act 2 at the end of the mission where the Eva is destroyed, shortly after destroying the Eva and just before receiving new orders, the game crashes, with the bug codes as attached. Reloading the game does not help and I cannot progress with the campaign.

All other friendly ships had been destroyed and I was the only ship (with a support ship) left in game. I destroyed the Eva and it crashed on loading to the new orders screen.
Capture.JPG (80,831 bytes) 2018-02-12 15:33
http://scp.indiegames.us/mantis/file_download.php?file_id=2724&type=bug
jpg
 
There are no notes attached to this issue.




View Issue Details
3202 [FSSCP] user interface minor always 2017-12-08 11:44 2017-12-16 15:39
Hirmuolio  
 
none  
new 3.8  
open  
none    
none  
   
ctrl+shift+S does not work in windowed modes
CTRL+SHIFT+S in techroom mission simulator temporarily unlocks all the missions.

It works in fullscreen.
With "Run in window" enabled it does nothing.
With "Run in fullscreen window" at native resolution (1920x1080) it works.
With "Run in fullscreen window" at not native resolution it does nothing.
Tech room
Set game to windowed mode or fullscreen windowed mode at not native resolution.
 
Notes
(0016914)
MageKing17   
2017-12-14 04:25   
Do you have an AMD video card?
(0016915)
Hirmuolio   
2017-12-16 15:33   
Yes. RX 480.
(0016916)
MageKing17   
2017-12-16 15:39   
One of the default ReLive hotkeys is ctrl+shift+s; it's intercepting the keypress. Change the hotkey in the Radeon control panel and it should work in FSO again.

(Had the exact same problem myself.)




View Issue Details
3201 [FSSCP] localization feature N/A 2017-11-15 18:25 2017-11-17 10:13
Novachen  
 
normal  
new 3.8  
open  
none    
none  
   
Language setting flag
I had another idea because of my translation efforts.

In Between the Ashes with its TrueTypeFont files i encountered the problem, that the font01.vf was ignored by the game and so i was not able to use it to change the language of the game into the desired one like i normally do.

In lack of a better solution i included a BAT file in my BtA-translation that have to be run before the game starts, because it backup and replace the fs2open.ini with a fs2open.ini that include only a "Language=German" entry... and that has the possibility to restore the original file after the player has exited the game.

But actually i do not like it this way, because this requires the player to start another program before he can play the game... and he have to remember to continue the program to restore the old settings after the session.

So i am asking for that better solution which would be a language flag in my opinion which you can integrate into the mod.ini or which you could call in programs like knossos directly.
The -language flag should not be needed by default and the default value would be english of couse.
To prevent errors, it is maybe even a better idea if this one has a higher priority than the entry in the fs2open.ini file if this flag is user activated.
 
Notes
(0016912)
MageKing17   
2017-11-17 09:26   
Changing language on a per-mod basis sounds like a bad idea to me...
(0016913)
Novachen   
2017-11-17 10:13   
Yes maybe. But currently, you have to force a language change over external means and that also require the the user is doing all required steps for that right, because otherwise problems would appear if he tries to play another mod. IMO the current possible solutions are also bad and not much better, because they need always to change the general language of the game.

In the multi language DVD FS2 release there was a Language tab in the Retail Launcher where you were able to switch between English, German and French languages.


But the problem only appeared in a Mod that uses solely TTF files so far. Maybe a change in the TTF-code would also be sufficent, so that the font01.vf is still recognized to set the desired language automatically.




View Issue Details
3200 [FSSCP] user interface minor always 2017-10-20 19:13 2017-10-20 19:20
frsp2op  
 
normal  
new 3.8  
open  
none    
none  
   
Unix/Linux/BSD: program can never get focus when run on pure xorg xserver
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.
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
 
Notes
(0016911)
frsp2op   
2017-10-20 19:20   
it does not matter if program is run in fullscreen or windowed mode




View Issue Details
3198 [FSSCP] gameplay minor always 2017-08-12 08:36 2017-08-13 09:55
Novachen  
 
normal  
new 3.7.5  
open  
none    
none  
   
Support ships give primary weapons
If you do not equip every primary weapon bank with a weapon on a ship during a mission, a called in support ship during the mission will not only restock your missiles, but will equip you with an additional primary weapon (Prom in FSPort and PromR in FS2) for the empty slot.
Copy the attached mission in your data/mission folder. Play the mission and call a Support ship.

Or play a mission where you do not equip a weapon on all your primary slots and call in a support.
Support Ship Test.fs2 (2,250 bytes) 2017-08-12 08:36
http://scp.indiegames.us/mantis/file_download.php?file_id=2723&type=bug
 
Notes
(0016903)
MageKing17   
2017-08-12 22:12   
Support ships adding primary weapons to empty banks was an intentional feature on Volition's part: http://scp.indiegames.us/mantis/view.php?id=3056#c15896

Making the system more customizable would be nice, but it would be a new feature, so it'll need to wait until the current feature freeze is over.
(0016904)
Novachen   
2017-08-13 09:03   
Actually there is a difference between developer/debug and player-features.

This feature make sense for debug and developer reasons, but not for the player, especially if the mission is designed, that you use only one Primary weapon.
At least the support ship should give you a weapon that is allowed in the mission. For example, is the only bank used by a Subach HL-7 and all other weapons are locked, the support ship should give you a HL-7 only, but not a weapon that is not allowed by the mission file.

For me this behaviour is still explainable as an debug-only function, but a bug in a regular build :).

Especially because unused secondary banks get missiles in debug-builds only also afaik.


But whatever, thanks for the reply and i hope this will be fixed soon.
(0016905)
MageKing17   
2017-08-13 09:55   
The feature explicitly exists for mission design purposes, not as a testing function (if it were a debug feature, it would just require a simple keypress... as, in fact, there is such a debug feature for changing a ship's weapons). Now, it's not helpful for the kind of mission you (and others) want to design, and I get that, but that still doesn't make it a bug. That doesn't mean we won't fix it anyway, but it does mean you'll have to wait until after FSO 3.8.0 goes final.




View Issue Details
3192 [FSSCP] localization major always 2017-03-05 03:51 2017-06-24 20:13
Novachen  
 
normal  
confirmed 3.7.4  
open  
none    
none  
   
Freespace look always for the translated strings in the missions, not for the initial default one.
If you translate ranks, medals, weapons and/or shipclass names with the help of XSTR-entries in other languages, you have to use the translated names in the missionfile itself to get them to work, because Freespace2 report errors otherwise, that it can not find a specific weapon/ship/medal/rank during the loading of a mission.
Add a XSTR to any medalname in the medals.tbl to transfer it to a tstrings.tbl, where you set unique names for this medal for any other language.

Now create a mission with a grant-medal SEXP and load this mission in different languages.
In the attachment i include a screenshot of fred2, where you can see the available medals. And the error message that it spawns in the game, if i use a language where this medal have another name.

In this case the name is "Dekoriertes Fliegerkreuz" that have to set in the grant-medal SEXP.
Name Error.7z (113,788 bytes) 2017-03-05 03:51
http://scp.indiegames.us/mantis/file_download.php?file_id=2716&type=bug
MedalTest.7z (6,360 bytes) 2017-03-05 07:57
http://scp.indiegames.us/mantis/file_download.php?file_id=2717&type=bug
MedalTest-2.7z (6,568 bytes) 2017-03-05 08:18
http://scp.indiegames.us/mantis/file_download.php?file_id=2718&type=bug
MedalTest-3.7z (6,578 bytes) 2017-03-05 08:23
http://scp.indiegames.us/mantis/file_download.php?file_id=2719&type=bug
 
Notes
(0016875)
m_m   
2017-03-05 06:50   
Could you create a test mod which reproduces this error based on your reproduction steps? It would make reproducing and fixing this issue much easier.
(0016877)
Novachen   
2017-03-05 07:57   
Yes of course.

Here is a mod you can extract in the freespace folder. select "MedalTest" in Mods and select the campaign with one mission that gets you "Wings" after you jump out.

The german font01.vf for language change is included and activated by default.
(0016880)
Novachen   
2017-03-05 08:19   
There was a faulty medaltest-tlc.tbm.
Missed the #end :/

Sorry about that.
(0016881)
m_m   
2017-03-05 08:40   
Ok, I can reproduce this issue although it causes an error at mission load instead of failing to grant the medal for me.

However, this issue can not be fixed very easily since SEXPs can't use the translated names of anything since they are simply not designed for that. I opened a discussion thread on our GitHub repository so hopefully someone else has an idea how this could be handled: https://github.com/scp-fs2open/fs2open.github.com/issues/1285
(0016901)
Goober5000   
2017-06-24 20:13   
This sounds like the same problem I encountered in Mantis 0002919. The tech-add-intel sexp didn't work with translated intel entry names, so the solution was to add tech-add-intel-xstr.

The same will have to be done for grant-medal, and indeed any sexp where the lookup key is a translated token.




View Issue Details
3197 [FSSCP] FRED minor always 2017-04-24 00:56 2017-04-24 00:56
Hippo Windows  
 
normal  
new  
open  
none    
none  
   
Ship editor initial status screen does not reliably update mission file
The Initial Status window box for speed does not save a value of 0 to the mission file. A non-zero value is saved, but when 0 is entered the "+Initial Velocity: " line disappears from the mission when opened in notepad instead of properly recording 0. This does not occur with hull or shields.

A second, possibly related bug, is that the checkbox for "has shield system" is also not written to the mission file when unchecked. I'm not sure if it's stored as a bool and possibly any 0 values are filtered out for some reason. When the global shield settings are changed, the mission reacts as expected, but that flag is applied as the "no-shields" flag, not a bool on the ship status. I did not test the other 7 settings in that screen.
 
There are no notes attached to this issue.




View Issue Details
3194 [FSSCP] AI crash random 2017-03-29 17:11 2017-04-06 18:39
Danfun64 Acer Aspire 5560  
Xubuntu Linux 64-bit  
urgent 16.04.2  
new 3.7.5  
open  
none    
none  
   
Inexplicable crashing that might be related to AI
I am running the latest 3.7.5 trunk build. For whatever reason, the mission "The Hammer and the Anvil" on FSPort crashes randomly, sometimes the moment you first send your ship to space, sometimes when ships appear, sometimes when ships are attacked.
fs2_open.log (64,792 bytes) 2017-03-29 17:11
http://scp.indiegames.us/mantis/file_download.php?file_id=2720&type=bug
gdb.txt (1,722 bytes) 2017-03-29 17:11
http://scp.indiegames.us/mantis/file_download.php?file_id=2721&type=bug
 
Notes
(0016889)
niffiwan   
2017-04-01 21:24   
(Last edited: 2017-04-01 21:25)
Could you please advise which git commit hash you built FSO from?

Also; seems more to be a model-code issue rather than an AI issue?

ASSERTION: "handle == bm_bitmaps[n].handle" at bmpman.cpp:982

Assert: "handle == bm_bitmaps[n].handle"
File: bmpman.cpp
Line: 982

  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : os::dialogs::AssertMessage(char const*, char const*, int, char const*, ...)+0x2e5
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : bm_has_alpha_channel(int)+0x96
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : model_render_buffers(model_draw_list*, model_material*, model_render_params*, vertex_buffer*, polymodel*, int, int, unsigned int)+0xfae
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : submodel_render_queue(model_render_params*, model_draw_list*, int, int, matrix*, vec3d*)+0x5e5
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : debris_render(object*, model_draw_list*)+0x347
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : obj_queue_render(object*, model_draw_list*)+0x1f5
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : obj_render_queue_all()+0x239
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : game_render_frame(camid)+0x34f
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : game_frame(bool)+0x375
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : game_do_frame()+0xbe
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : game_do_state(int)+0x154
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : gameseq_process_events()+0x136
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : game_main(int, char**)+0x170
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : actual_main(int, char**)+0xc7
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : main()+0x20
  /lib/x86_64-linux-gnu/libc.so.6 : __libc_start_main()+0xf0
  /home/danfun64/Documents/freespace/fs2_open_3_7_5_x64-DEBUG : _start()+0x29

(0016890)
Danfun64   
2017-04-02 15:09   
I'm pretty sure it's commit 353c281.
(0016891)
Danfun64   
2017-04-05 02:04   
So...what should be done now?
(0016892)
Danfun64   
2017-04-06 18:39   
I have updated to commit 36ae38a. I ended up getting a more helpful error message, or at least, more obvious to non programmers.

"Error: Model 1504 ('Poseidon.pof') must have at least one point from submodel_get_points_internal!
File: modelinterp.cpp
Line: 1275"




View Issue Details
3190 [FSSCP] FS2NetD minor always 2017-01-30 02:58 2017-01-30 02:58
jg18  
 
normal  
new  
open  
none    
none  
   
FS2NetD website displays negative scores incorrectly
FS2NetD website's stats page displays negative scores as extremely high scores.
Go to http://fs2netd.game-warden.com/?area=stats

Notice the top 5 pilot scores are extremely high.
The problem is that FS2NetD is storing the pilot's score as an unsigned 32-bit integer, while FSO is correctly storing the pilot score as a signed 32-bit int. Thus negative scores are appearing on the FS2NetD site as very high positive scores.

The solution is to fix FS2NetD so that it stores the pilot score as a signed 32-bit integer.
 
There are no notes attached to this issue.




View Issue Details
3021 [FSSCP] tables minor always 2014-03-16 23:02 2017-01-20 14:35
Spoon  
DahBlount  
normal  
assigned 3.7.0  
open  
none    
none  
   
"target requires fov" flag does not take $Turret Base FOV: in account
Causing turrets to remain idle instead of firing at an other valid target within range.
basefov.png (424,955 bytes) 2014-03-16 23:40
http://scp.indiegames.us/mantis/file_download.php?file_id=2337&type=bug
 
Notes
(0016747)
DahBlount   
2015-06-14 14: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 19:16   
https://github.com/scp-fs2open/fs2open.github.com/pull/184 Pull Request
(0016749)
FUBAR-BDHR   
2015-06-14 22:06   
Already a flag for this: "only target if can fire"
(0016750)
Spoon   
2015-06-14 22:26   
"only target if can fire" is useless and doesn't do anything in this case.
(0016752)
FUBAR-BDHR   
2015-06-14 23: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 14: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.




View Issue Details
2367 [FSSCP] graphics minor have not tried 2010-12-30 21:40 2017-01-10 14:42
FUBAR-BDHR  
 
normal  
new 3.6.13  
open  
none    
none  
   
Any animation with thruster in the name will not load and gives no error
Ran into this while testing the thruster cone issue. I was testing with the retail cone ani files named thruster01.ani and thruster03.ani. Changing the texture in pcs2 to match the names and renaming the thruster cone from thruster01a to conea did not work in the lab or game. Changing to another .eff file did work. Going on the assumption that it just didn't like .ani files I picked one of our other thruster effects named Col_Thruster_Main.eff. It didn't work. Tried a simple .dds file Thruster_Col_Helo.dds. That did load. Tried a different effect with thruster in the name. Didn't work. Finally renamed the retail .ani file to cone3.ani. Worked.

Now the interesting part is that there is nothing in the log about the textures (not counting the ones that were loaded as thrusters for other reasons). For example thruster03.ani only used in the test did not exist at all in the log with the exception of when I tested with $Thruster Flame Effect: in weapons.tbl and the parse entry showed. Using a filename that didn't exist did produce the expected error message.
Unfortunately changing the name of the retail .ani file in both the .pof and directory still did not fix the cone issue so they are 2 separate bugs.
 
Notes
(0012584)
FUBAR-BDHR   
2010-12-30 21:43   
Forgot one. Testing with Thruster_x as a texture name in PCS2 that did not exist did not give an error either in the lab or game.
(0016849)
DahBlount   
2017-01-10 14:42   
Which directory have you place the animation files into?




View Issue Details
2986 [FSSCP] lab minor sometimes 2013-12-24 14:37 2017-01-10 14:41
DahBlount  
 
normal  
confirmed  
open  
none    
none  
   
Certain lists in the ship lab extend beyond screen.
For example, in Blue Planet, the ship lists of certain species will extend beyond the screen, making it difficult to look at certain ships.
Have A LOT of ships used in a mod.
Forum thread about this issue: http://www.hard-light.net/forums/index.php?topic=86400.0
wmcgui.diff (17,935 bytes) 2014-01-13 21:26
http://scp.indiegames.us/mantis/file_download.php?file_id=2321&type=bug
 
Notes
(0015573)
z64555   
2014-01-13 21:25   
Yeah, this is going to take some time to resolve. The WMC's gui system seems to have been a quick prototype of sorts that hasn't really been touched in quite a while.

The attached .diff just divides up each of the major gui elements into their own file, pretty much the start of some needed code organization.

In order to get a scrollbar object, we'll have to first make some resizing functions for the guiWindows and others. I've got some other projects open at the moment that need resolution, so anyone is free to give this issue a shot. :)
(0016296)
Goober5000   
2014-09-24 10:29   
Not critical for 3.7.2.
(0016848)
DahBlount   
2017-01-10 14:41   
I believe we now have horizontal sliders in wmcgui thanks to Swifty. Considering the new code freeze, would the addition of vertical sliders to the ship and weapon lists remain unmerged until after 3.8?




View Issue Details
3006 [FSSCP] FRED minor sometimes 2014-02-06 21:12 2017-01-01 18:09
GeneralBattuta PC  
Windows  
low Windows 7 64 bit  
confirmed 3.7.1  
open  
none    
none  
   
FRED crashes when left open and idle for long periods of time.
By Kara's request -

FRED locks up and stops responding when left idle for long periods of time. This may be tied to OS sleep/hibernation behavior, but it's not clear. While a bunch of people have confirmed encountering this bug and some think it's tied to leaving the events window open, others don't get encounter it at all.

I don't think this issue is a major priority. It's only a serious concern when the FREDder has to leave the computer without saving and can't return for a long time (a pretty rare use case unless, well, you are being dragged away, which is not a bad problem to have but which can really set your missions back!).
We're working to narrow this down. I'm gonna try leaving FRED on overnight WITHOUT the events window open to see if that alters the outcome.
vector subscript.png (84,171 bytes) 2016-12-29 23:55
http://scp.indiegames.us/mantis/file_download.php?file_id=2713&type=bug
png

Clipboard01.png (121,925 bytes) 2016-12-31 15:38
http://scp.indiegames.us/mantis/file_download.php?file_id=2714&type=bug
png
 
Notes
(0015621)
Echelon9   
2014-02-09 08:33   
Could be a memory leak of some form.
(0015695)
Goober5000   
2014-03-31 11:57   
Has there been any progress on this?
(0016841)
Goober5000   
2016-12-29 23:59   
Attached a screenshot from Brian See, reported in this thread:
http://www.hard-light.net/forums/index.php?topic=92943.0

This makes things more interesting. Just spitballing here - I wonder if the Event Editor is updating some sort of log, tally, or other vector-based structure, and leaving the window open for a long time causes the index to exceed INT_MAX.
(0016842)
Axem   
2016-12-31 15:39   
I managed to reproduce something sorta related. The same error message as Bryan See anyway. I added a bunch of new messages and events in the event editor, let it sit for like 3 hours and when I hit the okay button, I got that error message.
(0016843)
Axem   
2016-12-31 15:39   
(Should note I attached a picture of the debugger trying to trace it down, its something messages related)
(0016844)
Axem   
2016-12-31 15:45   
Okay, after trying again, this happens all the time with Debug FRED. No idling required. It'll happen all the time if you add a message and then click OK in the event editor.

It may not be the same bug, but it is a bug.
(0016845)
MageKing17   
2017-01-01 00:42   
Well, I've opened a PR for at least the issue Axem reported (since I could actually reproduce it): https://github.com/scp-fs2open/fs2open.github.com/pull/1123
(0016846)
Goober5000   
2017-01-01 17:49   
I was going to look into this today but I see MageKing17 already beat me to it, with the correct identification and solution. :yes:

That doesn't fix the root cause of the idling bug, though, since OnOk only runs when you click Ok.

While looking into this I found another issue, for which I've opened a PR here:
https://github.com/scp-fs2open/fs2open.github.com/pull/1124
(0016847)
MageKing17   
2017-01-01 18:09   
I wouldn't rule out PR 0001123 fixing the idling bug; given that it was writing past the end of the vector, we were in nasal demon territory. The undefined behavior could very well have meant that, if messages were added and ok was clicked at least once, FRED could've been left in a "ticking time bomb" state that made a future crash inevitable. We won't know for sure until/unless the idling crash happens again in the future.




View Issue Details
3180 [FSSCP] turrets minor always 2016-06-21 18:05 2016-11-22 16:15
Spoon  
 
normal  
new 3.7.4 RC1  
open  
none    
none  
   
Protect ship - Turret threats: Laser protect ship also causes it to be protected from beams, turrets still track.
Setting a ship to be laser protected from turrets causes beam turrets (at least confirmed on multi part turrets) to also not fire on the target. They do still track the target, but never fire.
When the target is beam protected, the turrets do no track.
 
Notes
(0016831)
MageKing17   
2016-07-29 22:56   
Is this beam weapon perchance defined in a "#Primary Weapons" block (or have a "$Subtype: Primary" line)?
(0016835)
Spoon   
2016-11-22 16:15   
Yes, every beam in the table is under #Primary weapons. Just like the retail weapons.tbl, the #Beam Weapons block there is empty too. So if this is the cause, then it affects probably every mod and retail too. I've never used $Subtype: anywhere myself.




View Issue Details
3181 [FSSCP] turrets minor always 2016-06-21 18:09 2016-07-29 22:39
Spoon  
The_E  
normal  
assigned 3.7.4 RC1  
open  
none    
none  
   
Fire on target flag causes turrets to ignore their rotation speeds
It's super noticable with beams on multi part turrets
As shown here: https://my.mixtape.moe/fehacj.webm
These turrets are suppose to have a 360 degree rotation of 10 seconds. Yet they track and lead the target (in this case, me) at speeds they shouldn't be able to.

Excuse all the other laser bolts obscuring the vision. I'd laser protect myself, but it turns out that's another thing that is bugged. Which I reported here: http://scp.indiegames.us/mantis/view.php?id=3180
 
Notes
(0016828)
Spoon   
2016-06-21 18:31   
(Last edited: 2016-06-21 18:32)
Why does mantis not come with an edit button? (Or am I too blind to see it? At least these notes have a edit button)
My initial report was not actually super clear but I am not allowed to edit (or delete) a report.

So to elaborate: Fire on target flag causes turrets to ignore their rotation speeds when firing beams.
A better webm to illustrate the issue: https://my.mixtape.moe/fgdjde.webm
Notice how slow these turrets rotate, until they fire on their target. Then they suddenly start tracking the target at rotation speeds way above their tabled value

(0016829)
The_E   
2016-07-14 17:05   
Could you try this build to see if it's fixed? https://www.dropbox.com/s/ui5vd5us14txemw/fs2_open_3_7_5.7z?dl=0
(0016830)
Spoon   
2016-07-29 22:39   
I remembered today I reported things on mantis, and only saw your added note today. Mantis used to send me an email before when someone added something to a mantis issue, but it seemingly couldn't be bothered to do so this time around. So my apologies for not responding to this sooner.

Tried the build, alas, issue not fixed.




View Issue Details
2865 [FSSCP] graphics crash always 2013-05-06 21:52 2016-06-17 17:14
Yarn x64  
Echelon9 Windows 7  
normal  
assigned 3.6.19  
open  
none    
none  
   
"Assert: num == bm_bitmaps[n].handle" in FSPort SM3-03a when -fb_explosions is enabled
In FSPort's SM3-03a ("A Failure to Communicate"), when the Aquilae Installation explodes shortly after the mission begins, the game crashes with "Assert: num == bm_bitmaps[n].handle" if all of the following conditions are met:

1. A debug build is being used.
2. The MediaVPs are enabled.
3. Both -3dshockwaves (Enable 3D shockwaves) and -fb_explosions (Enable Framebuffer Shockwaves) are enabled.
4. The player is looking at the explosion.

I have confirmed this in versions 3.6.14 and later (I couldn't get FSPort 3.4 to work in earlier builds). The build's SSE/AVX version makes no difference.
Here is the full error message:

Assert: num == bm_bitmaps[n].handle
File: bmpman.cpp
Line: 961

ntdll.dll! NtWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! SCP_DumpStack + 247 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! WinAssert + 176 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! bm_is_compressed + 125 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! bm_get_tcache_type + 18 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! gr_opengl_tcache_set + 54 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! gr_opengl_render_effect + 342 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! geometry_batcher::render + 112 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! batch_render_distortion_map_bitmaps + 283 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! game_render_frame + 970 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! game_frame + 697 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! game_do_frame + 210 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! game_do_state + 358 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! gameseq_process_events + 211 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! game_main + 730 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! WinMain + 265 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! invoke_main + 30 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! __scrt_common_main_seh + 346 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! __scrt_common_main + 13 bytes
fs2_open_3_7_5_AVX_20160616_b2fc335-DEBUG.exe! WinMainCRTStartup + 8 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes
 
Notes
(0015039)
Echelon9   
2013-05-07 08:07   
I'm seeing the Assert() under that repro case as per below, although I had to set -no_glsl due to Mantis 2861:

ASSERTION FAILED: "Scene_depth_texture != 0" at code/graphics/gropengldraw.cpp:1468

0 libsystem_kernel.dylib 0x00007fff9318f212 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff92c86b54 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff92ccadce abort + 143
3 FS2_Open (debug) 0x000000010261e64a WinAssert(char*, char*, int) + 938
4 FS2_Open (debug) 0x000000010037e221 gr_opengl_render_effect(int, vertex*, float*, unsigned int) + 1777 (gropengldraw.cpp:1468)
5 FS2_Open (debug) 0x000000010099d775 geometry_batcher::render(int, float) + 1765 (grbatch.cpp:527)
6 FS2_Open (debug) 0x00000001009a9222 batch_render_distortion_map_bitmaps(bool) + 1458 (grbatch.cpp:917)
7 FS2_Open (debug) 0x00000001002f1063 game_render_frame(camid) + 7731 (freespace.cpp:3777)
8 FS2_Open (debug) 0x00000001002fa562 game_frame(bool) + 6450 (freespace.cpp:4538)
9 FS2_Open (debug) 0x00000001002ff62c game_do_frame() + 604 (freespace.cpp:4917)
10 FS2_Open (debug) 0x000000010030b167 game_do_state(int) + 871 (freespace.cpp:6594)
11 FS2_Open (debug) 0x00000001009146b9 gameseq_process_events() + 1273 (gamesequence.cpp:405)
12 FS2_Open (debug) 0x0000000100311a07 game_main(char*) + 2071 (freespace.cpp:7160)
13 FS2_Open (debug) 0x00000001003130a5 SDL_main + 3781 (freespace.cpp:7294)




View Issue Details
2869 [FSSCP] FRED minor always 2013-05-11 05:56 2016-04-17 15:07
FUBAR-BDHR  
 
normal  
new 3.6.19  
open  
none    
none  
   
Changing AI class of a group of ships can mess up departure cues
Changed the AI class on 4 ships, 3 part of alpha wing and one individual ship. Saved the mission and received several warnings about ships needing a valid departure anchor. This was followed by the following warning: Ship name "<error>" referenced, but this ship doesn't exist.

Create new missions with 4 fighters as Alpha wing. Drop in a ship with a docking bay. Add a bomber. Set Alpha wing to depart via docking bay with a time delay. Do the same for the bomber. Save the mission.

Attached mission has the above done.

Select Alpha 2,3,4 and the bomber. Open the ship editor. Change AI class to general. Hit next or previous. Save mission (good idea to give it a new name).
r9673. The bug does not occur if the bomber is set to depart via hyperspace. I haven't tested changing any other values or departure combinations since it's almost 7am and even staying awake to do a test mission for this report was hard enough.
2869.fs2 (6,753 bytes) 2013-05-11 05:56
http://scp.indiegames.us/mantis/file_download.php?file_id=2195&type=bug
 
Notes
(0016827)
FSF   
2016-04-17 15:07   
Issue still present in 3.7.5. The ship editor dialog takes over the departure location (hyperspace/docking bay) from the bomber (as that one is not in a wing), and subsequently applies it to all selected ships (see CShipEditorDlg::update_ship()). However, the departure anchor (the owner ship of the docking bay) is only applied if the ship is not in a wing. The ships in Alpha now have a docking-bay departure set without ship, causing <error> to be written to the mission.

Solution proposed in PR 595, only setting departure/arrival locations if selected ship is not part of a wing.




View Issue Details
2876 [FSSCP] FRED graphics minor always 2013-05-16 22:08 2016-03-29 06:52
FUBAR-BDHR  
 
normal  
new 3.6.19  
open  
none    
none  
   
No warning and background not rendered if first sun doesn't exist
If the first sun listed in the mission does not exist you do not get the warning that you should and the entire background for the mission does not load. All you get is the stars and the default sun. Now if the missing sun is not the first one you get the warning that it doesn't exist and the background does render correctly (minus the bad sun entry of course). Also in either case if you try to go into the background editor you will get the correct warning and the background will render.
Edit a mission in notepad and change the name of the first sun to something you know doesn't exit in stars.tbl. Save the mission and open in FRED. You should get no warning and no backgroud. Save the mission and notice again no warning. Now open the background editor and you will get the warning and the background will render. Next edit the mission in notepad again but this time make the fist sun a valid entry and the second one the bad one (copy/paste the first one if the mission only has one). Save that and load in FRED. Notice you will get the error that the sun isn't valid.

To save time I'm attaching 2 copies of SM1-01. First one has the star changed to an invalid name. Second one has a second invalid star added.
SM1-01_no_exist.FS2 (68,247 bytes) 2013-05-16 22:08
http://scp.indiegames.us/mantis/file_download.php?file_id=2200&type=bug
SM1-01_not_first.FS2 (68,317 bytes) 2013-05-16 22:09
http://scp.indiegames.us/mantis/file_download.php?file_id=2201&type=bug
 
Notes
(0016823)
FSF   
2016-03-28 08:30   
Issue no longer occurs in 3.7.5; warning is displayed and background is rendered for both of the attached missions.

Suggest issue be closed.
(0016824)
MageKing17   
2016-03-29 06:52   
(Last edited: 2016-03-29 06:52)
My first thought is that this was probably fixed by PR433 (https://github.com/scp-fs2open/fs2open.github.com/pull/433), but it would be nice if somebody could confirm when this got fixed.





View Issue Details
2023 [FSSCP] camera code minor N/A 2009-11-09 23:40 2016-03-23 06:03
chief1983  
Admiral MS  
high  
assigned 3.6.11  
open  
none    
none  
  3.8  
Additional tools and/or help needed for camera coordinate systems
Bug retitled/redescribed due to Admiral MS's information (see "additional information" section and his ticket comment).

More specifically, not all of the coordinate systems in FRED align with the camera and orientation code. More documentation and user interface enhancement needs to be done to allow users to operate with the two different coordinate systems without getting confused. They might assume that lessons in one system can be applied to the other, where this is not necessarily the case.

It would be nice to provide a FRED widget to calculate/convert between one coordinate system and another.
Admiral MS said the following:

I took a look at this and there seems to be no difference between camera and ingame coordinate systems:
- I found no transformation anywhere in camera code that would change something from the ingame coordinates
- Using a script to display Position and Orientation of a ship and its camera revealed them to be identical (scripting includes no tranformations)
- FRED uses the same axes that are used ingame

What I found:
- The background editor in FRED uses a completely different definition of pitch bank and heading that doesn't align with ingame coordinates
- The input of set-object-orientation is defined as going from 0 to 360° for pitch, bank and heading while ingame these have different ranges (heading and bank: -90° to 270°, pitch: -90° to 90° to -90°)
- Guessing an orientation for a random direction and bank angle is nearly impossible in the system used, it has to be calculated
- Before the camera code and scripting were added set-object-orientation was the only sexp that allowed to modify the actual object orientation, so people may have a wrong idea of how the orientation works


Obiously there is a chance I missed something - I didn't check every single line of code that is somehow related to cameras.
 
Notes
(0011249)
chief1983   
2009-11-12 02:04   
Changing to a new category I made.
(0012338)
Goober5000   
2010-08-29 01:08   
To elaborate, the X, Y, and Z axes don't correspond with the X, Y, and Z axes defined by the game or FRED.

Chief, you'll need to go ahead and assign this to somebody because it'll have to be fixed before use of the camera code becomes more widespread.

And before you assign it to me, please note that I haven't had time to look at it in the past eight months. :p
(0013350)
Echelon9   
2012-02-23 23:41   
Is this still a present issue?

I've seen plenty of uses of the camera system since 2010, is there an employed system of getting around this issue if it still exists by FREDers?
(0013360)
Goober5000   
2012-02-24 22:18   
It's still an issue, because the coordinate axes haven't changed.

What this needs is documentation to explain exactly what the axes correspond to. And maybe a mod.tbl setting to control whether or not the axes line up with the FRED axes.
(0014941)
Admiral MS   
2013-04-21 07:04   
(Last edited: 2013-04-21 07:06)
I took a look at this and there seems to be no difference between camera and ingame coordinate systems:
- I found no transformation anywhere in camera code that would change something from the ingame coordinates
- Using a script to display Position and Orientation of a ship and its camera revealed them to be identical (scripting includes no tranformations)
- FRED uses the same axes that are used ingame

What I found:
- The background editor in FRED uses a completely different definition of pitch bank and heading that doesn't align with ingame coordinates
- The input of set-object-orientation is defined as going from 0 to 360° for pitch, bank and heading while ingame these have different ranges (heading and bank: -90° to 270°, pitch: -90° to 90° to -90°)
- Guessing an orientation for a random direction and bank angle is nearly impossible in the system used, it has to be calculated
- Before the camera code and scripting were added set-object-orientation was the only sexp that allowed to modify the actual object orientation, so people may have a wrong idea of how the orientation works


Obiously there is a chance I missed something - I didn't check every single line of code that is somehow related to cameras.

(0014943)
chief1983   
2013-04-21 10:49   
That is interesting to note, thanks for looking into that.
(0015145)
Goober5000   
2013-06-23 18:19   
Ticket rewritten based on Admiral MS's discovery. Many thanks to him for transforming the problem from something vague and poorly specified to something concrete.

(And yeah, I should have done this updating back in April. :p)
(0015935)
Goober5000   
2014-06-29 18:53   
Since Admiral MS is now a developer, I'm assigning this to him to see if he'd be willing to take a stab at squashing it.
(0016819)
MageKing17   
2016-03-23 06:03   
Bumping target.




View Issue Details
2942 [FSSCP] localization major sometimes 2013-10-26 00:41 2016-03-23 06:03
Goober5000  
Goober5000  
high  
assigned  
open  
none    
none  
  3.8  
XSTR indexes can cause string overflows in mods
Actually the problem isn't so much string overflows, it's different strings, period. See this thread for a full description of the problem:
http://www.hard-light.net/forums/index.php?topic=85041.msg1716600#msg1716600

A feature should be added to lcl_ext_localize so that it returns a special value if the "default language" localized string is a different size from the untranslated string. The mission listing code should check this flag and not add missions to the list whose titles differ in this way.
 
Notes
(0016818)
MageKing17   
2016-03-23 06:03   
Bumping target.




View Issue Details
2840 [FSSCP] docking minor always 2013-04-08 09:25 2016-03-23 06:02
MjnMixael PC  
Goober5000 Windows  
normal Win7  
assigned 3.6.19  
open  
none    
none  
  3.8  
Docking Paths not obeyed on multiple docking attempts.
The new Bast has a docking animation set to work with the straight path of the VC 3. Bast docks once following the path exactly. But the second time it docks, it does so at completely wrong angles which causes clipping.

As docking animations become the norm, it's important to make sure they will work each time, every time.
Download the test mod from here: http://www.mediafire.com/?rk5ef55jx6g9jew

Play the Bast Test mission.

1) Alt-X to order docking and wait until docking is complete.
2) Shift-N to order undocking and wait until the Bast has moved away from the VC3.
3) Alt-X to order docking again.
4) Bug during docking procedure.
5) Repeat as much as you want in the same mission.
NVIDIA GeForce GTX 550 Ti
 
Notes
(0014913)
Goober5000   
2013-04-08 21:28   
Well poo. In early 2012, Vasudan Admiral and I tried to sort out all the bugs with the docking animations. We eventually found about 24 separate use cases and fixed them all except for maybe a half-dozen very tricky situations. This may be one of those. (Or even a new one...)
(0016817)
MageKing17   
2016-03-23 06:02   
Bumping target.




View Issue Details
3141 [FSSCP] Pilot data minor have not tried 2015-02-09 04:23 2016-03-23 06:02
niffiwan x86_64  
niffiwan Linux Mint  
normal 17  
assigned 3.7.2 RC5  
open  
none    
none  
  3.8  
AddressSanitizer: heap-buffer-overflow in pilotfile::update_stats_backout()
==12331== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602c000605dc at pc 0xc18240 bp 0x7fff3b676ec0 sp 0x7fff3b676eb8
READ of size 4 at 0x602c000605dc thread T0
    #0 0xc1823f in pilotfile::update_stats_backout(scoring_struct*, bool) /home/mememe/src/fs2open.github.com.niffiwan/code/pilotfile/pilotfile.cpp:290
    0000001 0x90a8dd in debrief_close() /home/mememe/src/fs2open.github.com.niffiwan/code/missionui/missiondebrief.cpp:2094
    0000002 0x41ef30 in game_leave_state(int, int) /home/mememe/src/fs2open.github.com.niffiwan/code/freespace2/freespace.cpp:5618
    0000003 0x5b6c1c in gameseq_set_state(int, int) /home/mememe/src/fs2open.github.com.niffiwan/code/gamesequence/gamesequence.cpp:279
    0000004 0x41e0c1 in game_process_event(int, int) /home/mememe/src/fs2open.github.com.niffiwan/code/freespace2/freespace.cpp:5184
    0000005 0x5b7847 in gameseq_process_events() /home/mememe/src/fs2open.github.com.niffiwan/code/gamesequence/gamesequence.cpp:399
    0000006 0x4218f5 in game_main(char*) /home/mememe/src/fs2open.github.com.niffiwan/code/freespace2/freespace.cpp:7153
    0000007 0x421e45 in main /home/mememe/src/fs2open.github.com.niffiwan/code/freespace2/freespace.cpp:7288
    0000008 0x7fc8f1b37ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287
    0000009 0x40c6c8 in _start ??:?
0x602c000605dc is located 36 bytes to the right of 376-byte region [0x602c00060440,0x602c000605b8)
allocated by thread T0 here:
    #0 0x7fc8f47044e5 in calloc ??:?
    0000001 0x7fc8f36ee03b in glXCreateNewContext ??:?
Shadow bytes around the buggy address:
  0x0c0600004060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0600004070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
  0x0c0600004080: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c0600004090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c06000040a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c06000040b0: 00 00 00 00 00 00 00 fa fa fa fa[fa]fa fa fa fa
  0x0c06000040c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06000040d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06000040e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06000040f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0600004100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable: 00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone: fa
  Heap righ redzone: fb
  Freed Heap region: fd
  Stack left redzone: f1
  Stack mid redzone: f2
  Stack right redzone: f3
  Stack partial redzone: f4
  Stack after return: f5
  Stack use after scope: f8
  Global redzone: f9
  Global init order: f6
  Poisoned by user: f7
  ASan internal: fe
==12331== ABORTING
This occurred when I clicked on "Accept" after playing SM3-06 from the techroom.
I was looking for a different bug!
 
Notes
(0016815)
MageKing17   
2016-03-23 06:02   
Bumping target.




View Issue Details
2715 [FSSCP] gameplay major always 2012-09-22 15:35 2016-03-23 06:02
MatthTheGeek  
niffiwan Windows 7  
normal  
assigned 3.6.13  
open  
none    
none  
  3.8  
Weapons are always loaded on top banks when some banks are empty
If some banks are left empty on the loadout screen, whatever weapons were selected in the other banks will be shifted toward the top banks.
For example if on the loadout screen you have :
Bank 1: empty
Bank 2: weapon 1
Bank 3: weapon 2

In mission you will have
Bank 1: weapon 1
Bank 2: weapon 2
Bank 3: empty

This is potentially heavily balance-breaking as it can alow a player to entirely bypass per-bank weapon restrictions, like for example loading an Archer on the hexa bank of an Uriel instead of the single underslung bank.

Confirmed with both primary and secondary banks.
Load a mission with ships that have at least two banks.

Put weapons only in bottom bank(s).

Load mission.

Watch in external mode what bank is actually firing when you fire.
 
Notes
(0013969)
MatthTheGeek   
2012-09-22 15:55   
Also confirmed with both 2-bank and 3-bank configurations. Tested on latest trunk, but it very much sounds like it is a retail-era bug.
(0014042)
niffiwan   
2012-11-16 03:38   
(Last edited: 2012-11-16 03:47)
This is going to be... interesting. The observed behaviour is "as designed". i.e. the loadout code removes any missing weapon entries & moves the weapons in the banks 2+ towards bank 1. This is done because there's an assumption in many places (e.g. firing primaries, switching secondaries, drawing the HUD, probably other places as well) that the ship weapon array starts at zero, there are no gaps/empty banks, and the number of full banks is the number of banks on the ship.

Since this will need a fair bit of refactoring to fix, I think it should be deferred until 3.7.2. It might be an opportunity to refactor all the loadout code at the same time.

edit: also discussed on the IRC whether a possible fix could be preventing the loadout screen from exiting if there were any gaps in the banks. However, this would prevent FREDers from deliberately leaving banks empty if they wished to in their missions.

(0014043)
MjnMixael   
2012-11-16 09:03   
Perhaps a decent work around until then is to create a 'dummy' weapon called Empty and doesn't fire?

Of course the player would have to know to specifically choose to place it where needed...
(0014429)
FUBAR-BDHR   
2012-12-12 14:45   
I was thinking about this last night for some strange reason. What about adding a int primary_bank_flags[MAX_SHIP_PRIMARY_BANKS] and secondary_bank_flags[MAX_SHIP_SECONDARY_BANKS] to the ship_weapon struct. Then a flag such as "unloaded" could be added and checked to leave that weapon there but make it not usable. Additional flags could be added such as "no-rearm" that would prevent reloading of a particular weapon by support and "no-hud" that would work with "unloaded" to not display the weapon on the hud.

These could be set in ships table and altered in FRED. This would also provide a way to fix 0002355 as well as allow for other future features.
(0014430)
MjnMixael   
2012-12-12 14:52   
I could see myself even using a system like that. It's basically a feature request then, though.. so perhaps this (already is) and 2355 should be re-targeted for 3.7.2.
(0014431)
niffiwan   
2012-12-12 16:17   
Thanks for the suggestion, that's more flexible than what I had been thinking of which would have only dealt with the equivalent of the "unloaded" flag.
(0016814)
MageKing17   
2016-03-23 06:02   
Bumping target.




View Issue Details
2139 [FSSCP] gameplay minor random 2010-02-23 19:42 2016-03-20 17:22
FUBAR-BDHR  
 
normal  
new 3.6.11  
open  
none    
none  
   
AI will fire secondaries at start when mission is restarted
Reminds me of the old multiplayer lag bug that would cause secondaries attempting to be fired before respawn to fire after respawn. This is in single though. I've reproduced it 2 ways. First was dying and hitting replay. Second was just hitting escape and doing a replay mission. The weapons fired were aspect seekers and just flew straight.

If I restarted immediately before any enemy fighters were within range it did not seem to happen.
3.6.11 r5919. This was in Diaspora but nothing really out of the ordinary. Fighters, aspect seekers (corkscrew but single fire) some new AI features, etc but nothing that should cause a missile to fire after restart. I'm going to keep an eye out for it in other places.
 
Notes
(0014592)
karajorma   
2012-12-30 10:44   
If the cause is what I think it is, I doubt the cause is exactly the same (the multiplayer bug appears to be caused by the control info not being wiped properly, this shouldn't affect an AI ship).

That said, it does sound very similar.




View Issue Details
2871 [FSSCP] FRED minor always 2013-05-11 22:50 2016-03-20 17:17
FUBAR-BDHR  
 
normal  
new 3.6.19  
open  
none    
none  
   
Invalid AI class on turret causes FRED to stop responding
Opened up an old mission in FRED. Apparently the entire campaign was made at a time when the AI classes had different names. This hadn't been an issue with ships since the engine just defaults to the first AI class and then you can change it if you want. This mission in particular had the old AI classes assigned to turrets as well as the ship itself. FRED really doesn't like that. This needs to be caught, a warning thrown, and defaulted to valid values just like with the ship.
Option 1:
Open FRED. Drop in a ship with turrets. Save mission. Assign invalid AI class to some of the turrets. Looks like this ability was removed from FRED probably because it didn't work so you will need to notepad them in. Open mission in FRED.

Option 2:
Open attached mission.
Stack Dump:

     fred2_open_3_6_19_SSE2-DEBUG.exe!strlen(unsigned char * buf) Line 69 Asm
     fred2_open_3_6_19_SSE2-DEBUG.exe!std::char_traits<char>::length(const char * _First) Line 491 + 0x9 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!std::basic_string<char,std::char_traits<char>,SCP_vm_allocator<char> >::append(const char * _Ptr) Line 840 + 0x9 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!std::basic_string<char,std::char_traits<char>,SCP_vm_allocator<char> >::operator+=(const char * _Ptr) Line 784 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!vsprintf(std::basic_string<char,std::char_traits<char>,SCP_vm_allocator<char> > & dest, const char * format, char * ap) Line 3701 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFred_mission_save::fout(char * format, ...) Line 3040 + 0x11 bytes C++
> fred2_open_3_6_19_SSE2-DEBUG.exe!CFred_mission_save::save_turret_info(ship_subsys * ptr, int ship) Line 3853 + 0x21 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFred_mission_save::save_common_object_data(object * objp, ship * shipp) Line 2221 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFred_mission_save::save_objects() Line 1467 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFred_mission_save::autosave_mission_file(char * pathname) Line 247 + 0x8 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFREDDoc::autosave(char * desc) Line 278 + 0xd bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFREDDoc::OnOpenDocument(const char * pathname) Line 180 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CSingleDocTemplate::OpenDocumentFile(const char * lpszPathName, int bAddToMRU, int bMakeVisible) Line 169 + 0x14 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CDocManager::OpenDocumentFile(const char * lpszFileName, int bAddToMRU) Line 1068 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CDocManager::OpenDocumentFile(const char * lpszFileName) Line 977 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWinApp::OpenDocumentFile(const char * lpszFileName) Line 90 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWinApp::OnOpenRecentFile(unsigned int nID) Line 147 + 0x2a bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void (void)* pfn, void * pExtra, unsigned int nSig, AFX_CMDHANDLERINFO * pHandlerInfo) Line 101 + 0xa bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CCmdTarget::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 381 + 0x27 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFrameWnd::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 978 + 0x23 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWnd::OnCommand(unsigned int wParam, long lParam) Line 2729 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFrameWnd::OnCommand(unsigned int wParam, long lParam) Line 371 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 2101 + 0x1e bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam) Line 2087 + 0x20 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 257 + 0x1c bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 420 C++
     user32.dll!758862fa()
     [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
     user32.dll!75886d3a()
     user32.dll!75886ce9()
     user32.dll!758877c4()
     user32.dll!75887bca()
     fred2_open_3_6_19_SSE2-DEBUG.exe!AfxInternalPumpMessage() Line 183 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWinThread::PumpMessage() Line 900 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWinThread::Run() Line 629 + 0xd bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWinApp::Run() Line 832 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 47 + 0xd bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!__tmainCRTStartup() Line 275 + 0x2c bytes C
     fred2_open_3_6_19_SSE2-DEBUG.exe!WinMainCRTStartup() Line 189 C
     kernel32.dll!750b33aa()
     ntdll.dll!77539ef2()
     ntdll.dll!77539ec5()
     fred2_open_3_6_19_SSE2-DEBUG.exe!ai_waypoints() Line 4426 + 0x9 bytes C++
     f301c0b2()
2871.fs2 (4,127 bytes) 2013-05-11 22:50
http://scp.indiegames.us/mantis/file_download.php?file_id=2197&type=bug
 
There are no notes attached to this issue.




View Issue Details
2892 [FSSCP] FRED minor always 2013-06-10 03:53 2016-03-20 17:15
FUBAR-BDHR  
 
normal  
new 3.6.19  
open  
none    
none  
   
Invalid bitmaps in background 2 not being detected during load/save
Basically when you load or save a mission it is supposed to throw a warning if a background bitmap isn't found. This works find for background 1 but background 2 appears to not be checked. It will load and save the mission without any warnings. You can even go into the background editor and not get one unless you actually switch to background 2.

This might be related to 2876 but happens even if the suns are correct.
Requires a mission with 2 $Bitmap List: sections in the .fs2 file. If you don't have one take any mission that has a valid background, copy the $Bitmap List: section so there are 2. Change the name of one of the bitmaps in the second list to something that doesn't exist. Open the mission in FRED. Note there is no warning about the invalid bitmap. Save mission, again no warning. Open background editor, again no warning. Change the background to background 2 and you should get the warning.
3.6.19 but it's basically 3.7.0 RC2.
 
There are no notes attached to this issue.




View Issue Details
2902 [FSSCP] HUD tweak have not tried 2013-07-12 23:02 2016-03-20 17:14
kopachris  
 
low  
new  
open  
none    
none  
   
Player engine loop uses forward velocity for volume
In hud.cpp, update_throttle_sound() uses forward velocity to determine what volume the engine loop sound should play at in most cases. Now that we have the ability to use semi-Newtonian physics (as in e.g. Diaspora), we should always use forward thrust to determine engine volume. Otherwise, we end up with no engine volume even when the engine should be working at full thrust.
Origin: http://www.hard-light.net/forums/index.php?topic=85028.msg1699748

I went ahead and made the change and have attached the patch.
fs2_use_thrust_for_snd.patch (918 bytes) 2013-07-12 23:02
http://scp.indiegames.us/mantis/file_download.php?file_id=2240&type=bug
 
There are no notes attached to this issue.




View Issue Details
3169 [FSSCP] physics minor have not tried 2015-07-15 14:35 2016-03-20 17:08
z64555 x86_64  
Microsoft Windows  
normal 8.1  
new 3.7.2  
open  
none    
none  
   
Weapon Object Radius is Ignored for Ship-Weapon Collision Checks
This is a phenomenon most notable in mods where munitions have a significant difference in size from FS2 weapons (Think big bullets and missiles here). All weapons are treated as if they have the same size, regardless of their representative .pof radius and/or @Laser Head Radius.
Mod a laser weapon to have a significantly large Head Radius (we'll go with 5.0)
Mod a laser weapon to use a .pof, presumably that of a sphere of radius 5

Shoot a standard laser at a dummy ship target and find a point where it'll *just* miss hitting its hull. The shield shouldn't interact with it.

Switch to the modded lasers and perform the same test. What *should* happen is that the larger size of the weapons would trigger a collision, and thus impact the shield and/or hull.
Sticking this here as a reminder, since I have a busy week ahead of me. I'll try to do more research on it as soon as I can.
MS Windows 64-bit OS
Intel Core i7 4700-MQ
NVIDIA GeForce GTX 770M
 
There are no notes attached to this issue.




View Issue Details
3115 [FSSCP] models minor always 2014-10-01 08:15 2016-03-07 14:49
Black Wolf  
Goober5000  
high  
code review  
open  
none    
none  
  3.8  
look_at has been removed from the engine
Last year, VA mentioned that he had accidentally broken look_at for submodels (http://www.hard-light.net/forums/index.php?topic=84897.msg1713468#msg1713468).

The feature has yet to be repaired and reintegrated with the engine as of the September 17 nightly.
Launch fighters from the Praetor. Its hydraulic rams should be looking at each other, instead they follow the orientation of the bay doors.
See thread here: http://www.hard-light.net/forums/index.php?topic=88393.0
Praetor.7z (722,861 bytes) 2014-10-01 08:15
http://scp.indiegames.us/mantis/file_download.php?file_id=2575&type=bug
3115.patch (2,617 bytes) 2014-10-17 18:52
http://scp.indiegames.us/mantis/file_download.php?file_id=2585&type=bug
 
Notes
(0016336)
MageKing17   
2014-10-09 19:47   
Relevant: http://www.hard-light.net/forums/index.php?topic=83628.msg1709474#msg1709474
(0016339)
MageKing17   
2014-10-17 18:55   
(Last edited: 2014-10-17 18:55)
So I've uploaded a simple patch that adds the missing line from the above link, plus a couple of minor tweaks on the parsing side. This (plus fixing the provided POF to use submodel names instead of numbers) makes the example work, but still has the worrisome potential performance issues brought up in the previously-linked thread.

(0016643)
Goober5000   
2015-04-16 00:31   
Assigning this to The_E for review. It would be nice to have this figured out given that the look_at feature was meant for 3.7.0 and then forgotten.
(0016782)
m_m   
2015-09-18 08:29   
Maybe the performance issues could be reduced by only traversing the model hierarchy for the models that actually use look_at by setting a flag when the model is loaded?
(0016783)
MageKing17   
2015-09-18 16:20   
As The_E already noted back in 2013: http://www.hard-light.net/forums/index.php?topic=83628.msg1709521#msg1709521

Goober's suggestion immediately after (http://www.hard-light.net/forums/index.php?topic=83628.msg1709547#msg1709547) was to incorporate the look_at stuff into one of the existing traversals, which makes a lot of sense, but at the very least, a model flag would be better than doing the traversal for everything every frame.
(0016788)
m_m   
2015-09-23 13:29   
I made a PR for this: https://github.com/scp-fs2open/fs2open.github.com/pull/358

Currently untested because I have no test mission. I'm also not sure if my usage of model_look_at is right in model_render_queue.
(0016811)
Goober5000   
2016-01-31 22:21   
New PR opened: https://github.com/scp-fs2open/fs2open.github.com/pull/530

Almost, but not quite, ready to be resolved.
(0016812)
Goober5000   
2016-03-07 14:49   
I've told chief1983 and The E that I'm bumping this to 3.7.6. The refactoring is complete, but the angle calculation is proving extremely difficult to get working for all models in all situations.




View Issue Details
2866 [FSSCP] sound minor always 2013-05-08 03:13 2015-12-19 18:51
FUBAR-BDHR  
FUBAR-BDHR  
normal  
code review 3.6.19  
open  
none    
none  
  3.7.0  
Sounds played from event editor in FRED get extension added even if they have one
event_editor::OnPlay() calls audiostream_open() with ASF type forced to ASF_EVENTMUSIC which has a value of 1. This causes keep_ext in WaveFile::Open() to be true. For some reason the code does not look at this flag and assumes no extension and adds one. Normally this doesn't seem to cause an issue but as soon as you have a long enough file name you end up going over the 32 character limit due to the duplicate extension and getting an ERANGE string error.
Put a wav file into data\voice\special and rename it so it is 30 characters total length including extension. Open up FRED, create a message with this .wav file. Make sure you include the .wav extension in the filename. Hit the play button.
event_editor_sound.patch (1,210 bytes) 2013-05-08 04:04
http://scp.indiegames.us/mantis/file_download.php?file_id=2192&type=bug
2866.patch (3,816 bytes) 2013-06-02 22:43
http://scp.indiegames.us/mantis/file_download.php?file_id=2217&type=bug
 
Notes
(0015043)
FUBAR-BDHR   
2013-05-08 04:05   
Attaching patch that might fix the issue but can't test it in FS2 to make sure id doesn't break anything there due to 2684 not allowing me to load test missions.
(0015074)
niffiwan   
2013-05-20 05:00   
I'm not sure what the 1st patch hunk is there for. It'll load a file in certain circumstances, and then (if successful) it'll load the same file again?

Also, if there is no extension on the file, the "stristr" check will find that and log an error? If FRED forces event_editor::OnPlay() to use type ASF_EVENTMUSIC shouldn't a file extension be checked for and enforced at that point?

Why not just keep the 2nd hunk (i.e. only add an extension if !keep_ext) but also add a check to ensure the filename is <= MAX_FILENAME_LEN-4?
(0015075)
FUBAR-BDHR   
2013-05-20 06:15   
Well it was never a requirement that the files have an extension. Forcing the type the type to ASF_EVENTMUSIC was probably just a hack in FRED to make it work with or without an extension. Basically not having to worry about the type, stripping the extension, etc. There are tons of missions out there without extensions on messages.

If the possible redundant call to cf_find_file_location(); is an issue it could be put into and if (!fred_forced_failed).

Now the real issue is the way this whole thing was setup could cause what is played in FRED to be different that what is played in game if both an .ogg and .wav exist since FRED will always use the extension and FS2 will always do the best match for voice files.
(0015098)
niffiwan   
2013-05-30 05:49   
After some thought, I think we can break this into two problems with corresponding solutions.

1) ERANGE error
Don't add the 2nd extension if one already exists, and verify that the filename isn't too long if an extension is being added.

2) FRED being able to play audio files without an extension AND Avoid confusion if both a .wav & .ogg are present
event_editor::OnPlay() should check for the presence of an extension in the passed filename & set ASF_EVENTMUSIC appropriately. This should also ensure the same file plays in FRED & FSO. If there's no extension then FSO & FRED will find the same file (.ogg if it exists, otherwise .wav). If there is an extension, then it's fine as well. If an invalid extension is added (or mispelled), or the filename is wrong then the sound won't play which should prompt the FREDDER to investigate further.

How does that sound? :)
(0015099)
FUBAR-BDHR   
2013-05-30 15:45   
Well the 1st one should already be happening in FS2. The only time I saw where the extension would get added and possibly pushed over the limit was if the type was ASF_EVENTMUSIC. That was fixed by the if (!keep_ext) around the strcat_s. Of course an extra check for it never hurts in case the above function doesn't do what it's supposed to do.

The 2nd one is a little more complicated. It's not just event_editor::OnPlay() it's every call from FRED. Now all those could all have the extension checks added but what type do you call audiostream_open() with? The files used can be voice files which aren't tabled, sound files which may or may not be tabled, of music files which may or may not be tabled. In all cases FRED doesn't require an extension but the tabled version may.

Now I can see 2 possible ways to fix the second one. Edit ever place in FRED and add redundant code to either add an extension if one doesn't exist or strip all extensions. You still don't really have a valid type to call audiostream_open() with though. Add a new type like ASF_FRED and handle this in audiostream_open(). Of course handling the extensions there is probably how V should have done it in the first place for all calls not just from FRED so everything would be consistent and extensions would be optional in all tables. And as usual fixing it totally would break backward compatibility so that's probably not an option. Of course the 3rd option is go with the hack and revamp the whole sound file handling in wxFRED with proper.

The part about the wrong filename would not be a good idea. From what I've seen most of the time the files entered there don't exist. People seem to like using that filed for comments for voice acting so there are a lot of things like "alien music bit" or "surrender or we fire" in those fields. Even when they are actual file names they may not exist because the voice acting isn't done at the time the messages are made.
(0015115)
FUBAR-BDHR   
2013-06-02 22:57   
Well it seems this one was even more complex but the solution for most of it was a lot easier.

It turns out that depending on where the voice is being played from it may or may not even go through audiostr.cpp in game. Briefings and debriefings do but messages played via events don't unless they are training messages. It does appear that everywhere voice files are played that the extension is stripped before loading. This means that forcing ASF_EVENTMUSIC in FRED actually did the opposite of what would happen in FS2.

So anyway the solution is just to change the types in FRED to ASF_VOICE. That along with a warning to prevent the ERANGE error (if it hits this outside of FRED there are bigger fish to fry) and the previous not adding an extension if it's supposed to have one should cover this.

Of course there is still is the possibility of an edge case where you will get 2 different results for entries in music.tbl used in messages. This would require that files exist with both .wav and .ogg extensions and are used as messages. With ASF_EVENTMUSIC keeping the extension and everything else dropping it I don't see a way to easily keep this from happening.
(0016807)
Yarn   
2015-12-19 18:51   
This PR, which has already been merged, should at least prevent the error caused by adding a second extension: https://github.com/Yarn366/fs2open.github.com/commit/b1e7a2a1bf5e72224ca369b950ed6a04007613d4




View Issue Details
3130 [FSSCP] beams major sometimes 2014-11-21 19:07 2015-12-19 18:06
Goober5000  
FSO 4  
normal  
confirmed 3.7.2 RC4  
suspended  
none    
none  
   
The insidious beam crash bug
I suddenly started experiencing it myself and now I've noticed some common features. All of the following seem to be necessary:

1) A recent build (latest trunk as of r11178 will do it)
2) A beam begins firing
3) The player is using an NVIDIA card

It occurs on both release and debug builds but NOT when a debug build is run through MSVC 2005, at least. It happens both with and without the 2014 mediaVPs. I've attached a couple of fso_open.log files.

I didn't initially experience this crash when playing through the FS2 campaign on MediaVPs 2014, but then I realized I was playing using the integrated graphics card. As soon as I switched to NVIDIA, the crashes started reliably happening.

This is a show-stopper for the 3.7.2 release as far as I'm concerned.
Threads where the crash has been reported:

http://www.hard-light.net/forums/index.php?topic=88649.0
http://www.hard-light.net/forums/index.php?topic=88662.0
http://www.hard-light.net/forums/index.php?topic=88654.0
fs2_open-mediavps.log (47,382 bytes) 2014-11-21 19:15
http://scp.indiegames.us/mantis/file_download.php?file_id=2614&type=bug
fs2_open-nomediavps.log (43,030 bytes) 2014-11-21 19:16
http://scp.indiegames.us/mantis/file_download.php?file_id=2615&type=bug
crash error.jpg (15,660 bytes) 2014-11-22 13:31
http://scp.indiegames.us/mantis/file_download.php?file_id=2616&type=bug
jpg

call stack.txt (6,326 bytes) 2014-11-22 13:31
http://scp.indiegames.us/mantis/file_download.php?file_id=2617&type=bug
MVP 2014 patches.zip (4,112 bytes) 2014-11-22 14:45
http://scp.indiegames.us/mantis/file_download.php?file_id=2618&type=bug
call stack 2.txt (2,458 bytes) 2014-11-23 14:30
http://scp.indiegames.us/mantis/file_download.php?file_id=2619&type=bug
call stack 3.txt (2,558 bytes) 2014-11-23 14:30
http://scp.indiegames.us/mantis/file_download.php?file_id=2620&type=bug
fs2_open 3.log (48,048 bytes) 2014-11-23 14:31
http://scp.indiegames.us/mantis/file_download.php?file_id=2621&type=bug
fs2_open 4.log (456,666 bytes) 2014-11-23 15:15
http://scp.indiegames.us/mantis/file_download.php?file_id=2622&type=bug
call stack 4.txt (2,558 bytes) 2014-11-23 15:15
http://scp.indiegames.us/mantis/file_download.php?file_id=2623&type=bug
call stack 5.txt (2,558 bytes) 2015-01-03 21:07
http://scp.indiegames.us/mantis/file_download.php?file_id=2635&type=bug
call stack 6.txt (2,558 bytes) 2015-01-05 00:31
http://scp.indiegames.us/mantis/file_download.php?file_id=2636&type=bug
hud.cpp.patch (1,806 bytes) 2015-01-05 02:30
http://scp.indiegames.us/mantis/file_download.php?file_id=2637&type=bug
gropengltexture.cpp.patch (791 bytes) 2015-01-05 03:31
http://scp.indiegames.us/mantis/file_download.php?file_id=2638&type=bug
smother_with_error_checking.patch (2,375 bytes) 2015-01-07 17:04
http://scp.indiegames.us/mantis/file_download.php?file_id=2639&type=bug
call_stack-2015-01-10.txt (2,558 bytes) 2015-01-10 22:43
http://scp.indiegames.us/mantis/file_download.php?file_id=2640&type=bug
fs2_open-2015-01-10.log (510,630 bytes) 2015-01-10 22:43
http://scp.indiegames.us/mantis/file_download.php?file_id=2641&type=bug
bmpman_entry.txt (1,404 bytes) 2015-02-08 21:04
http://scp.indiegames.us/mantis/file_download.php?file_id=2646&type=bug
bm_bitmaps watch.txt (1,328 bytes) 2015-02-22 20:16
http://scp.indiegames.us/mantis/file_download.php?file_id=2653&type=bug
disable_reuse.patch (582 bytes) 2015-02-26 19:56
http://scp.indiegames.us/mantis/file_download.php?file_id=2655&type=bug
call stack wo dummy.txt (2,559 bytes) 2015-03-04 00:45
http://scp.indiegames.us/mantis/file_download.php?file_id=2663&type=bug
call stack w dummy.txt (2,558 bytes) 2015-03-04 00:45
http://scp.indiegames.us/mantis/file_download.php?file_id=2664&type=bug
call stack w dummy and kills disabled.txt (2,558 bytes) 2015-03-04 00:46
http://scp.indiegames.us/mantis/file_download.php?file_id=2665&type=bug
different crash call stack.txt (2,453 bytes) 2015-03-04 00:46
http://scp.indiegames.us/mantis/file_download.php?file_id=2666&type=bug
different crash fs2_open.7z (126,238 bytes) 2015-03-04 00:46
http://scp.indiegames.us/mantis/file_download.php?file_id=2667&type=bug
3130.patch (9,855 bytes) 2015-03-04 01:06
http://scp.indiegames.us/mantis/file_download.php?file_id=2668&type=bug
redundancy.patch (482 bytes) 2015-03-05 03:29
http://scp.indiegames.us/mantis/file_download.php?file_id=2669&type=bug
callstack w redundancy.txt (2,559 bytes) 2015-03-10 00:23
http://scp.indiegames.us/mantis/file_download.php?file_id=2671&type=bug
units.txt (651 bytes) 2015-03-10 00:23
http://scp.indiegames.us/mantis/file_download.php?file_id=2672&type=bug
hudtarget.cpp.patch (1,343 bytes) 2015-03-10 23:51
http://scp.indiegames.us/mantis/file_download.php?file_id=2673&type=bug
enabling triangles.txt (2,546 bytes) 2015-03-15 02:16
http://scp.indiegames.us/mantis/file_download.php?file_id=2674&type=bug
swifty.patch (1,553 bytes) 2015-03-23 02:08
http://scp.indiegames.us/mantis/file_download.php?file_id=2677&type=bug
desaturate_fix.patch (2,863 bytes) 2015-04-08 03:49
http://scp.indiegames.us/mantis/file_download.php?file_id=2689&type=bug
desaturate-callstack.txt (2,559 bytes) 2015-04-08 23:10
http://scp.indiegames.us/mantis/file_download.php?file_id=2690&type=bug
desaturate-fs2_open.log (404,039 bytes) 2015-04-08 23:11
http://scp.indiegames.us/mantis/file_download.php?file_id=2691&type=bug
shader_mode_hunch.patch (4,404 bytes) 2015-04-09 23:01
http://scp.indiegames.us/mantis/file_download.php?file_id=2692&type=bug
hunch-callstack.txt (2,558 bytes) 2015-04-10 00:13
http://scp.indiegames.us/mantis/file_download.php?file_id=2693&type=bug
hunch-fs2_open.log (403,794 bytes) 2015-04-10 00:13
http://scp.indiegames.us/mantis/file_download.php?file_id=2694&type=bug
hunch2.patch (4,582 bytes) 2015-04-10 00:17
http://scp.indiegames.us/mantis/file_download.php?file_id=2695&type=bug
hunch2-callstack.txt (2,559 bytes) 2015-04-10 23:50
http://scp.indiegames.us/mantis/file_download.php?file_id=2696&type=bug
hunch2-fs2_open.log (404,961 bytes) 2015-04-10 23:50
http://scp.indiegames.us/mantis/file_download.php?file_id=2697&type=bug
 
Notes
(0016390)
MageKing17   
2014-11-21 20:20   
The second thread linked doesn't fit the pattern because TheHound's logs show him using an Intel HD 4000, not an nVidia card. I think you're also the first person to report that the crash still occurs with a debug build... if running the debug build through Visual Studio fails to reproduce the problem, have you tried attaching the debugger to a release build?
(0016391)
Goober5000   
2014-11-22 13:20   
(Last edited: 2014-11-22 13:22)
Tried that today. It refuses to crash in MSVC whether it's through release or debug.

But since the crash does occur in a debug build, it should be possible to narrow down the problem by use of logging statements. The cause seems to be in the shader system, because the debug log contains shader information immediately prior to the crash, both with and without MVPs.

If someone wants to heavily instrument the shader system with logging statements and provide me a patch, I'd be happy to run tests.

(0016392)
Goober5000   
2014-11-22 13:31   
Actually, let me modify that comment. It doesn't crash if I launch the process from MSVC, but it does crash if I launch the process separately and then attach the debugger.

The crash occurs in opengl_texture_state::Enable, inside the glBindTexture function. The actual source of the crash is in the nvoglv32.dll, for which we don't have the debug symbols. I'm attaching a screenshot of the error as well as the call stack.
(0016393)
Goober5000   
2014-11-22 14:45   
I've uploaded a zip that contains versions of the MVP 2014 tables so that 3.7.0 can run with the MediaVPs 2014. I still get the crash under 3.7.0.
(0016394)
Goober5000   
2014-11-22 16:36   
Updating the NVIDIA drivers did not solve the crash.
(0016395)
m_m   
2014-11-23 11:24   
The call stack shows that the bitmap_handle argument for gr_opengl_tcache_set_internal is 0. If I read bm_get_next_handle() in bmpman.cpp correctly that should never happen.
Is there a mission where this crash happens consistently?
(0016396)
Goober5000   
2014-11-23 12:08   
Yeah, if you load up Exodus (SM3-06) the Nebtuu and Abraxis are firing beams at each other at mission start, so the crash happens almost immediately.
(0016397)
m_m   
2014-11-23 12:50   
I tried running the mission and checking for bitmap_handle==0 in gr_opengl_tcache_set_internal but that condition is apparently never true on my machine.
(0016398)
MageKing17   
2014-11-23 13:38   
It shouldn't be possible for bitmap_handle to be 0 in gr_opengl_tcache_set_internal() because it's only called through gr_opengl_tcache_set(), which specifically checks if (bitmap_handle <= 0) and returns 0 if it is. For some reason, gr_opengl_tcache_set() is missing from the attached call stack, which doesn't seem like it should be possible.
(0016399)
Goober5000   
2014-11-23 15:15   
More logs attached.
(0016420)
chief1983   
2014-12-19 10:03   
Goober, if you're getting crashes with debug, attaching a debugger and snooping around could be very very helpful here. Perhaps in conversation with another dev or something.
(0016422)
Goober5000   
2014-12-20 16:29   
I've done that already. See comment #c16392 that I wrote on 11/22. I tracked down the location of the crash and attached several call stacks.

I'm happy to do more collaboration with whoever wants to step up to fix this, but nobody has stepped up yet. And not being a graphics coder, I don't have the expertise to fix this myself.
(0016423)
chief1983   
2014-12-20 16:34   
One of our members mentioned that the crash happens only when directly looking at beam sources. Was this something you observed? If not it might be different bugs.
(0016424)
Goober5000   
2014-12-20 17:29   
That's an interesting note. Every crash that I saw was when I was looking directly at the beam, but I didn't try looking away from the beam.

I don't think that tells us much though. We already knew it was graphics related, and there's no need to draw the beam if you're not looking at it.
(0016425)
MageKing17   
2014-12-20 17:36   
Would be interesting to see if it could be linked to a specific part of drawing the beam (e.g. disable particles and see if it still happens); I'm going to try to reproduce this issue on an nVidia computer today and, with luck, get more data (although I'm also pessimistic the data might be "it doesn't happen on that card").
(0016426)
chief1983   
2014-12-20 17:53   
Not just the beam itself, but he could look at the beam freely, and not crash until he looked at its origin. People mentioned that boom warmups had been causing it, so personally I hadn't ruled out that we just had a small sample pool and that it was possibly still audio related, although now I'm more willing to rule that out. But if it's only the origin of the beam, it seems to indicate something with the way the warmup or base animation points are being draw, or possibly how beam origin animations are interacting with the surrounding ship model. With the description of your callstack you mentioned earlier, perhaps it has to do with the animation somehow failing to have loaded in the first place, and upon trying to draw it to load it ends up crapping out because it isn't there to draw in the first place? I take it no one has had this happen with retail, so that might imply it has to do with DDS textures and PCX are immune. That or the actual difference between how MVP beam glows and retail beam glows are configured is related.
(0016427)
MageKing17   
2014-12-20 19:55   
Null result on a GTX 580; sounds like this problem only affects 600-series and later cards.
(0016428)
Goober5000   
2014-12-20 21:45   
Mine is a Quadro K2100M, if that helps.
(0016429)
chief1983   
2014-12-20 23:23   
That appears to share a chipset with the GTK660, so that would be in line with the findings. And if you're running Quadro drivers it means they're not any more immune to the issue than the Geforce line drivers.
(0016435)
z64555   
2015-01-03 16:59   
(Last edited: 2015-01-03 17:02)
Thought I would try to help out, but I could not repro the crash on my machine.

Build Info:
 SVN r11204
 MSVS Debug AVX configuration

Test Mission:
 SM3-06

GPUs:
 Intel 4700-MQ
 Nvidia GeForce 770M (driver 347.09)

Assets:
 Retail
 mediavps_3612
 MediaVPs_2014

(0016436)
Goober5000   
2015-01-03 17:04   
If one of the graphics coders is able to do a code review of the section that crashes, that would be helpful even if he can't reproduce the crash on his own machine. Scrutinizing the code may reveal improperly formatted data, a bad API call, a function being called out-of-order, data being accessed after being freed, or any number of things.

Refer to my previous comments and stack traces, particularly this: "The crash occurs in opengl_texture_state::Enable, inside the glBindTexture function."
(0016437)
Goober5000   
2015-01-03 17:49   
(Last edited: 2015-01-03 17:49)
It's definitely HUD related. I loaded up Exodus and immediately toggled the HUD off, and the beams fired without crashing. Then I toggled the HUD back on while the beam was firing, and insta-crash, even before the HUD became visible again.

(0016439)
niffiwan   
2015-01-04 02:08   
(Last edited: 2015-01-04 02:08)
I notice that the call stacks always show that the Kills Gauge is being rendered, does the crash still occur if just that one gauge is disabled?

(0016441)
Goober5000   
2015-01-04 02:38   
If you can whip up a test mission, I'll test it out. I've been using Exodus (sm3-06) and applying various tweaks.
(0016443)
MageKing17   
2015-01-04 02:54   
Should be as simple as using the in-game options menu and turning it off; hit F2, enter "HUD Config", click on the kills gauge (it's between ETS and CM count), and set it to "off" and see what happens.

(And then, of course, if it doesn't crash, try turning it on while a beam is firing, although at that point I think it'd be a pretty safe bet that it crashes again.)
(0016444)
Goober5000   
2015-01-05 00:33   
(Last edited: 2015-01-05 00:33)
Very interesting. That's exactly what happened... starting the mission with the kills gauge disabled prevented the crash, and then re-enabling that gauge while the mission was in progress caused a crash as soon as I hit Accept. New call stack (number 6) attached, but it's pretty much the same as the previous ones.

(0016445)
MageKing17   
2015-01-05 02:30   
(Last edited: 2015-01-05 03:32)
Well, I've gone all over the HudGaugeKills code and can't find anything unusual about it. I did find one oddity in hud.cpp that shouldn't be causing any problems, but just to be safe, I've attached a patch file that removes some unused things. Could you compile a build with the patch attached and see if it affects the problem? I don't expect it to, but who knows what could be affecting it...

EDIT: Another patch attached that adds some error checking near the problem area.

(0016448)
Goober5000   
2015-01-09 10:56   
I haven't had a chance to test the patch yet, but hopefully I can do so this evening.
(0016449)
Goober5000   
2015-01-10 22:44   
Or the following evening. >.> Crashed again in the same place. New log and stack trace attached.
(0016450)
MageKing17   
2015-01-10 22:51   
It looks like it didn't trigger any of the new OpenGL error checking. Did you use the smother_with_error_checking.patch or just gropengltexture.cpp.patch?
(0016451)
Goober5000   
2015-01-11 17:30   
Just the smother_with_error_checking.patch actually. But I just ran a new build with both patches and it looked like I got the same result.
(0016452)
MageKing17   
2015-01-11 17:39   
smother_with_error_checking.patch includes gropengltexture.cpp.patch; clearly, whatever is going wrong here isn't throwing any OpenGL errors.

Someone on the forums reported that the problem has gone away since installing the latest nVidia drivers; is there an updated driver for the Quadro K2100M?
(0016453)
chief1983   
2015-01-11 17:42   
Looks like it. http://www.nvidia.com/download/driverResults.aspx/80141/en-us 341.21, on December 5.
(0016454)
Goober5000   
2015-01-17 21:30   
I installed the driver update. Crash still occurs.
(0016466)
niffiwan   
2015-01-29 07:44   
(Last edited: 2015-01-29 16:33)
There seems to have been another driver update recently; it may be worth testing with it?
http://www.nvidia.com/download/driverResults.aspx/81666/en-us

Version: 347.25 WHQL
Release Date: 2015.1.23

Also, do we know if the problem occurs with mediavps_3612? And do we know the earliest release that it occurs on? (pre 3.7.0)

update: info from krevett62
http://www.hard-light.net/forums/index.php?topic=89060.msg1775367#msg1775367

... for me before updating my nvidia drivers, I was crashing when playing with 3.7.2_RC4 and with MVP 2014 or MVP 3.6.12, but no crash occured with retail data and the same exe. Also 3.7.0 with MVP 3.6.12 worked fine at this time.

(0016467)
Goober5000   
2015-02-01 02:59   
Updated the driver again. Still crashes.
(0016475)
Inglonias   
2015-02-07 12:04   
(Last edited: 2015-02-07 12:20)
I have this bug, but trying to reproduce it in the debug builds results in the game running just fine. Weird.

Using a GTX 670 with the latest drivers.

EDIT: Reading the other notes reveals that this is not new information. My bad. Any way I can help with just the debug builds and normal builds?

(0016476)
Goober5000   
2015-02-07 12:52   
Debug builds will run on the Intel Integrated graphics card unless you specifically set them to run with the NVIDIA card. I think that's why some people have not seen crashes in debug builds.

I think that all the help testers can give has been given. We know where in the code it crashes, we know about an unusual setting that disables the crashes (turning off the HUD gauge), and we know a possible cause (NVIDIA has said this can happen with badly formatted graphics data).

This bug will only be fixed when a group of graphics coders sit down, take a serious look at it, and make a serious attempt to solve it. It's not going to solve itself, and three separate driver updates have not fixed it.
(0016477)
niffiwan   
2015-02-08 17:09   
(Last edited: 2015-02-08 21:22)
@Goober5000; have you had a discussion with Nvidia regarding this issue? If you've got more info from them it'd be useful to see the entire conversation, and in particular understand what "badly formatted graphics data" refers to. Maybe there's something wrong with the retail hud kills gauge .ani?

I've also had a look through the hud kills gauge code and can't see any obvious issues (apart from the one that MageKing17 has already identified). Coverity is reporting some uninitialised variables in the HUD code class constructors but I can't see anywhere obvious that these are being *used* uninitialised (i.e. they're being initialised outside the contructors). Regardless I'll see if I can put together a patch that'll fix those issues and we can see if it makes any difference or not.

One other idea I had was to investigate the possibility that (any of) the beam textures were corrupting/overwriting the kills gauge textures. Would it be possible for you to check the contents of BMPMAN (when FSO crashes) at the relevant bmpman index (532715 in most of the stack traces; and it's not exactly an index given the modulo operations involved, the real index is probably 532715%4750 = 715) and maybe extract the data into a file to check if it looks like valid data?

@Inglonias; I think it'd be useful if you could confirm whether you have dual video cards in your system and whether the debug builds are using the Intel card or the Nvidia one.

(0016478)
niffiwan   
2015-02-08 17:31   
(Last edited: 2015-02-08 21:30)
more info; Axem is unable to reproduce the issue.

Nvidia 960
Drivers 347.25
Exodus (SM3-06) with mediavps_2014

So maybe the issue only affect 6xx/7xx series cards and their Quadro equivalents?

edit:

DahBlount also can't repro with a 970

(0016479)
Goober5000   
2015-02-08 21:04   
(Last edited: 2015-02-08 21:05)
@niffiwan: I haven't discussed anything with NVIDIA directly. That comment came from a search on the error message which returned this result:

https://devtalk.nvidia.com/default/topic/720651/opengl/access-violation-in-nvoglv32-dll-how-do-i-track-down-the-problem-/
"Access violations during glDrawArrays or glDrawElements are most often due to incorrectly enabled vertex attribute arrays.
Please check your current state of the enabled vertex attributes very carefully. One which is left enabled inadvertently without providing any or enough data will result in these kinds of errors when sourcing data out of bounds during the draw call."

Good call on checking the contents of bmpman. I looked at bm_bitmaps using the bitmap_handle passed to gr_opengl_tcache_set_internal() at the time of the crash, and it corresponded to kills1.ani. I have attached the rest of the entry as a text file to this ticket but I wouldn't know how to extract the graphical data into a file.

(0016480)
MageKing17   
2015-02-08 21:27   
Except it's not during glDrawArrays() or glDrawElements(), it's during glBindTexture().

Have you tried taking some other ANI file (like, say, time1.ani), copying it to your /data/hud/ folder, renaming it to "kills1.ani", and seeing what happens?
(0016482)
Goober5000   
2015-02-08 23:42   
Yes, I know that glBindTexture is a different function, but the same principle could apply. In the first place, it was a very similar error; in the second place, the forum poster may not have exhaustively listed every single potential crash source; and in the third place, checking that your inputs are valid is a good thing to do no matter what API you are using.

Copying and renaming time1.ani to kills1.ani produced exactly the same crash.
(0016483)
niffiwan   
2015-02-08 23:52   
The odd thing is that there's a heap of other hud gauges rendered in similar fashion. I guess it'll need a more thorough comparison of the exact calls+params used in each case. I'm kinda assuming it's not a stale OGL state issue since then I'd expect it to crash at the next gauge to be rendered when the kills gauge is off.
(0016485)
MageKing17   
2015-02-09 00:23   
"Copying and renaming time1.ani to kills1.ani produced exactly the same crash."

And you can see the background of the kills gauge changed, thereby ensuring that this copy is being loaded and not being overridden by a higher-priority kills1.ani somewhere else in the file tree? Just want to make sure. It sounds incredibly odd for it to not be working when time1.ani renders just fine for the mission time gauge.

Both gauges render in pretty much exactly the same way; they call setGaugeColor(), then renderBitmap() on the appropriate frame. For HudGaugeKills, this renderBitmap() call is apparently crashing whenever a beam is onscreen. For HudGaugeMissionTime, it isn't. Just about the only difference I can see is in how they behave slightly differently if first_frame is < 0, but that shouldn't be relevant when both have background images (or cause any problems even if they didn't).

Just about the only zany testing change I can think of to make at this point is to rearrange retail_gauges[] to swap HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS, just to see if it still crashes during HudGaugeKills.
(0016486)
Goober5000   
2015-02-09 02:22   
(Last edited: 2015-02-09 02:23)
Swapping HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS now results in a crash in the mission-time HUD gauge (time1.ani), but at the same bitmap handle as the kills gauge in the previous test. This lends support to niffiwan's earlier hypothesis about memory overwrites:

"One other idea I had was to investigate the possibility that (any of) the beam textures were corrupting/overwriting the kills gauge textures."

(0016487)
niffiwan   
2015-02-09 05:21   
(Last edited: 2015-02-09 05:42)
OK, so thinking in the same direction, the 1st beams to fire in SM3-06 would be the VSlash on the Nebtuu? Could you try switching out each texture used by the VSlash, one at a time? i.e.

particleexp01
beam-white3
beam-orange2
beam-orange
(I think they're the only VSlash textures that are unique to beams)
(actually, isn't there a beam glow texture loaded somewhere as well?)
(and hopefully I'm looking in the correct tables, there could be a table I've missed in the mediavps_2014 that's overriding the VSlash)

As for what to replace them with; maybe any original retail textures?
ParticleExp01.ani
beam-white3.pcx
beam-orange2.pcx
beam-orange.pcx

The idea is to isolate which texture is the cause of the issue to hopefully narrow down the area of code that needs checking.

In conjunction with this, maybe use a debug_filter.cfg containing the following lines, in order to get some extra info about the texture load process?
+General
+Warning
+Error
+BmpMan
+BmpInfo
+BMP DEBUG
+BmpFastLoad


edit: D'oh! There is, in mv_effects.vp. Maybe disable that single VP as the 1st test?

edit2: I think I've found the correct textures now.
particle_yellow.eff
VasBeam2Core.dds
VasBeam2Glow.dds
VasBeam2GlowHaze.dds
OrangeFade.dds
beamglow6.eff
capflash.eff
exp06.eff
exp04.eff

Maybe try at replacing the .eff files 1st as I recall that EFF loading/handling changed within the last few years. More recently than any DDS changes at least. Disabling MV_Advanced.vp will probably remove a fair few of them.

(0016494)
Goober5000   
2015-02-09 22:00   
The test occurs regardless of whether the MediaVPs are active or not. In all of my recent tests, I've been running with just the standard no-mods configuration. So they are already all retail textures.
(0016498)
MageKing17   
2015-02-18 20:28   
I don't suppose there's some way to find out exactly what section of memory the kills gauge is stored in and then make FSO break whenever that section of memory changes?
(0016499)
Goober5000   
2015-02-18 22:00   
It's very possible, and in fact I've tracked down some devious bugs that way. But I would need to know what I should be looking for. Memory changes all the time in perfectly normal ways.

I'll give you an example of one such bug. Remember my gigantic campaign to fix memset/memmove/memcpy in 2013? That was prompted by a crash where a pointer had a null value that had no business being null. I set a breakpoint on that pointer to trigger when its value changed, and then I ran the test mission. Upon reaching the breakpoint, I immediately saw that memset was being used incorrectly.
(0016500)
MageKing17   
2015-02-19 13:00   
Well, I was thinking that once it's loaded, the bitmap data shouldn't be changing again, so any change to that memory should be incorrect after the initial loading stage.
(0016501)
chief1983   
2015-02-19 13:10   
So the difference between this and that example is that in that example, the pointer's value was changing, but here, we're looking to see if the data in the memory the pointer points to is changing? I'm guessing that's harder to set up a watch for? Or at least not the same.
(0016502)
niffiwan   
2015-02-19 20:22   
I don't think it'll be much different. Set a data watchpoint on this pointer address, i.e.:

&bm_bitmaps[715]->bm->data

From this page I believe you can set the number of bytes to watch from that point on, which should let you watch all the data for that bitmap.
http://stackoverflow.com/questions/621535/what-are-data-breakpoints

To get the number of bytes I think you just need to read the contents of bm_bitmaps[715].data_size (if I'm reading this correctly BMPMAN_DEBUG is always defined in DEBUG builds)
(0016503)
Goober5000   
2015-02-20 23:51   
K. I'll give that a try on Saturday.
(0016505)
LotF   
2015-02-22 16:03   
No issues with my GeForce GTX 660 Ti (Vendor: MSI, Driver: nvlddmkm 9.18.13.3788 (ForceWare 337.88) / Vista 64bit)
(0016509)
Goober5000   
2015-02-22 20:15   
So I set a data watchpoint on bm_bitmaps[257]->bm->data (not 715, because that's exp05_1) and it had the value 0 during the entire run of the executable. Never changed at all, and was still 0 when the crash occurred.

I am attaching the data watch of the bm_bitmaps[257] entry at the time the crash occurred.
(0016510)
MageKing17   
2015-02-22 22:41   
ref_count is 0; that means that entry isn't being drawn at the time the crash is happening. Given the fact that bm->data is 0, this almost certainly means that this bitmap entry has never been drawn.

It's rather odd that this is bm_bitmaps[257] when the bitmap_handle in previous call stacks was 532715 (which, modulo MAX_BITMAPS, should be 715 as niffiwan referenced earlier). This isn't still with HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS swapped in retail_gauges[], is it?
(0016511)
Goober5000   
2015-02-22 23:42   
Well, bitmap handles aren't set in stone. Their loading order probably depends on the sequence in which you do things. In recent test runs the bitmap_handle has been 332757, which mod 4750 is 257.

The HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS are not still swapped.
(0016515)
MageKing17   
2015-02-26 19:57   
After stepping through the related graphics code, it would seem that the crash is actually occurring before there's ever a chance to even load the relevant bitmap data; this suggests that the problem isn't related to the graphics data, but is instead related to how OpenGL is being used. As an experiment, I've uploaded a patch that disables a bit of code that causes the engine to re-use a texture slot; if it still crashes with this patch, then I'm out of ideas.
(0016523)
Goober5000   
2015-03-02 02:01   
Crashed again, same place. Same bitmap handle, in fact. (Yes, I double-checked that your patch had been applied.)
(0016524)
MageKing17   
2015-03-02 02:40   
Well, I wouldn't expect the bitmap handle to change; the texture slots I am referring to are the texture IDs generated by glGenTextures(); I had thought that perhaps forcing it to free the IDs and regenerate fresh ones would avoid some wonky driver issue and fix the problem. Since that appears to not be the case... as I previously said, I'm out of ideas.
(0016533)
MageKing17   
2015-03-03 22:17   
After reading an offhanded comment niffiwan made in the March newsletter ("Maybe we should just reorder the hud gauges array such that an unused/little used HUD gauge is in the (ahem) *slot of doom* and then the workaround is to turn off the gauge"), I've come up with a stupid idea. Latest patch creates a "dummy" HUD gauge that's more-or-less an exact copy of HudGaugeKills, but a render() function that doesn't do anything, and inserts it before HUD_OBJECT_KILLS in retail_gauges[]. Given the behavior regarding swapping HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS, and the fact that turning off the kills gauge makes it not crash, this should theoretically fix the problem (even if it is a dirty, dirty hack).
(0016534)
Goober5000   
2015-03-04 00:47   
Well, this was interesting. With your patch applied, the game still crashes in the same place, with the same bitmap_handle, and using the same kills gauge. Not only that, but disabling the kills gauge in the HUD config doesn't work -- the gauge still appears in the mission and the crash still occurs.

To double-check this, I reverted the patch and ran things again. With the patch reverted, disabling the kills gauge worked and prevented the crash, while leaving the HUD gauge active caused the crash.

I did this series of tests twice. The first time I realized adding the extra HUD gauge might introduce some unknown problem with pilot profiles, so during the second cycle I created a new pilot for each of the trunk build and the patched build. Same result in all respects, including the patched build not actually disabling the kills gauge in-mission when you disable the kills gauge in your settings.

I've uploaded call stacks of the second cycle's series of tests.

(It's worth noting that during the first cycle, with the potentially compromised pilot files, I encountered one crash that was completely different, though it *also* occurred right at the beginning of Exodus. I've uploaded the call stack and log for that one crash as well.)
(0016535)
MageKing17   
2015-03-04 01:16   
Inability to disable kills gauge was probably due to inserting the entry in the wrong order in hudconfig.cpp; patch updated to hopefully fix that (although the fact that the crash still happened at all means that the dummy gauge isn't doing what it was expected to do).

The "different crash call stack" looks like "call stack 2" above, except with the addition of gr_opengl_string() in the stack trace... the odd part being that line 537 is the closing brace of the function. I guess that means some variable in that function is causing a crash due to going out of scope; the only non POD variable being declared in gr_opengl_string() would seem to be the GLboolean cull_face.

Before we go too far down this rabbit hole, it looks like there was another driver update last month: http://www.nvidia.com/download/driverResults.aspx/82061/en-us
Version: 347.52
Release Date: 2015.2.11

Might be worth trying one more time to see if the new drivers get rid of the issue.
(0016536)
MageKing17   
2015-03-05 03:31   
On a working assumption that the driver update won't fix the problem, I've attached another patch. This adds a glBindTexture() call immediately before the crashing one that binds the texture target to 0. This should be a completely redundant call that should have no effect whatsoever.

"Should" being the operative word.
(0016539)
chief1983   
2015-03-09 11:07   
Since we do have a workaround for this of disabling the kills gauge, plus it seems a smaller subset of users are still having issues at all now, there's talk of going ahead with the 3.7.2 final release without a final fix for this bug. Objections?
(0016540)
Inglonias   
2015-03-09 12:28   
(Last edited: 2015-03-09 12:28)
As one of the smaller subset of users who is still having this issue... yes?

EDIT: I'll use the workaround if I have to. No harm done.

(0016541)
chief1983   
2015-03-09 12:34   
You are? We were thinking that recent driver updates had almost narrowed it down to only Quadro users still affected by it. Are you able to reproduce the issue the same way Goober has been in the more recent posts in this thread? And disabling the kills gauge prevents the crash for you as well?
(0016542)
Inglonias   
2015-03-09 12:36   
Oh, that's right. I DID update my drivers didn't I? Huh.

I haven't tested it with the new drivers. Ignore my ramblings.
(0016543)
MageKing17   
2015-03-09 12:37   
Inglonias, when asked for more information earlier, you never commented again; without feedback, we had no way of knowing you even still had the issue.

The best way to help track down the cause of this bug is to provide as much information as possible!
(0016544)
Inglonias   
2015-03-09 12:43   
Right, yes, but I was also told that more testing information was not needed at that point. Specifically, Goober said "I think that all the help testers can give has been given."

So really, it's Goober's fault. /sarcasm

If it helps, I'll try reproducing the bug again as soon as I have access to my desktop in a few minutes. (Someone else is using it)
(0016545)
Inglonias   
2015-03-09 13:01   
Alright, so I was on my desktop with a GTX 670. If it makes you feel better, I was staring right at the Psamtik as it fired in "Surrender, Bellisarius!" and the game doesn't crash.

Loading up Exodus, the game doesn't crash there either. I guess I'm not affected by this any more after all. As I said:
1. Ignore my mad ramblings
2. Goober. Blame him. It's his fault. Because I say so.
(0016546)
Goober5000   
2015-03-09 23:05   
When I said "I think that all the help testers can give has been given", I meant that the testers had narrowed down the location and context of the crash, and the next step was for someone with deep understanding of the graphics code to sit down, construct a fault tree, and start zeroing in on what might be causing the crash. That person never showed up. MageKing17 has been making a valiant attempt and is to be commended, but it amounts to throwing darts at the code to see if something gets hit. That's a lousy way to debug a problem. Nevertheless, because MageKing17 has been persevering, we owe it to him as testers to continue to provide feedback.

In short, Inglonias, my comment was directed at the developers, not the testers. It was meant to shame the graphics coders into showing up. :p

I've been busy over the past few days (painting, ugh) but I will update the drivers again and try MageKing17's latest patch.

Inglonias, are you *positive* that the game is running using the NVIDIA graphics processor and not Intelgrated or whatever the fallback is? If you have multiple processors you can right-click on the EXE and select "run with high performance processor" to make it explicit.

If Inglonias confirms that he's using the right processor, and if neither the driver update nor the latest patch solves the problem, AND if nobody else has the problem, then I will accede to closing this bug as "won't fix" and I'll just live with using the standard processor.

I will post again with the results of my tests shortly.
(0016547)
Goober5000   
2015-03-10 00:28   
Well now we're getting somewhere... I think. The bad news is that it still crashed after the driver update. The good news is that something unexpected happened: it crashed on the newly inserted line:

glBindTexture(units[active_texture_unit].texture_target, 0);

The bitmap_handle variable is still 332757 and still points to kills1.ani. On the assumption that this "units" struct has something to do with the crash, I've uploaded a variable watch for that reference. (The active_texture_unit variable itself is 0.)
(0016548)
MageKing17   
2015-03-10 00:37   
(Last edited: 2015-03-10 01:07)
The texture_target is just GL_TEXTURE_2D (3553 == 0x0DE1, which is how GL_TEXTURE_2D is #defined in /code/graphics/gl/Gl.h). glBindTexture(GL_TEXTURE_2D, 0) is just saying "make the active 2D texture the default". The fact that it's crashing on what should be the safest, most boring OpenGL call means that the problem almost certainly lies elsewhere; something else is changing the state in such a fashion that the next glBindTexture() call is resulting in a crash.

EDIT: Does it still not crash with the kills gauge disabled?

EDIT2: I just noticed that neither gauge after the kills gauge in retail_gauges[] calls renderBitmap(). It's possible that this is the reason the dummy gauge failed; moving something that calls renderBitmap() after the kills gauge may cause that gauge to crash if the kills gauge is disabled.

Perhaps it's time to try moving HUD_OBJECT_KILLS up in retail_gauges[] until the crash stops occuring (swap it with the item above it one by one so we know which gauge is causing the OpenGL state to become corrupted).

EDIT3: Actually, HudGaugeEtsRetail() eventually winds up calling renderBitmapEx() which winds up in the same set of functions, and HudGaugeFixedMessages (HUD_OBJECT_FIXED_MESSAGES, immediately after HUD_OBJECT_KILLS) calls renderString(), which eventually ends up in gr_opengl_tcache_set() again. So... I dunno. Still want to know what happens if HUD_OBJECT_KILLS is moved up the list.

(0016549)
Inglonias   
2015-03-10 01:46   
(Last edited: 2015-03-10 01:46)
In regards to Goober asking if I'm sure about the crashing: What part of "Ignore my mad ramblings" do you not understand?

But, if it makes you happy, I loaded up Exodus on 3.7.2 RC5. Using a non-debug build. I was able to play the mission, and watch some beams before jumping out and being court marshalled. They were pretty.

Lack of a crash in this case from my end proves... that my copy of Freespace Open didn't crash. I don't know what else to say.

Goober, you don't HAVE to use the standard processor. Just disable the kills gauge. Nobody ever looks at it anyway!

(0016550)
Goober5000   
2015-03-10 20:39   
I don't think randomly shuffling HUD_OBJECT_KILLS is a good use of testing resources. It takes time to run each test, and every time the game crashes it takes longer to run the next test than the previous one.* Plus this is even more blatantly throwing darts than usual.

And it's not a good test either. It has only two possible outcomes: reordering the gauges will prevent the crash or the crash will keep happening. Neither outcome tells us anything.

You need to think strategically. It makes sense that the root cause lies elsewhere and what we're seeing is merely a symptom. This is consistent with NVIDIA's statement that malformed data can cause problems (though not conclusive). So, how might we check that the data isn't being corrupted or incorrectly constructed? What logging statements can we add? What Asserts can we add? Where should we expand our search? If we think that one of the other HUD gauges is corrupting the OpenGL state, is there some sort of sanity check that we can temporarily insert into each gauge's code? (This is what I meant by "construct a fault tree" and "zero in on the problem".)


*I assume this is caused by memory leaks due to the crash. The game will randomly freeze for a second or so, and every time it crashes and I run another test the freezes will occur more frequently. However, the crash is not dependent on whether or how frequent the freezing occurs.
(0016551)
Goober5000   
2015-03-10 21:11   
Because apparently I like to contradict myself, I ran a few tests with moving HUD_OBJECT_KILLS up a few indexes in the retail_gauges[] array. Turns out that the crash occurs if it is immediately below HUD_OBJECT_TARGET_TRI, but does not occur if it is immediately above it.
(0016552)
Goober5000   
2015-03-10 21:12   
(Note that usually HUD_OBJECT_KILLS is two spaces below HUD_OBJECT_TARGET_TRI, not one space.)
(0016553)
MageKing17   
2015-03-10 22:12   
And that is exactly why I wanted you to move HUD_OBJECT_KILLS around; because now we know that we need to look at HudGaugeTargetTriangle for odd behavior. Not sure what's not strategic about wanting to find that out...

Given that, HUD_OBJECT_HOSTILE_TRI, HUD_OBJECT_TARGET_TRI, and HUD_OBJECT_MISSILE_TRI all use HudGaugeReticleTriangle::renderTriangle() for their drawing, there may be something wrong with that function that's causing the kills gauge to crash.

If you want to verify that renderTriangle() is causing the problem, you could try disabling the gauges that use it instead of the kills gauge (with HUD_OBJECT_KILLS in its original position, of course) and see if it still crashes. They're "locked missile direction" and "current target direction" (not "target orientation", which is HUD_OBJECT_ORIENTATION_TEE) in the in-game HUD config menu (HUD_OBJECT_HOSTILE_TRI can't be turned off via this menu, but since it didn't crash for you before with HUD_OBJECT_KILLS immediately below it, that probably won't be a problem for this test).
(0016554)
MageKing17   
2015-03-11 00:04   
For experimentation purposes, I've attached a patch that makes the triangles get drawn with an OpenGL mode of GL_TRIANGLES instead of GL_TRIANGLES_FAN. Theoretically there should be no difference between the two, but, well, theoretically, glBindTexture() shouldn't be crashing at all.

One last retail_gauges[] rearrangement test I'd like to see the results of is HUD_OBJECT_ETS_RETAIL swapped with HUD_OBJECT_KILLS. If the crash occurs in HudGaugeEtsRetail, then we'll know that there's no difference between renderBitmap() and renderBitmapEx(), and then maybe we can take a look at why HudGaugeFixedMessages::render() not only doesn't trigger the crash, but fixes the problem for gauges rendered afterwards.

(If HudGaugeEtsRetail doesn't crash, then we'll be freaking out because there's very little difference between gr_opengl_aabitmap() and gr_opengl_aabitmap_ex(); they both call opengl_aabitmap_ex_internal().)
(0016556)
Goober5000   
2015-03-15 02:15   
With the kills gauge in the original place, I disabled "locked missile direction" and "current target direction". No crash. Then I re-enabled "current target direction" and got a completely different crash at the same time instant: the one shown in the "enabling triangles" attachment.

I'll try your triangles patch next, but I need to restart first. Too many memory leaks...
(0016557)
Goober5000   
2015-03-15 02:56   
(Last edited: 2015-03-15 02:57)
First I swapped HUD_OBJECT_ETS_RETAIL with HUD_OBJECT_KILLS. No crash at all.

Then I reverted the code, added your TMAP_FLAG_TRILIST patch (the hudtarget.cpp.patch uploaded on March 10), created a new pilot. Crashed immediately. (That patch doesn't seem to contain either GL_TRIANGLES or GL_TRIANGLES_FAN; do I have the right patch?)

(0016558)
MageKing17   
2015-03-15 04:06   
"That patch doesn't seem to contain either GL_TRIANGLES or GL_TRIANGLES_FAN; do I have the right patch?"

Yes. It adds a flag that causes a later function to use GL_TRIANGLES instead of GL_TRIANGLES_FAN. It shouldn't have made a difference, and it didn't. Good to know.

"First I swapped HUD_OBJECT_ETS_RETAIL with HUD_OBJECT_KILLS. No crash at all."

This is mind-boggling. HudGaugeEtsRetail calls calls a function that calls HudGauge::renderBitmapEx(), which follows an extremely similar to codepath to HudGauge::renderBitmap(), so I don't--

...Huh. I guess it does call HudGauge::renderPrintf() before that (to draw the "G", "S", "E" labels), so maybe that's why it doesn't crash. I guess that makes more sense than HudGaugeFixedMessages::render() fixing anything, since it shouldn't actually do anything most of the time. I wonder why gr_opengl_string() getting called avoids the crash, given that it also calls gr_opengl_tcache_set().

...In fact, in terms of actual OpenGL calls, the two should be doing exactly the same thing, up to the point where the kills gauge crashes. Both gr_opengl_string() and opengl_aabitmap_ex_internal() do the following things in the following order (with identical code):

GL_state.SetTextureSource(TEXTURE_SOURCE_NO_FILTERING);
GL_state.SetAlphaBlendMode(ALPHA_BLEND_ALPHA_BLEND_ALPHA);
GL_state.SetZbufferType(ZBUFFER_TYPE_NONE);

if ( !gr_opengl_tcache_set(gr_screen.current_bitmap, TCACHE_TYPE_AABITMAP, &u_scale, &v_scale) ) {
(0016559)
Goober5000   
2015-03-16 00:24   
(Last edited: 2015-03-16 00:29)
Did your comment get truncated? Not sure if your code snippet is meant to go to the closing brace, or if you were going to propose another test.

(0016560)
MageKing17   
2015-03-16 00:33   
No, I stopped quoting on the line that the kills gauge crashed on, and I have no other suggestions given there shouldn't actually be any difference in OpenGL calls between those two gauges.
(0016561)
Goober5000   
2015-03-16 11:10   
Did you get anything out of the "enabling triangles.txt" stack trace?
(0016562)
MageKing17   
2015-03-16 12:44   
Given that it happened in std::_Uninit_move(), I'm pretty sure there's memory corruption going on. At this point my recommendation is to reorder retail_gauges[] and/or immerse the computer in holy water before nuking it from orbit, then try to forget this ever happened.
(0016563)
chief1983   
2015-03-16 12:59   
Reordering sounds like a slightly better solution than asking people to disable their kills gauge, and I'm fine to release 3.7.2 with that but it would still be nice to someday understand this behavior more fully.
(0016564)
Goober5000   
2015-03-16 22:07   
Let's not "fix" it by reordering the array, otherwise the problem may manifest it in a different mysterious way and we'll be back to the wild goose chase again.

We really need someone who has a solid knowledge of the graphics code and can audit our API calls to make sure the data is passed in properly. (Or who at least knows what Assertions to put in place that can more precisely detect the problem.) Do we have nobody on the SCP who can fill that role?
(0016571)
MageKing17   
2015-03-22 03:16   
Swifty just found an interesting potential problem while working on the deferred+shadows branch: http://www.hard-light.net/forums/index.php?topic=89379.0

Does this patch affect the issue in any way?
(0016572)
Goober5000   
2015-03-23 02:12   
Alas, no effect. It crashes in the same place.
(0016578)
Goober5000   
2015-03-26 21:32   
On a whim, I decided to try the nightly builds in case this was due to a compiler optimization issue like the infamous Y targeting bug. No such luck. The standard, SSE, and no-SSE builds all crashed.
(0016579)
chief1983   
2015-03-27 09:49   
How about Swifty's deferred lighting branch? If it doesn't crash that way for you, then surely this is just a temporary issue at worst that is already resolved in what will be merged into trunk soon anyway.
(0016582)
Goober5000   
2015-03-27 22:23   
I thought I had posted about that but I guess not. No, neither Swifty's patch against trunk nor Swifty's full branch fixes the crash.
(0016584)
chief1983   
2015-03-28 08:54   
I might have missed it if you had but it's good to have documentation here. Still, I think we're going to have to release without knowing the full cause of the issue at this point. Can we get a reordering patch that at least works around the issue so anyone on Goober's hardware wouldn't have to disable the kills gauge?
(0016585)
Goober5000   
2015-03-28 14:57   
I don't want to "fix" it with a reordering patch. It'll just hide the issue and it's possible that it will then be caused by some other strange combination of settings and we'll have to track it down all over again.

So far no graphics coder has taken a serious look at this ticket. Since Swifty is knowledgeable in the ways of OpenGL I want him to take a look first. If he's stumped too, then we can release.
(0016586)
chief1983   
2015-03-28 23:47   
I appreciate that we do want to get the root cause of this issue fixed, but as it seems to only currently affect an incredibly narrow set of circumstances, of which the ones we're aware of we can work around, I think it's safe to go with the workaround now and see if Swifty can investigate down the road, possibly with his deferred lighting branch which he is probably more comfortable with at this point. I've been requested by our commander in chief to get a release out very soon and don't think we should be waiting any longer for this issue.
(0016587)
Goober5000   
2015-03-29 00:41   
The workaround we know of is to disable the kills gauge. That's reasonable as a workaround. But if we apply a code hack that we neither understand nor know the consequences of, it could backfire. It's better to release with a known bug than a buried land mine.

However, I have managed to find a knowledgeable person who provided some diagnostic logging statements and has a test plan. Let's wait to see how that pans out first.
(0016588)
The_E   
2015-03-29 04:11   
Let's not. This issue seems to be fixed for most people affected due to driver updates, and we've held up this release for far too long already.

I fully understand that the workarounds available are bad. I would absolutely prefer to ship 3.7.2 with this bug understood, fixed and buried, but without some sort of timeframe for this fix, and workarounds available, I'd rather we not keep everyone else waiting.
(0016589)
m_m   
2015-03-29 12:38   
@Goober: We could try looking at the OpenGL calls FSO executes. Can you install GLIntercept (https://code.google.com/p/glintercept/wiki/Downloads?tm=2) and use the FullDebug mode while reproducing the crash?
For comparison it could also help if you provide a glintercept log for when you have the kills gauge disabled. Maybe that will show if something is wrong.
(0016590)
Goober5000   
2015-03-29 13:16   
The E, the timeframe is very short: just a matter of days. We're already making some significant progress -- for instance, we've discovered that the crash occurs on glIsTexture(), not just glBindTexture(), and we've ruled out certain graphics modes.

m!m, I'll take a look at that.
(0016591)
Swifty   
2015-03-29 17:45   
(Last edited: 2015-03-29 17:51)
Some thoughts:

- Can anyone who can reproduce this issue try running with a build before 11165? Perhaps my changes to gr_opengl_string is causing issues.

- While we're on that, can someone try to run the code before the large amount of Xt changes were merged in? The changes that prompted my changes to gr_opengl_string were because of the gr_opengl_string changes from the Xt merges. Basically run a build before 11116.

- Just for the interests of science, can someone comment out the line with renderBitmap in HudGaugeKills::render and see what happens?

- Also try to comment out beam_render, beam_render_muzzle_glow, or beam_generate_muzzle_particles to see what happens.

- Also try out pabst_bleu_ribbon (https://github.com/SamuelCho/Freespace-Open-Swifty/tree/pabst_bleu_ribbon) to see if the bug is persisting there. I replaced all fixed function rendering with a passthrough shader. Maybe Nvidia's drivers aren't very tolerant of fixed function rendering anymore.

(0016592)
Goober5000   
2015-03-29 23:02   
Doesn't seem to be due to the Xt changes. Revision 11115 crashes.

Commenting out the renderBitmap line prevents the crash. But commenting out beam_render, beam_render_muzzle_glow, or beam_generate_muzzle_particles does not.

I checked out the PBR branch and that doesn't crash, but there are no stars and all the ships are black silhouettes.
(0016593)
Goober5000   
2015-03-29 23:49   
M!m, there is no crash when running using GLIntercept. This actually makes sense if GLIntercept uses debug code and the crash is due to a data problem, because garbage values would be sanitized to NULL or other known values.
(0016597)
Goober5000   
2015-04-02 00:43   
Just a quick update to say that progress is being made. We have some debugging callbacks running in the OpenGL functions now.
(0016608)
chief1983   
2015-04-07 15:09   
All right, progress is nice but seriously, we need like daily updates at this point to keep justifying waiting on this bug.
(0016620)
Goober5000   
2015-04-08 00:28   
Sorry, Easter intervened. We're back in contact now though.

Unfortunately the OpenGL debug callback is *itself* crashing, which is leaving us both stumped. I want to give this another day or two, but if after that time we haven't figured it out, then I'll punt and we can release.

So start warming up your release script, and someone should do a quick pass through the tickets to make sure there are no patches for fixed bugs waiting to be committed.
(0016621)
Goober5000   
2015-04-08 01:42   
Actually I may have spoken too soon. I found a way to get the debug callback to run, and I've sent along the appropriate logs. Hopefully they can provide a clue to solving this.

Or they may tell us nothing, in which case revert to my previous comment.
(0016622)
Swifty   
2015-04-08 03:54   
So, I took a careful look at the logs posted in this ticket and I noticed the shaders are displaying a lot of warnings related to the desaturate uniforms in the model rendering shaders. Unfortunately hose warnings don't seem to appear on any other machine I compile those shaders on (Notably an AMD Radeon 290, a Geforce 750M, a Geforce 750M with Mac drivers, and a Geforce 470 GTX). So, this is just a stab in the dark to see if this little bit of code cleanup will fix the issue. Check the attached desaturate_fix.patch file I've uploaded.

I've also noticed that each log file seem to end with the Diffuse and Glow Map shader variant is compiled so I tried to see if there's anything peculiar about the #defines and the #ifdefs concerning glow maps and diffuse in the shaders but I've found nothing.
(0016627)
Goober5000   
2015-04-08 23:13   
(Last edited: 2015-04-08 23:13)
Alas, the desaturate patch didn't fix the beam crash. I've attached the stack trace and log anyway.

On my end, we found and fixed a VBO configuration error and generated a new batch of logs. No smoking gun yet.

(0016632)
Goober5000   
2015-04-09 22:29   
Well, poo. The debug callbacks into the OpenGL functions told us exactly nothing useful. Which means we're out of ideas.

Time to punt on this and release 3.7.2. It sucks, but what are you going to do.
(0016634)
Swifty   
2015-04-09 23:06   
Another patch to try. I noticed that we never call SetShaderMode on the texture unit state handlers when rendering soft particles. Maybe us calling glEnable on a texture unit being used in shader draw calls is causing issues?
(0016635)
Goober5000   
2015-04-10 00:13   
I applied the patch to clean trunk. Alas, it crashed just as before. Logs attached.
(0016636)
Swifty   
2015-04-10 00:21   
Last hunch. Basically I make sure to disable all texture units in opengl_render_internal if we're not doing any texturing.
(0016640)
Goober5000   
2015-04-10 23:50   
Crashed again. :( Logs attached as before.
(0016641)
Goober5000   
2015-04-15 23:08   
Assigning this bug to FSO 4 and untargeting from 3.7.2.
(0016710)
Goober5000   
2015-05-20 01:08   
Hmm. VS 2005 builds from both r11289 and 3.7.2 final exhibit the crash. But VS 2013 builds from both r11289 and 3.7.2 *do not* exhibit the crash.

This makes me think that this error *was* a compiler problem, except that the nightly builds I tested from r11289 to rule out this possibility (see #c16578) crashed as well. I've asked chief1983 what compiler he used to create the r11289 builds.
(0016711)
MageKing17   
2015-05-20 01:13   
All Nightly builds prior to 2015-05-07 (935af40) were built with VS 2008 (since then, they've been built with VS 2013; see also http://www.hard-light.net/forums/index.php?topic=89681.msg1784993#msg1784993).
(0016713)
chief1983   
2015-05-20 08:29   
Yup, what he said. That was the cutover date, and I haven't looked back since.
(0016715)
Goober5000   
2015-05-20 23:46   
I'll test the two nightlies on either side of that date. Tomorrow though.
(0016716)
Goober5000   
2015-05-22 00:05   
Well, so much for that theory. Both 2015-05-06 (4d90765) and 2015-05-07 (935af40) crashed -- and there was even an attempt when 2015-05-06, the VS 2008 build, did *not* crash. This does not make any sense.

Guess I'll shove this ticket back under the bed then.
(0016805)
Goober5000   
2015-12-19 18:06   
Changing description. It's not widely reported anymore, but it has popped again for a couple people, and it certainly is insidious.




View Issue Details
1826 [FSSCP] multiplayer text always 2008-11-20 16:27 2015-12-19 18:05
FUBAR-BDHR  
 
low  
new 3.6.9  
open  
none    
none  
   
Switching to campaign mode doesn't update mission description
If you switch to campaign mode and there is a non coop mission selected the description will not update to the coop missions in the campaign.
3.6.10 11/09 build. Screenshot coming soon.
campaign.jpg (95,827 bytes) 2008-11-20 18:11
http://scp.indiegames.us/mantis/file_download.php?file_id=1152&type=bug
jpg
 
Notes
(0010244)
FUBAR-BDHR   
2008-11-20 18:27   
Was in a bit of a hurry when I posted (hosting) and forgot to mention the host side updates find so it's a client side only thing.
(0016700)
Cyborg17   
2015-05-09 13:31   
(Last edited: 2015-05-09 13:32)
I've started looking at this issue, and I would like to see if I can try to solve it since it's sufficiently minor and would be a good project for me as I continue to try to understand the code and C++ better.

Problem still occurs in the most recent nightly. I'm able to test it on one computer by forcing different ports on multiple instances of the launcher for the same build.

(0016705)
Cyborg17   
2015-05-15 13:58   
Update on my progress:

This feature was never implemented into the engine, probably because it was not that useful a feature, and (I think) requires a new function or edits to an existing function. The logic for requesting the description is in place, but the function was not written in because the function is only able to send information on the current mission. I'm still game for trying it for now. I might jump on IRC for assistance.
(0016712)
Cyborg17   
2015-05-20 03:16   
I think I got it! I have the description field updating for campaign files. Only the host's exe needs to be updated as well, actually. The only issues might be with how I accomplished it. The Netgame_Info class has two new entries which aren't carried by the function which used to send the whole class. One of the entries is an int, acting as a boolean, which will tell you if the host is trying to select campaign or non-campaign games. So, a *little* disorganized, but I added good comments. You guys may want me to rearrange it to be a little cleaner. Like with a new class or something.

And now I'm in the odd position of not knowing how to post a patch file to share the proposed fix with. Would anyone be able to send me in the right direction? Should I just get on Github and try from there or should I try posting a patch here?
(0016714)
Cyborg17   
2015-05-20 20:26   
Pull request has been added to GIT. :)
(0016745)
Cyborg17   
2015-05-31 22:28   
File was too large to upload directly. So I have a mediafire link:

http://www.mediafire.com/download/xncrt05fvgmlfkd/fs2_open_3_7_3_AVXMANTIS1826CANDIDATE.7z
(0016804)
Goober5000   
2015-12-19 18:04   
(Last edited: 2015-12-19 18:05)
A github link would be nice to have. :p

Searching git yields four PRs, all closed:
https://github.com/scp-fs2open/fs2open.github.com/pull/122
https://github.com/scp-fs2open/fs2open.github.com/pull/189
https://github.com/scp-fs2open/fs2open.github.com/pull/190
https://github.com/scp-fs2open/fs2open.github.com/pull/191

Has there been any progress on a new PR?





View Issue Details
2024 [FSSCP] AI minor N/A 2009-11-09 23:41 2015-09-22 17:29
chief1983  
Goober5000  
high  
assigned 3.6.11  
open  
none    
none  
   
Design tweaks and refactoring in Sushi's AI code
It needs to be cleaned up. Per Goober.
 
Notes
(0011281)
Sushi_CW   
2009-11-14 10:10   
More specific details/suggestions on what needs to be cleaned up and how would be uber-handy. I have "I wrote it" myopia. :)
(0013996)
iss_mneur   
2012-10-27 20:57   
Goober please provide Sushi with the feedback that he requested.
(0014191)
The_E   
2012-11-26 06:35   
Closing this. Mantis is IMHO not the right venue for this kind of discussion; and simple one-liners like "a bit of a mess" are not constructive criticism.
(0014192)
Goober5000   
2012-11-26 19:03   
(Last edited: 2012-11-26 19:04)
Reopening. There are a bunch of legitimate design concerns that should be addressed here, but I need to sit down and outline them. There should be a thread on HLP where we've discussed some of them, such as putting all the AI arrays under the umbrella of a struct rather than as separate instances.

I'll provide Sushi with the requested feedback, but not until after 3.7 is out, since this is more of a design and future-proof ticket than a bugfix ticket.

I've renamed the ticket since the original name was of course not really descriptive or constructive.

(0016785)
m_m   
2015-09-22 17:29   
I have unset the target version because there is no clearly defined bug in the description.




View Issue Details
2826 [FSSCP] graphics feature N/A 2013-03-28 21:40 2015-09-19 22:15
Hunter  
m_m  
normal  
confirmed 3.6.18  
open  
none    
none  
   
a Multi screen feature.
Every time I want to run FS2 in full window mode I have to shut off monitors, or unplug monitors... I have played many games where choosing your gameplay monitor in the launcher, please consider this feature.
 
Notes
(0014848)
chief1983   
2013-03-28 21:52   
Is using the primary monitor not sufficient?
(0014849)
Hunter   
2013-03-28 22:38   
(Last edited: 2013-03-28 22:48)
Every time i want to play on my scondary screens (# 2 or # 3) I have to mess with things for this game. So no my 18" 10 year old screen for icons and chat screens is not good enough. I like new apps and new messages appearing on a screen other then my Television or Gaming screen. I am sure I am not the only soul on this planet who uses more then one screen on their system.

(0014851)
chief1983   
2013-03-28 23:03   
Probably not but most seem to be ok playing on the primary.
(0015023)
Zacam   
2013-05-03 13:00   
I'm pretty sure most games just default to whatever the reported primary device is for the display, unless by activation of some video card related software that manages the "routing" for the display output based on application.

As an idea worth looking into though, it really isn't a bad one. I'm just not entirely sure how long it will take to implement, assuming that it can be.

It'll take collaborating the work for the display detection with the Launcher and set FSO to be able to accept a Display setting parameter to be passed.
(0016012)
chief1983   
2014-07-02 12:12   
Don't know why this is assigned to me though, it's beyond my current abilities.
(0016762)
Italianmoose   
2015-07-11 13:36   
Which OS is this? (I presume Windows, which I have no idea how to fix, although http://dualmonitortool.sourceforge.net/index.html may help). On Linux, this is easier to fix, it's mentioned in the Wiki.
(0016779)
m_m   
2015-09-06 16:44   
SDL2 has proper support for multiple displays so adding support for that is very easy so I added it: https://github.com/scp-fs2open/fs2open.github.com/pull/342
Currently there is no launcher support so you'll have to manually add the config file entry Video.Display=<x>.
(0016784)
Goober5000   
2015-09-19 22:15   
What about a command-line option?




View Issue Details
3171 [FSSCP] FRED minor always 2015-08-08 08:59 2015-08-08 08:59
z64555 x86_64  
Microsoft Windows  
normal 8.1  
new 3.7.2  
open  
none    
none  
   
FRED doesn't copy multiple waypoint lists
Left-clicking and dragging a waypoint while the Control key is held down results in the waypoint being copied into a new list. If multiple waypoints are selected, then they are all copied into a new list respecting their waypoint order.

However, if the selection has two or more waypoint lists, the resulting copy is one new list instead of having the expected duplicate waypoint lists.
Open FRED.
Create two or more waypoint lists.
Select all waypoints, then click-drag with Ctrl held down to copy them. The resulting copy operation has all waypoints in one new list
MS Windows 64-bit OS
Intel Core i7 4700-MQ
NVIDIA GeForce GTX 770M
 
There are no notes attached to this issue.




View Issue Details
3082 [FSSCP] graphics minor always 2014-08-03 14:48 2015-06-26 07:25
zookeeper  
Echelon9  
normal  
assigned  
open  
none    
none  
   
gr.drawModel draws model inside out if rendering to texture
If the gr.drawModel scripting function is used for example in an $On Frame hook, it renders the model correctly, except if we're rendering to a texture, in which case the model gets rendered with its polys seemingly inverted.

I recently fixed some similar'ish bugs pertaining to the RTT code, but this one persists and I haven't been able to figure it out despite spending countless hours on it. I did conclude that it's not a case of the projection matrix being any different depending on whether doing RTT or not (except the difference due to target aspect ratio), and didn't find any indication of anything else being wrong with the setup of the matrices (gr_set_proj_matrix/gr_opengl_set_projection_matrix and gr_set_view_matrix/gr_opengl_set_view_matrix), but of course I might have missed something.

Attached is a simple test mod consisting only of one script, which 1) renders the player ship's model in front of the camera onto a texture and then 2) draws the texture in the top left corner of the screen.

The commented-out lines in the script are for using a custom camera, which isn't needed for reproducing but any fix should probably be tested with those lines uncommented as well, because in real usage one would almost always use a custom camera like that, and it might very well be affected by the fix one way or another.
rtttestmod.zip (1,394 bytes) 2014-08-03 14:48
http://scp.indiegames.us/mantis/file_download.php?file_id=2506&type=bug
 
There are no notes attached to this issue.




View Issue Details
3167 [FSSCP] HUD minor always 2015-06-24 00:02 2015-06-24 00:02
Yarn x64  
Windows 7  
normal  
new 3.7.3  
open  
none    
none  
   
Offscreen indicator does not stay on center monitor
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.
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.
 
There are no notes attached to this issue.




View Issue Details
3164 [FSSCP] graphics minor always 2015-06-05 05:55 2015-06-05 05:55
zookeeper  
Swifty  
normal  
assigned 3.7.3  
open  
none    
none  
   
-destroyed turrets have wrong orientation
If a multipart turret has a -destroyed version, it will not be drawn in the same orientation the turret base was in when it was destroyed. It seems that the orientation of the -destroyed submodel doesn't take the turret base's fvec/uvec into account.

This is likely introduced by the new rendering code. Previously, a -destroyed turret appeared facing exactly the same direction as the live turret was when it got destroyed. Now, it only works correctly if the -destroyed submodel is given the same fvec/uvec as the turret base.
 
There are no notes attached to this issue.




View Issue Details
3010 [FSSCP] beams minor always 2014-02-18 14:59 2015-05-22 01:35
Joshua R10541  
Windows  
low 7  
new 3.7.1  
open  
none    
none  
   
Beams stay whilst ship casting them has been destroyed.
I am aware of a ship being capable of shooting weapons whilsts it's in it's "Final detonation" sequence, but currently, beams are able to fully finish their firing sequence even though the ship firing has been destroyed. The beams "Stay on" for their predetermined time whilst the ship's model has already been reduced to fiery debris.
Tested repeatedly in the "Rescue" mission of the "Incursion" campaign (as provided by the campaign restoration project")
 
Notes
(0016718)
SmashMonkey   
2015-05-22 01:04   
Replicable. Inspection of beam.cpp shows that the check for beam firing only takes place during the beam warmup. There is no way to turn off the beams mid-firing (if the firing ship has been destroyed).
(0016720)
MageKing17   
2015-05-22 01:35   
There is code that is supposed to serve this purpose, in beam_move_all_pre():

        // check if parent object has died, if so then delete beam
        if (b->objp->type == OBJ_NONE) {
            // set next beam
            moveup = GET_NEXT(moveup);
            // delete current beam
            beam_delete(b);

            continue;
        }


The object's type should be set to OBJ_NONE when it's deleted, which should happen shortly after OF_SHOULD_BE_DEAD gets set, which should happen if the ship is either vaporized or finished exploding.

Is the problem that beams aren't stopping during the process of dying? Because that seems like intended behavior.




View Issue Details
3159 [FSSCP] sound minor always 2015-05-17 09:58 2015-05-17 17:45
Axem  
m_m  
normal  
assigned 3.7.3  
open  
none    
none  
   
looping with play-sound-from-file isn't seamless
It's near impossible to have a seamless looping music track in missions because there is a very small break in the audio when the game has to loop back to the start.

See attached "music" (its just a tone) and mission for an example. The tone should be constant, but its not!
psff_bug.rar (7,448 bytes) 2015-05-17 09:58
http://scp.indiegames.us/mantis/file_download.php?file_id=2708&type=bug
 
Notes
(0016708)
m_m   
2015-05-17 17:45   
The timer interval used for looping sounds is way to high. Currently the timer fires every 250 ms which causes the audible gap in the sound. Even lowering it to 20 doesn't solve that.
The audiostream code is pretty ugly and does a lot of things for no good reason (why use a timer instead of running things on the main thread? Why not just continue writing data into the buffer when we want the sound to loop?).




View Issue Details
3155 [FSSCP] HUD major sometimes 2015-04-05 19:56 2015-04-23 23:06
Yarn  
 
normal  
new 3.7.2 RC5  
open  
none    
none  
   
Some HUD tables break targeting brackets at 4K resolutions
As leoben pointed out in this thread (http://www.hard-light.net/forums/index.php?topic=89450.0), Blue Planet 2's HUD table is causing targeting brackets, as well as almost everything else that follows the brackets, to be missing or displayed improperly at very high resolutions like 3840x2160. More common resolutions like 1920x1080 appear to be unaffected.

Plain FS2 does not exhibit the problem, and neither do the 2014 MediaVPs. However, if BP2's HUD table is stripped of its custom gauges and fonts and is then used with plain FS2, then the problem occurs. Thus, the problem is not specific to BP2.

The culprit was determined to be revision 10990, which was meant to fix Mantis 0002985 by introducing proper rounding to the gr_[re|un]size_screen_pos(f) functions. (The problem also existed between revisions 10844 [inclusive] and 10868 [exclusive] whenever the HUD was scaled, regardless of the resolution.)
Download the attached table (which uses the BP2 layout but is compatible with plain FS2) to FreeSpace2\data\tables and play a mission at 3840x2160 resolution without mods. The targeting brackets and perhaps other things like the lead indicator will be either missing or placed at the wrong part of the screen.
I still don't know what part of the HUD table is triggering the problem, why this only occurs at very high resolutions, or how this can be fixed without ditching rounding. I intend to work with leoben in this ticket to find out. Help from others who can run the game in 4K is also welcome.
mv_root-hdg.tbm (4,885 bytes) 2015-04-05 19:56
http://scp.indiegames.us/mantis/file_download.php?file_id=2680&type=bug
test_4-hdg.tbm (2,613 bytes) 2015-04-06 21:14
http://scp.indiegames.us/mantis/file_download.php?file_id=2683&type=bug
test_6-hdg.tbm (85 bytes) 2015-04-06 21:14
http://scp.indiegames.us/mantis/file_download.php?file_id=2684&type=bug
test_7-hdg.tbm (2,634 bytes) 2015-04-07 01:11
http://scp.indiegames.us/mantis/file_download.php?file_id=2685&type=bug
test_8-hdg.tbm (2,594 bytes) 2015-04-07 21:08
http://scp.indiegames.us/mantis/file_download.php?file_id=2687&type=bug
test_9-hdg.tbm (2,594 bytes) 2015-04-07 21:08
http://scp.indiegames.us/mantis/file_download.php?file_id=2688&type=bug
 
Notes
(0016598)
leoben   
2015-04-06 00:40   
I'm ready for testing
(0016599)
Yarn   
2015-04-06 01:11   
Here are the first builds that I want you to try:

Test 1: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/fs2_open_3_7_1_mantis_3155_test_1_SSE2.zip
Test 2: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/fs2_open_3_7_1_mantis_3155_test_2_SSE2.zip
Test 3: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/fs2_open_3_7_1_mantis_3155_test_3_SSE2.zip

All three builds are based on revision 11296 with these changes:

Test 1: Simple revert of revision 10990.
Test 2: Changed fl2ir() (the rounding function) to round up instead of away from zero in halfway cases (like 3.5).
Test 3: Changed fl2ir() to use C++11's round() function. (For the sake of compatibility with older compilers, this change won't be committed even if it does work, but it's still worth trying.)
(0016601)
leoben   
2015-04-06 19:28   
Build 1 - works OK
Build 2 - bad, just as before
Build 3 - bad, but worse than before. Rather than the brackets disappearing only after the first time your target moves out of your screen (until you do that, all other faulty builds worked OK), with this build you begin with the brackets being off screen immediately and/or in one of the corners of your screen, though your target is smack in the middle.
(0016602)
Yarn   
2015-04-06 21:14   
I expected Test 1 to work. It's not optimal, though, since it reintroduces 0002985, which I'm hoping to avoid.

It's odd that Test 3 made things worse. At least we don't have to worry about that for now.

Next, I want you to try some HUD tables using the latest nightly build without mods. To try a table, place it in FreeSpace2\data\tables and rename it to "mv_root-hdg.tbm". (And make sure that Windows Explorer is not hiding file extensions, or else you might inadvertently name it "mv_root-hdg.tbm.tbm", which will not work with the game.)

Here are the tables that I want you to try:

Test 4: The file "test_4-hdg.tbm", which is attached to this report. It's basically the built-in HUD in the form of a table.
Test 5: The file "mv_root-hdg.tbm" that's attached to Mantis 0002672.
Test 6: The file "test_6-hdg.tbm", which is attached to this report. This one has a HUD configuration with no gauges defined. All the gauges should still work, though.
(0016603)
leoben   
2015-04-06 21:55   
The plot thickens. Tests 4 and 6 failed. 5 is OK.
(0016604)
Yarn   
2015-04-06 22:41   
Oh yeah, I forgot to tell you to remove the first $Max line from Test 5. Do that and then try it again.
(0016605)
leoben   
2015-04-07 00:14   
OK, that screwed it up. So tests 4-6 all failed now.
(0016606)
Yarn   
2015-04-07 01:11   
Here's another table to try:

Test 7: The file "test_7-hdg.tbm", which is attached to this report. Same as Test 4, but with scaling disabled.
(0016607)
Yarn   
2015-04-07 14:30   
Are you sure that you're testing with no mods whatsoever (not even the MediaVPs and definitely not BP2) and that you only have one *-hdg.tbm file in the FreeSpace\data\tables folder at any given moment? If not, then please do these things and run tests 4-7 again.
(0016610)
leoben   
2015-04-07 20:22   
Yes, I'm very sure - thanks for checking. Test 7 - works OK, targeting brackets are normal.
(0016611)
Yarn   
2015-04-07 21:07   
Two more tables to try:

Test 8: The file "test_8-hdg.tbm", which is attached to this report. Same as Test 4, except the base resolution is 3840x2160. Scaling isn't explicitly disabled, but it should work anyway since the base resolution matches your resolution.

Test 9: The file "test_9-hdg.tbm", which is attached to this report. Same as Test 4, except the base resolution is 3200x2048. This will test whether just a little scaling at very high resolutions causes the problem.

I also want you to try a bunch of resolutions between 3840x2160 and 1920x1080 using either Test 4 or Test 6. This should give me an idea as to how high the resolution must be for this problem to occur. (Remember that you can use resolutions that your system doesn't support in full-screen mode by using windowed mode and the -res flag.)
(0016613)
leoben   
2015-04-07 21:42   
OK, both 8 and 9 check out fine. Note however that I didn't see any scaling on HUD elements (not sure if I should've seen any). Test 4 fails only at 4K resolution. 1440p is fine. Not sure what the point is of trying anything between the two, as there are no monitors that have native resolutions between those two (at least not that I'm aware of).
(0016614)
MageKing17   
2015-04-07 22:05   
"Not sure what the point is of trying anything between the two, as there are no monitors that have native resolutions between those two (at least not that I'm aware of)."

To see what level of scaling starts to cause problems. It's intended to narrow down the cause of the issue, not provide testing of real-world use conditions.
(0016615)
Yarn   
2015-04-07 22:06   
There should be scaling in Test 9, although it might be hard to notice a difference since there really isn't much scaling at all (only about 5.5%).

Yes, there is a point in testing non-standard resolutions. If, for example, the problem starts at around 2048x1536 (a good resolution to test, actually), then that would suggest that the problem occurs when the HUD is scaled 2x or more. You don't have to (and shouldn't) limit yourself to native resolutions of monitors that you can find.
(0016616)
leoben   
2015-04-07 23:06   
OK, interesting find. I remembered I never tested in windowed mode until I tried a custom resolution - didn't want to drive my monitor to insanity to resolutions it didn't support in overlay mode. So I tried your suggested resolution, it worked fine. Then I tried 4K again in FS mode just to make sure I'm still using the right tbm file. In FS mode, it immediately produced the issue. But when I tried 4K in windowed mode, the problem never surfaced. So - chew on that for a while :)
(0016617)
Yarn   
2015-04-07 23:19   
Can you try a fullscreen window at 4K?
(0016618)
leoben   
2015-04-07 23:27   
Yes. Same as FS - bad. Only Windowed mode is good.
(0016619)
Yarn   
2015-04-07 23:40   
(Last edited: 2015-04-08 01:36)
Perhaps windowed mode is working because a small portion of the window is off the screen. This time, play in windowed mode, but use the -res parameter to shrink the resolution just enough so that the entire window, border included, fits within the screen. If the brackets still work, then try a fullscreen window at that same resolution.

EDIT: Can you also test various resolutions (including non-standard ones) in a fullscreen window?

(0016625)
leoben   
2015-04-08 21:59   
Tested a slightly lower (100x100) resolution in windowed mode - suddenly targeting brackets were gone.
(0016626)
leoben   
2015-04-08 22:19   
OK - I think I'm getting on to something. I tried a gazillion custom resolutions now. Turns out once you go over 2000 pixels vertically, the brackets start disappearing. So for example, a 3840x1999 resolution would work just fine, once you go to 3840x2000, it's screwed up. This was done using FS window mode.
(0016628)
Yarn   
2015-04-09 01:22   
If you reduce the horizontal resolution to less than 2665, do the brackets still stop working at 2000 vertical pixels?
(0016629)
leoben   
2015-04-09 19:34   
I'm lost now - 2664x1999 will also lose brackets. It just took more time to happen.
(0016630)
Yarn   
2015-04-09 20:53   
Yeah, I'm completely lost too. It appears that the changes in revision 10990 aren't directly responsible for your problem; rather, they probably only exposed an existing bug. Considering that the brackets work fine when no table is used yet don't work with Test 6's table (both of which should produce the same result), and that running in a bordered window that doesn't fit the screen somehow makes the brackets work, it seems highly improbable that revision 10990 is the real culprit.

Since this issue is most likely beyond my expertise (and I don't have access to a 4K display), I'm unassigning this issue. Additionally, because the SCP team wants to release 3.7.2 Final soon, very few players will run into this issue, and there's a (admittedly not ideal) workaround for this issue (play in 1080p), I'm clearing the Target Version field.

The only thing left that I can think of is for you to ensure that your video driver is up to date.
(0016631)
leoben   
2015-04-09 20:57   
Since I work for one of the two companies that create high-end GPUs, this goes without saying :)

Thanks for the help, I guess I'll use an earlier build that doesn't have scaling.
(0016633)
Yarn   
2015-04-09 22:31   
Um, ALL builds (except for very early ones) have scaling, which is necessary to support resolutions other than 640x480 and 1024x768. Just use a pre-10990 build until this can be fixed.
(0016637)
Italianmoose   
2015-04-10 18:12   
Hurrah. Confirmed replicated at 3840x2400 (Nvidia DSR) on Windows 7 64bit.
(0016661)
Goober5000   
2015-04-23 23:06   
Untargeting for 3.7.2, since it's out.




View Issue Details
2638 [FSSCP] speech feature always 2012-04-13 00:20 2015-04-23 13:39
gereedy  
Echelon9  
normal  
code review  
open  
none    
none  
   
Support speech on OSX
This patch implements text-to-speech for mac os x.
macspeech.patch (5,716 bytes) 2012-04-13 00:20
http://scp.indiegames.us/mantis/file_download.php?file_id=1828&type=bug
macspeech2.patch (5,747 bytes) 2012-04-13 15:54
http://scp.indiegames.us/mantis/file_download.php?file_id=1829&type=bug
macspeech3.patch (5,999 bytes) 2012-08-14 10:16
http://scp.indiegames.us/mantis/file_download.php?file_id=1932&type=bug
macspeech4.patch (4,887 bytes) 2014-06-30 18:20
http://scp.indiegames.us/mantis/file_download.php?file_id=2435&type=bug
macspeech5.patch (5,020 bytes) 2015-04-23 13:09
http://scp.indiegames.us/mantis/file_download.php?file_id=2703&type=bug
 
Notes
(0013464)
gereedy   
2012-04-13 15:54   
Oops, I forgot to release the strings. Here's an updated patch.
(0013479)
Echelon9   
2012-04-23 10: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 00: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 11: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-03 23: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 15:07   
Huh, and here I thought we'd need to be using Festival across the board.
(0013905)
Echelon9   
2012-08-14 09: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 10:16   
A more recent patch version is attached (macspeech3.patch)
(0015977)
chief1983   
2014-06-30 18: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 18:21   
(Last edited: 2014-06-30 18: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-06-30 20:26   
Thanks, I'll take another look at the memory corruption here. Looks like another double free.
(0016000)
Echelon9   
2014-07-01 08: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 09: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 10: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 10:36   
(Last edited: 2014-07-01 10: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 11: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 11: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 13:06   
(Last edited: 2015-04-23 13: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 13: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
2953 [FSSCP] minor always 2013-11-15 23:59 2015-04-16 00:24
Echelon9  
Echelon9  
normal  
assigned 3.7.1  
open  
none    
none  
   
AddressSanitizer: stack-buffer-overflow in ade_set_args()
Reported by AddressSanitizer, a memory error detector for C/C++, in FS2Open builds based on trunk r10041.

ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5fbfd320 at pc 0x1028940c0 bp 0x7fff5fbfcb10 sp 0x7fff5fbfcb08
READ of size 4 at 0x7fff5fbfd320 thread T0
    #0 0x1028940bf in ade_set_args lua.cpp:15069
    0000001 0x1028971e6 in script_state::CreateLuaState lua.cpp:14631
    0000002 0x10292a63b in script_init scripting.cpp:187
    0000003 0x10014a1c6 in game_init freespace.cpp:1853
    0000004 0x10018b11b in game_main freespace.cpp:6995
    0000005 0x10018cdc6 in SDL_main freespace.cpp:7186
    ...


int ade_set_args(lua_State *L, char *fmt, ...)
{
    //Start throught
    va_list vl;
    int nargs;
    int setargs; //args actually set

    va_start(vl, fmt);
    nargs = 0;
    setargs = 0;
    while(*fmt != '\0')
    {
        switch(*fmt++)
        {
                        ...
            case 'o':
                {
                    //WMC - char must be 1 byte, foo.
                    Assert(sizeof(char)==1);
                    //WMC - step by step
                    //Copy over objectdata
                    ade_odata od = (ade_odata) va_arg(vl, ade_odata);

                    //Create new LUA object and get handle
                    char *newod = (char*)lua_newuserdata(L, od.size + sizeof(ODATA_SIG_TYPE));
                    //Create or get object metatable
                    luaL_getmetatable(L, Ade_table_entries[od.idx].Name);
                    //Set the metatable for the object
                    lua_setmetatable(L, -2);

                    //Copy the actual object data to the Lua object
                    memcpy(newod, od.buf, od.size);

                    //Also copy in the unique sig
                    if(od.sig != NULL)
                        memcpy(newod + od.size, od.sig, sizeof(ODATA_SIG_TYPE)); <================
                    else
                    {
                        ODATA_SIG_TYPE tempsig = ODATA_SIG_DEFAULT;
                        memcpy(newod + od.size, &tempsig, sizeof(ODATA_SIG_TYPE));
                    }
                    break;
1. Utilise a version of Clang that supports AddressSantizer (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer).
2. Build with -fsanitize=address C/C++ flag
3. Run the game with mediavps 3.6.12, error reported during startup.
ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5fbfd320 at pc 0x1028940c0 bp 0x7fff5fbfcb10 sp 0x7fff5fbfcb08
READ of size 4 at 0x7fff5fbfd320 thread T0
    #0 0x1028940bf in ade_set_args lua.cpp:15069
    0000001 0x1028971e6 in script_state::CreateLuaState lua.cpp:14631
    0000002 0x10292a63b in script_init scripting.cpp:187
    0000003 0x10014a1c6 in game_init freespace.cpp:1853
    0000004 0x10018b11b in game_main freespace.cpp:6995
    0000005 0x10018cdc6 in SDL_main freespace.cpp:7186
    0000006 0x100003401 in -[SDLMain applicationDidFinishLaunching:] SDLMain.m:300
    0000007 0x7fff8fb26fcb in __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ (in CoreFoundation) + 11
    0000008 0x7fff8fa1ac5c in _CFXNotificationPost (in CoreFoundation) + 2892
    0000009 0x7fff8b4ea4a9 in -[NSNotificationCenter postNotificationName:object:userInfo:] (in Foundation) + 67
    0000010 0x7fff8e920b78 in -[NSApplication _postDidFinishNotification] (in AppKit) + 288
    #11 0x7fff8e9208ab in -[NSApplication _sendFinishLaunchingNotification] (in AppKit) + 194
    0000012 0x7fff8e91d795 in -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] (in AppKit) + 569
    0000013 0x7fff8e91d1ea in -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] (in AppKit) + 241
    0000014 0x7fff8b508ea9 in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] (in Foundation) + 293
    0000015 0x7fff8b508d1c in _NSAppleEventManagerGenericHandler (in Foundation) + 105
    0000016 0x7fff8f743e1e in aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) (in AE) + 380
    0000017 0x7fff8f743c31 in dispatchEventAndSendReply(AEDesc const*, AEDesc*) (in AE) + 30
    0000018 0x7fff8f743b35 in aeProcessAppleEvent (in AE) + 314
    0000019 0x7fff8c32c5f0 in AEProcessAppleEvent (in HIToolbox) + 55
    0000020 0x7fff8e9190f5 in _DPSNextEvent (in AppKit) + 1025
    0000021 0x7fff8e9188da in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 121
    0000022 0x7fff8e90c9cb in -[NSApplication run] (in AppKit) + 552
    0000023 0x1000054f1 in CustomApplicationMain SDLMain.m:227
    0000024 0x100004fca in main SDLMain.m:377
    0000025 0x100001f93 in start (in FS2_Open (debug)) + 51
    0000026 0x0 in 0x0

Address 0x7fff5fbfd320 is located in stack of thread T0 at offset 576 in frame
    #0 0x102891f0f in ade_set_args lua.cpp:15011

  This frame has 9 object(short):
    [32, 40) 'L.addr'
    [96, 104) 'fmt.addr'
    [160, 184) 'vl'
    [224, 228) 'nargs'
    [288, 292) 'setargs'
    [352, 360) 'short'
    [416, 448) 'od'
    [480, 488) 'newod'
    [544, 548) 'tempsig' <== Memory access at offset 576 overflows this variable
HINT: this may be signed char false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x1fffebf7fa10: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x1fffebf7fa20: 00 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2
  0x1fffebf7fa30: 00 00 00 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2
  0x1fffebf7fa40: 04 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2
  0x1fffebf7fa50: 00 00 00 00 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2
=>0x1fffebf7fa60: 04 f4 f4 f4[f3]f3 f3 f3 00 00 00 00 00 00 00 00
  0x1fffebf7fa70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffebf7fa80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffebf7fa90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffebf7faa0: f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4
  0x1fffebf7fab0: f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable: 00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone: fa
  Heap right redzone: fb
  Freed heap region: fd
  Stack left redzone: f1
  Stack mid redzone: f2
  Stack right redzone: f3
  Stack partial redzone: f4
  Stack after return: f5
  Stack use after scope: f8
  Global redzone: f9
  Global init order: f6
  Poisoned by user: f7
  ASan internal: fe
==82223==ABORTING
 
There are no notes attached to this issue.




View Issue Details
2355 [FSSCP] FRED feature always 2010-12-15 20:45 2015-04-16 00:23
FUBAR-BDHR  
 
normal  
new 3.6.13  
open  
none    
none  
   
Primary and secondary banks with no default weapons cannot be set
While you can set a weapon to none in FRED there is no way to have a turret set to none by default (not counting hacking a dummy weapon into the tables). Entries in the tables like $Default Sbanks: ( "" ) are legal but there is no way to change them as parsing doesn't actually count them as defined banks since weapon_info_lookup fails.

Also these banks are changeable via sexp but in tests on secondaries do not fire.
 
Notes
(0014564)
Valathil   
2012-12-22 16:29   
Could a fix for this break currently existing missions?
(0014567)
FUBAR-BDHR   
2012-12-22 16:57   
I don't see how. Any existing models that have weapons tabled this way couldn't have used those weapons in missions. As the default would still be no weapon behavior should not change. This would just allow those weapon banks to be used in new missions.




View Issue Details
2720 [FSSCP] graphics feature N/A 2012-10-30 04:53 2015-04-16 00:22
The_E  
The_E  
low  
assigned 3.6.16  
open  
none    
none  
   
Loadout screen does not show external weapon models
Which it really should, for immersion value and stuff
 
There are no notes attached to this issue.




View Issue Details
3147 [FSSCP] AI major always 2015-02-27 05:41 2015-03-18 00:29
niffiwan  
Admiral MS  
normal  
feedback 3.7.2 RC5  
fixed  
none    
none  
   
AI rams stationary targets
The AI seems to have problems with stationary targets, when attacking it doesn't avoid them. Instead it ineffectually rolls before charging into the target.

Note: originally reported by Spoon who 1st encountered this in WoD
See attached mission (originally from Axem, made no-mod compatible and slightly tweaked by me). Stop moving and wait for the Perseus to attack you. Don't evade or shoot, your ship is invulnerable. Most of the time the Perseus will ram you and kill itself.

When the 1st Perseus is dead, a 2nd one will warp in and attack. This one will usually manage to avoid you completely.

The only difference between the two ships is that the 1st carries Rockeyes, the 2nd carries Harpoons.
This one has wierd written all over it. In addition to the oddball change in behaviour due to carrying aspect seekers or not, you also have these gems:

1) removing primary weapons make the AI evade correctly
2) clearing/removing AIF_SEEK_LOCK from the check in avoid_ship() makes all the AI ram you
3) making it so that set_predicted_enemy_pos() isn't called makes the AI evade correctly

And some more general info from IRC:

MageKing17: At a range of approx 600 meters, it enters the SM_AVOID submode.
MageKing17: Here is where behavior diverges; with aspect-seekers, it sets AIF_SEEK_LOCK, avoids calling set_predicted_enemy_pos(), and changes direction immediately upon entering SM_AVOID.
MageKing17: SM_AVOID is a submode of AI_CHASE, so if it can still hit with its weapons, it will continue firing.
MageKing17: For instance, it can and will fire off a missile in the middle of its avoidance manuever.
MageKing17: Without aspect-seekers, it calls set_predicted_enemy_pos() and for some reason, instead of changing direction, it rolls while remaining on its course, usually colliding with the player.
MageKing17: The problem cannot lie in the aspect-seeking code, because commenting out the calls to set_predicted_enemy_pos() results in the proper behavior without aspect seekers.
MageKing17: And preventing AIF_SEEK_LOCK from being set (which results in set_predicted_enemy_pos() getting called) causes the improper behavior even with aspect seekers.
MageKing17: There are a few oddities: even with the "improper" behavior, it can still sometimes break off, but this happens seemingly at random.
MageKing17: The breaking off seems to be more likely if you increase its rotational velocities, for some reason.
MageKing17: As far as I can determine, the relevant side effects of set_predicted_enemy_pos() are to introduce a very slight randomness to the predicted enemy position, and to set a couple of globals.
MageKing17: Since G_collision_time isn't used and I just checked and setting G_predicted_pos outside of set_predicted_enemy_pos() has no effect, the relevant effect must be the slight randomness added to the predicted position.
MageKing17: It's very slight, however; in my stepping through with the debugger, it was maybe a meter or two.
cs_suicide.fs2 (4,778 bytes) 2015-02-27 05:41
http://scp.indiegames.us/mantis/file_download.php?file_id=2656&type=bug
ai_no_ramming.patch (576 bytes) 2015-03-02 10:21
http://scp.indiegames.us/mantis/file_download.php?file_id=2657&type=bug
aicode.cpp.patch (938 bytes) 2015-03-03 19:38
http://scp.indiegames.us/mantis/file_download.php?file_id=2659&type=bug
 
Notes
(0016517)
niffiwan   
2015-02-27 06:02   
(Last edited: 2015-02-27 06:05)
Some more notes: the issue seems to have been introduced somewhere between 3.6.14 and 3.6.16. In 3.6.14 "Rockeye" seems to reliably avoid a collision by pulling up at the last minute.

I've also noticed that mission time seems to effect the avoid behaviour, if I let both ships attack in turn I have different behaviour from "Harpoon" to when I kill "Rockeye" at mission start by firing a missile at it.

And, there seems two types of successful avoidance behaviours:
1) pull up at the last minute
2) start avoiding much further away and make one or short short secondary passes to fire primaries at the target.

(0016518)
MageKing17   
2015-02-27 14:18   
There are a number of behaviors in the AI code that use Missiontime as a pseudorandom value, so the fact that the time affects the behavior isn't that surprising to learn (in my tests, I used two separate missions to minimize differences due to Missiontime changes).

As far as I can determine, "pull up at the last minute" is a subset of "it can still sometimes break off, but this happens seemingly at random", but heck if I know why the different behaviors.

Also, the "short secondary passes" are actually it leaving SM_AVOID mode; when it breaks off again, it has re-entered SM_AVOID.
(0016520)
Spoon   
2015-02-28 17:37   
On the subject of mission time and behavior, something that may affect testing in that regard is the $allow primary link delay flag in ai_profiles.tbl
(0016521)
niffiwan   
2015-03-01 04:22   
Thanks for the info about $allow primary link delay / $allow primary link at mission start, that explains why the Harpoon would firelink primaries and Rockeye didn't.

More testing has proved my previous statement incorrect, "pull up at last minute" seems to depend on a factor that I can't figure out, making it seem random per MageKing17's comment. I've also seen it occur as far back as 3.6.12. In any event, the AI sure as heck isn't evading when it enters SM_AVOID and it *should* be.
(0016525)
Admiral MS   
2015-03-02 10:26   
(Last edited: 2015-03-02 10:26)
Uploaded a svn patch which should fix this bug. Kinda got off into the wrong direction until I figured that it has to be somewhere else.

(0016526)
MageKing17   
2015-03-02 15:34   
Good catch.

Further testing reveals this bug has been present since retail; along with a related issue that since the AIF_SEEK_LOCK branch doesn't set G_predicted_pos and G_fire_pos, the AI is more likely to miss with primary weapons if aspect seekers are equipped.

Time for a couple of AI profile flags?
(0016527)
niffiwan   
2015-03-03 04:03   
I can confirm the patch works for me as well.

Setting G_predicted_pos and G_fire_pos for AIs armed with aspect seekers sounds like a good idea.

As for the AI profile flags... I know the 1st rule is "don't change retail", and that AI changes can easily have unexpected side effects, however these are really _bugs_ in the AI behaviour, and they should be low impact. Heck, it's taken 15 years to notice that they even exist! So I'd probably prefer (slightly) to just fix them rather than add some more conditional statements and complexity. Thoughts?
(0016528)
The_E   
2015-03-03 13:10   
I agree with Niffiwan: While this is an undeniable change to the retail behaviour, it's such an edge case (and in so many ways an obvious bug) that the hassle of implementing an AIP flag, publicizing it, and getting people to use it is just not worth it.
(0016529)
MageKing17   
2015-03-03 13:27   
I've attached a patch to set G_predicted_pos and G_fire_pos in the AIF_SEEK_LOCK branch.
(0016530)
Admiral MS   
2015-03-03 17:13   
So the second patch for the AIF_SEEK_LOCK branch should be behind an AIP flag though, as it can affect gameplay much more than just fixing the bug. Additionally there is need for an extra condition since having the effect for (aip->target_time < 1.0f) is not desirable (no perfect aim right after targeting).
(0016531)
MageKing17   
2015-03-03 19:38   
Your point about (aip->target_time < 1.0f) is a good one, but it's not really any more drastic a change than the other fix; predicted_enemy_pos was still the point the AI would point towards, it just wasn't being subjected to the orientation-fudging code due to an oversight. Given that the only case in which it actually matters is when facing a stationary target, can anyone think of any examples where mission balance relies on the AI sometimes (and only sometimes) completely missing a stationary target because it wasn't pointed at exactly the right angle?
(0016555)
Spoon   
2015-03-14 17:50   
While I personally don't think a flag for this is necessary, I don't really mind if there is one. Anyway, I'd love to include this fix for WoD's release and have sometime to play around with it.
So would it be possible for this to get code reviewed/commited soonish?
(0016565)
MageKing17   
2015-03-17 16:47   
Fix committed to trunk@11284.
(0016568)
Goober5000   
2015-03-18 00:28   
(Last edited: 2015-03-18 00:29)
"As for the AI profile flags... I know the 1st rule is "don't change retail", and that AI changes can easily have unexpected side effects, however these are really _bugs_ in the AI behaviour, and they should be low impact. Heck, it's taken 15 years to notice that they even exist! So I'd probably prefer (slightly) to just fix them rather than add some more conditional statements and complexity. Thoughts?"


That's approaching things from the wrong perspective. The effects of a bug may not be all that noticeable, but the effects of a *fixed* bug may be very noticeable indeed. Take the example of Trebuchets: it took a long time for people to notice that enemy AI didn't fire bomber+ missiles. But when that was fixed, it made several FS2 missions utterly impossible (particularly Dunkerque) because Shivan wings started using Trebuchets that they had previously carried around as dead weight.

Please note that there are many instances of bugfixes like these scattered throughout the FSO codebase. They're quite clearly marked as bugs and yet they're still controlled by flags.


"can anyone think of any examples where mission balance relies on the AI sometimes (and only sometimes) completely missing a stationary target because it wasn't pointed at exactly the right angle?"


Destroying a cargo depot. A mission designer may assume that AI wings may take a certain amount of time to destroy all the stationary cargo. Rather than taking X time plus a random factor, it now only takes X. Another example is Sneak's attack on the Karnak reactor in ST:R.

The point is that changes in the AI code, even bugfixes, can have unpredictable effects. Some time ago, I went though the AI code and made all non-retail behavior (including bugfixes) controlled by flags. We should take care to maintain this state of affairs and not let the code drift into unpredictable territory. So yes, these fixes should be tied to AI flags.





View Issue Details
3142 [FSSCP] scripting minor always 2015-02-16 16:40 2015-02-16 16:40
Axem  
 
normal  
new 3.7.2 RC5  
open  
none    
none  
   
$On Weapon Fired Issues
There are some odd behaviors with On Weapon Fired,

1: If you have a weapon with swarm, like the Hornet or Tornado, fire it and as its firing, switch to a bank that has a Weapon class On Weapon Fired hook, the On Weapon Fired hook will trigger, even though the weapon never actually fires.

2: If you have 1 missile left that has a On Weapon Fired hook and you fire it, the hook will not trigger.

3: And while having an actual hv.Weapon hook would make sense and be nice, that's a whole another can of worms that sounds like a real tricky thing to make work while preserving backwards compatibility.
 
There are no notes attached to this issue.




View Issue Details
3129 [FSSCP] graphics minor always 2014-11-14 22:51 2015-01-25 19:24
Darth Geek  
 
normal  
new 3.7.2 RC4  
open  
none    
none  
   
Lod 2+ rendered shiny even if shinemap is black
When a model has more than 2 LODs and a completely black shinemap, LOD 2 and above are rendered with bright specular regardless of the black shinemap: see attached screenshot.

I also notice the normalmap is gone, which makes sense for rendering LOD 2+, but the addition of a bright shinemap renders the model incorrectly if it needs little to no specular, for instance if it is an asteroid.
I suspect the effect isn't as visible using most ships since shininess doesn't look out of place on them. To see the effect more clearly, run the mission from test mod: https://app.box.com/s/yj1adjihffhbh5yx0pf6
screenshot.png (140,904 bytes) 2014-11-14 22:51
http://scp.indiegames.us/mantis/file_download.php?file_id=2611&type=bug
png
 
Notes
(0016461)
Cyborg17   
2015-01-25 13:33   
(Last edited: 2015-01-25 13:36)
So, I don't know if anyone has looked into this one yet, but I tried tracking down the revision that causes the bug.

What I found is that the revision which last changes the behavior, 9812, has little to do with shinemaps. (I could only test 9809 and 9814, but the rest seems unrelated) This bug simply became more pronounced in this revision since that's when turning normal maps off is sure to do something (the 9812 change), and it was probably trying to turn off normal mapping for LOD 2+ before that but couldn't.

So I loaded a really old revision, 7237, fixed the mission compatibility issues and then ran the mission. It had some really goofy behavior, including having this shinemap issue for all LOD's. I'm still looking for more clues, but I thought I'd report what I've found so far in case it would help.

(0016462)
Cyborg17   
2015-01-25 14:32   
(Last edited: 2015-01-25 14:33)
Testing by replacing the shine map with one that had a red tinge instead of black.

Red tinge did not appear at LOD+2, meaning that shine maps *are* turned off at LOD+2 and that a shader is being told to add shine data once above LOD+2.

After looking at revision 7189, adding shine data to models seems to have been the default behavior since shaders were introduced.

(0016463)
Cyborg17   
2015-01-25 15:03   
I tried changing the alpha channel of the shinemap to 0 to see if that would change the behavior, but it didn't.

I'm done looking for now, but the next think I was going to look at was to try to track the revision that the Lower LOD's stopped generating shine map data. (although that's probably when shinemaps were added)
(0016464)
FUBAR-BDHR   
2015-01-25 19:24   
Only LOD 0 and 1 render shine, glow and normal maps. Any LOD above 1 just renders the base map to keep the game from slowing down. The solution is to either make lod maps or increase the distance at which lod1 is used.




View Issue Details
1604 [FSSCP] multiplayer minor always 2008-02-18 18:39 2015-01-09 10:49
Shade  
Parias  
normal  
assigned  
open  
none    
none  
   
Time to waypoint for AI ships is only displayed correctly for host
As title. Client players get no time display at all for AI ships under waypoint orders.

Replicating: Join any multi game as a client, as long as it includes waypoint orders.
ship.cpp-ai_waypoints_timer_mp_hack.patch (671 bytes) 2014-11-21 01:21
http://scp.indiegames.us/mantis/file_download.php?file_id=2612&type=bug
 
Notes
(0010155)
taylor   
2008-11-04 18:34   
This happens with time-to-dock as well. It does look like it's caused by the new docking code, since AI goals don't get evaluated the same way for multi clients. I can't really figure out exactly how the new docking code progresses so I'm not sure how to even start fixing it. I didn't verify that it actually worked in retail though, so it could be an old bug.

It's likely that the two problems are linked, though almost certainly not directly related.
(0014561)
karajorma   
2012-12-22 00:48   
Well in the case of the waypoints issue the cause is that quite simply the waypoint information doesn't exist on the client. It's a null pointer. So the

if (aip->wp_list != NULL) {

check results in no calculations being done on the client. The simplest solution might be to simply send a packet to the client telling it how much time is left whenever a goal like waypoints or docking is set.

Either way this isn't something that I can fix for 3.6.16 quickly so I'm going to unassign it.
(0016335)
Goober5000   
2014-10-09 09:59   
Parias, since you did the show-subtitle-text positioning fix for multiplayer, could you take a look at this for 3.7.2?
(0016337)
Parias   
2014-10-13 22:30   
Heh - I've been looking into this and it seems quite a bit trickier than the "shuffle a few lines of code around" changes I've done so far, but this also looks like an interesting problem to cut my teeth on.

I have a few ideas (my findings so far are consistent with karajorma's) so I'll chime in if I hit a blocker.
(0016383)
Goober5000   
2014-11-20 23:09   
Parias, any update?
(0016385)
Parias   
2014-11-21 01:21   
(Last edited: 2014-11-21 01:23)
Ack. Sorry for the long wait Goob. This was an awesome learning opportunity in that debugging it took me through the packet handling code, HUD code, AI code, and ship code in all areas... but I was so intimidated by the results that it took me forever to even figure out where to begin.

But! I DO have a working solution which turned out to be relatively simple. It's a complete and total hack, but... it works. So far. This provides a fully functional time-to-completion countdown timer for ships performing waypoints that will appear on client systems in multiplayer. It's not perfectly 100% in sync with the host player because I think ships in MP will have slightly different actual velocities, etc on client systems, but it's more or less accurate.

I've been hesitant to publish because I need to do some more testing (I haven't validated all use-cases yet and was thinking maybe I could slide in a fix for client-side docking timers too in a similar way, as a bonus) and I don't even know if what I did here is sane. But let me throw up a quick .patch of what I have now so you can see what I've got. Could I get an advisory on if my fix even makes sense, or if there's a better way I should be going about this? I mean it's a bit messy, but I can't argue with the results I've seen... so far.

Or on the off-chance this actually does make sense, I'll add some proper comments to the code (once I finish figuring out WHY it works) and fire along a final product that can be added to trunk.

(0016389)
Goober5000   
2014-11-21 18:14   
This is good thinking but it's not the correct solution. For one thing, as you said, it's a hack. The proper patch should be a fix rather than a Band-Aid.

For another, it causes an unintended side-effect. The aip pointer will now leave the function with a wp_list assigned, whereas it didn't have one upon entering the function. The wp_list may have been null for a reason, or it may not -- but in either case it will be an unexpected change to the data structure in a function that should not have changed it. The *minimal* change to the function would involve calculating the time in such a way that the wp_list was not modified (or if it was, it would be set back to null).

I'm unmarking this as a 3.7.2 bug and bumping it from trivial to minor due to the difficulty. The proper fix needs to involve hunting through the multiplayer code and finding where clients get their time updates from. Once that code is found, it should be extended for the waypoint and docking cases.

One clue as to where to start may be found in Taylor's comment. Since he said "it looks like it's caused by the new docking code", I would start by checking out a version of the code from before the new docking was added and seeing how it handles time-to-dock on the clients.
(0016446)
Parias   
2015-01-08 19:50   
One quick note - after some digging I've actually been able to reproduce this kind of problem in retail as well, so I think this is definitely a very old bug (anybody recall cases of this working properly for MP clients ever?).

Definitely working on a more elegant, less hacky fix for this in any case though - will follow up once I've got it figured out. Appreciate the critique Goob.
(0016447)
Goober5000   
2015-01-09 10:49   
Sounds good. And while I haven't confirmed it myself, it wouldn't surprise me if this has been a bug since retail.




View Issue Details
1775 [FSSCP] graphics major always 2008-09-23 12:31 2015-01-03 13:05
chief1983  
Goober5000  
normal  
assigned 3.6.11  
open  
none    
none  
   
Fix in Xt: Reminder: Include Texture replacement bugfix from Xt diff in 3.6.11
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.
More info here: http://www.hard-light.net/forums/index.php?topic=48398.msg1143016#msg1143016
 
Notes
(0009898)
chief1983   
2008-10-09 13:02   
Bumping another one that should hopefully get pulled from Xt before release if someone can get to it.
(0010221)
phreak   
2008-11-18 10: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 10: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 11:12   
(Last edited: 2008-12-14 11: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 14: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 14: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-09 22:25   
Assigning to goober since phreak hasn't been around much and he wants this one done.
(0016434)
Goober5000   
2015-01-03 13: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
3125 [FSSCP] turrets major always 2014-10-18 13:37 2014-11-05 23:18
Goober5000  
 
normal  
new 3.7.2  
open  
none    
none  
   
Difference in turret firing arcs between Hades retail model and Hades MVP model
There seems to be a discrepancy in the turret targeting code between single-part turrets and multi-part turrets. According to Yarn's testing, the MVP Hades has trouble targeting cruisers that are 45 degrees or more away from the turret normal. The turret tries to aim, but doesn't fire. The retail Hades model, which uses single-part turrets, can fire at all ships within its firing arc just fine.
Attached is the mission that Yarn created for testing the firing arc of the Hades's ventral cannon. It can be used with no mods or with the MVP mod.
HadesBeamTest.fs2 (54,650 bytes) 2014-10-18 17:24
http://scp.indiegames.us/mantis/file_download.php?file_id=2588&type=bug
HadesBeamTest-FSPort.fs2 (53,685 bytes) 2014-10-18 17:26
http://scp.indiegames.us/mantis/file_download.php?file_id=2589&type=bug
 
Notes
(0016341)
Yarn   
2014-10-18 17:41   
I updated the test mission to actually equip the Hades' cannons with beam weapons (SFReds instead of SSLBeams, which exist only in FSPort). I also added a test for the port cannon.

Regarding the ventral cannon, the behavior with the retail (non-MVP) FS2 model is a bit different: the cannon has a lot of trouble firing (but not aiming) at the far corner ships (55 and 71 degrees). I think this might have to do with the beam weapon being used, but I'm not sure. With the 2014 MediaVPs, the situation is similar, except the cannon also doesn't fire at the 45-degree ships. (I need to check retail to see whether the behavior with the retail model is the same there.)

I have also attached an FSPort version of the test mission to provide the circumstances that I originally tested with (such as the use of SSLBeam).
(0016343)
VA   
2014-10-18 22:31   
Ok I know why the port cannon wasn't firing at all targets - I originally set up the two side guns with rotational restrictions that made sense for the physical turret housing, forgetting to make them compatible with the retail. As such it had a vertical firing arc that was narrower than retail.

Here's a corrected version, which is able to shoot down all the port-cannon's targets in Yarn's test mission. It does have some slight clipping issues because of the corrected fire arc where the turret arm will sometimes intersect geometry it shouldn't, but oh well. Can't have everything. :P

http://www.mediafire.com/download/zxudynk2ku4caav/CorrectedHadesFireArcs.zip

The ventral turret is definitely not a similar problem though. That one does appear to be a code bug, cos as has been described, even the retail one refuses to fire on the ones in the corners of the grid, despite being able to aim at them.
(0016344)
Yarn   
2014-10-19 00:19   
I tested the mission in retail (and had to break it into two missions to prevent retail from crashing). The retail model's ventral cannon behaved pretty much the same there as it does in FSO. In both cases, using cheats to destroy the 71-degree targets allowed the cannon to fire at the 55-degree targets.

I also tested the port cannon. In that test, the retail model in both retail and FSO destroyed all targets. The MVP model, on the other hand, only destroyed the 0- and 25-degree targets and a few 63-degree targets, but nothing else. Fortunately, VA's corrected Hades fixes this, allowing the Hades to destroy all targets.

I still need to do further testing to find out why the retail Hades' ventral cannon can destroy all targets in the FSPort mission but not the FS2 mission.
(0016363)
Yarn   
2014-10-29 17:03   
I did some more testing. Changing to the SSLBeam from FSPort had no effect on what targets the ventral cannon fired at. Changing to the FSPort non-MVP Hades model without editing the ships table, however, did allow the cannon to destroy all targets--but only in FSO. In retail, the FSPort model behaved the same way as the standard model did (that is, it didn't attack the far-corner targets).
(0016372)
VA   
2014-11-01 19:16   
The retail Hades has a dorsal turret FOV of 160°. It seems the non-MVP FSPort Hades model has changed this to 180°, which is why it's more able to shoot things than the MVP or retail one. In fact all the multi-part turrets have been upped to 180°.

I'm...a little reluctant to follow suit though with the MVP Hades without good reason though - I would be more inclined to suggest the non-MVP FSPort version be changed to match retail. That way you'll have more consistent behaviour between them, AND closer compatibility with retail.

BTW, do you know of any difference between the Hades model in the FSU folder and the Hades in the FSPort MVPs folder? I'm not sure why it's in there twice, as it was built to be compatible with Silent Threat Reborn in the first place - So the one in the main FSU folder should work correctly with STR.
(0016376)
Yarn   
2014-11-05 23:18   
To answer your third paragraph:


"BTW, do you know of any difference between the Hades model in the FSU folder and the Hades in the FSPort MVPs folder?"

I have no idea how they're different; all I know is that they are not bit-for-bit identical.


"I'm not sure why it's in there twice, as it was built to be compatible with Silent Threat Reborn in the first place"

I'm not completely certain why the model is in the FSPort MVPs; it was added back in 2011, well before the 2014 MediaVPs were released, so I'm guessing the FSPort team wanted players to be able to enjoy it without waiting for the next MVP version.


"So the one in the main FSU folder should work correctly with STR."

Remember that the model in the current MVP release has a narrower firing arc for its port and starboard cannons than the retail model does; this is what your altered model fixes. I don't see any reason to hesitate with it.




View Issue Details
3124 [FSSCP] Platform-Engine interaction minor always 2014-10-18 12:40 2014-10-18 14:18
ngld  
Yarn Linux  
normal  
feedback 3.7.2 RC4  
open  
none    
none  
   
-keyboard_layout qwertz should remap the Y and Z keys
If I launch FSO with "-keyboard_layout qwertz", all keys are bound correctly except for the Y and Z keys. Changing the language doesn't affect this.
If the language is set to English, all key labels are according to the QWERTY layout, only the Y and Z keys are labeled according to QWERTZ. If the language is set to German, all key labels are correct (QWERTZ) but the Y and Z key labels are swapped.

I suggest remapping the Y and Z keys for consistency (then the keys' labels would be consistent, too).
If I run FSO with "-keyboard_layout qwertz" and in English, the "#" key is displayed as "\" (which is wrong) but it's bound correctly. The "Z" key is displayed correctly but bound to the wrong function in the default keyboard bindings.
if I run FSO with "-keyboard_layout qwertz" and switch to German, the "#" key is displayed as "#" (which is correct) and it's bound correctly. The "Z" key is displayed as "Y" (which is wrong) and bound to the wrong function.
The remapping should probably be done in code/io/key.cpp, FillSDLArray().
It would be nice if the key labels would depend on the keyboard layout and not the selected language. The relevant checks are in code/controlconfig/controlsconfigcommon.cpp, control_config_common_init().
mantis3124.patch (3,285 bytes) 2014-10-18 14:17
http://scp.indiegames.us/mantis/file_download.php?file_id=2587&type=bug
 
Notes
(0016340)
Yarn   
2014-10-18 14:18   
The attached patch should fix the Y and Z mappings for the QWERTZ layout. It should also fix AZERTY mappings as well as some of the French key labels.

One thing to keep in mind is that the key labels are currently based on scancodes, which are independent of the keyboard layout in use. To make the labels correct for every combination of keyboard layout and language (which, I agree, would be a good thing), the labels would have to be based on the characters that are assigned to the scancodes, which would require some restructuring in controlsconfigcommon.cpp and the use of SDL for all platforms (currently, Windows builds don't use SDL). Thus, such a fix for the labels is probably better implemented in Antipodes 9 rather than current trunk.




View Issue Details
1931 [FSSCP] user interface crash always 2009-05-29 20:22 2014-10-07 22:06
FUBAR-BDHR  
 
normal  
feedback 3.6.9  
open  
none    
none  
   
Having more then 39 ship classes in loadout casues crash
TBP now has 40 player allowed ships and one multiplayer mission was set up for all 40. No problems adding them in FRED but every time you try to select a ship in loadout you crash. 39 ships = no problem and it doesn't matter which ship I remove.

Crash is at line 1700 in missionscreencommon.cpp
3.6.10 RC2 running Ultimate Gauntlet. Bad version is in Zathras RC3. I fixed it by removing the maint bot so if you are using a newer version just allow it in FRED.
FUBAR_MG03.FS2 (98,748 bytes) 2009-06-02 23:46
http://scp.indiegames.us/mantis/file_download.php?file_id=1280&type=bug
mantis-1931.diff (437 bytes) 2009-06-03 07:38
http://scp.indiegames.us/mantis/file_download.php?file_id=1281&type=bug
 
Notes
(0010921)
karajorma   
2009-05-30 03:25   
Client or server side crash? (Or client selection causing a server side crash?).

At first glance I suspect that this is either due to the number of ship or weapon classes in TBP rather than an odd limit of 39 ships. What happens if you leave the mainbot in and take out the Starfury then put it back?
(0010922)
FUBAR-BDHR   
2009-05-30 03:34   
Host definitely. Didn't try client myself but Andicirk said clients crashed too either at loadout or mission start. Guessing they crash at mission start if they don't try to change ships.
(0010934)
karajorma   
2009-06-02 17:13   
Works fine for me with the 3.6.11 build. This could be due to something that was fixed when I edited things for team loadout.
(0010935)
FUBAR-BDHR   
2009-06-02 23:24   
(Last edited: 2009-06-03 01:00)
Still getting it. Just compiled 3.6.11 inferno. It actually gave me some debug info.

Run-time check failure 0000002 - stack around the variable 'wss_data' was corrupted.

And from the log:

ASSERTION: "offset < max_size" at missionscreencommon.cpp:1718

Actually getting it even with the 39 ship version that worked in 3.6.10 RC3

More testing 38 now seems to be the limit.

If it still works for you can you get the 3.6.11 Inferno for me to test with.

(0010936)
karajorma   
2009-06-03 06:06   
Works just fine for me. This may be due to a packet being sent from client to server (I was trying a multiplayer coop on my own to test.) I'll try with a client present later today.
(0010937)
Echelon9   
2009-06-03 07:38   
(Last edited: 2009-06-03 07:41)
Based on the debug info FUBAR provided, I'd say this crash is caused by the memcpy() at missionscreencommon.cpp:1715.

memcpy(block+offset,&player_id,sizeof(player_id));

The 'offset' is used internally in store_wss_data() to keep track of how far past the start of the 'block' passed into store_wss_data() we should be writing, but it seems there's no check done before each memcpy that 'offset' isn't already past, or will go past, the 'max_size' passed in.

While we would still have to trust that the 'max_size' passed is correct, there's at least one spot in store_wss_data() where the Assert() should go before the memory operation.

This attached patch won't solve the underlying cause - the inputs to store_wss_data() can't accommodate all the data already and about to be written to the block - but it should stop the memory corruption, with an Assert() instead.

(0010939)
karajorma   
2009-06-03 16:04   
The problem is that the Assert only solves one problem while leaving a whole load more open and waiting to bite us on the arse. And it doesn't do anything to solve the problem in release builds.

Since the offset is also increased in the loops for ships and weapons there is a chance that it could go over the packet size limit in them too. Admittedly it's unlikely to do so in ship unless we bump the number of ships allowed again but it's very likely to happen in the weapons loop. Since ships add a ubyte while weapons add a short a single extra weapon would have corrupted the mission in a different place.

One solution I can see to the problem is to break the update into two packets (Like I did with the ship update packet that used to break Inferno multiplayer). Another would simply be to bump MAX_PACKET_SIZE. Although I'm not certain what else that could break.

Either way, whatever we do here is going to break compatibility with older builds unless we simply make it error out.
(0013448)
Echelon9   
2012-04-03 09:42   
Any updates on the network packet change?
(0014588)
karajorma   
2012-12-30 02:09   
I think I'm going to add this to my proposed rewrite of the loadout code. There are just too many things wrong with it to waste time patching it now when the entire thing really needs to be rewritten without the assumptions that Volition made when they originally wrote the code.
(0016262)
niffiwan   
2014-08-26 07:16   
I think this this thread probably hit the same issue?
http://www.hard-light.net/forums/index.php?topic=88136.0

I had a look in TBP's ship tables to see if there were any other fighter-class ships that I could add to the mission FUBAR_MG3.fs2, but I couldn't see anything obvious. I'll instead have a go at reproducing it in the Aerotech TC.
(0016293)
Goober5000   
2014-09-24 02:40   
Since Karajorma wants to rewrite the loadout code, this shouldn't be targeted for 3.7.2.

Karajorma, is there any sort of error condition you can add in the meantime to have the builds fail gracefully, rather than crashing?
(0016330)
karajorma   
2014-10-07 22:06   
I can definitely look into a better solution than a crash.




View Issue Details
1947 [FSSCP] gameplay feature always 2009-07-01 01:49 2014-09-24 02:41
Goober5000  
Goober5000  
normal  
assigned  
open  
none    
none  
   
Need to make comm system consistent for other ships
It just occurred to me (and I confirmed via a test mission) that the comm system does not seem to apply to one's wingmen. You can issue them orders, they can issue praise, etc., even if they have a dead comm system. This should be fixed.
 
Notes
(0011030)
Goober5000   
2009-07-01 01:50   
Reminder sent to: karajorma
Pinging karajorma as he'll undoubtedly have something to say about this.
(0011032)
KeldorKatarn   
2009-07-01 23:27   
(Last edited: 2009-07-01 23:27)
From what i could see in the code no ship at all is effected, including capships.
Aside from weapons and engines no destroyed subsystem affect any ship but the player.

(0011033)
karajorma   
2009-07-02 13:26   
Problem is that you could have quite a big effect on gameplay changing this. Every single mission written so far has always been based on the assumption that you could order your ships around unless forbidden from doing so via FRED.

Any mission which relies on you being able to order your wingmen around could potentially break on this one. And I really don't know what to do about cases where one person in a wing has broken comms and you give orders to the entire wing. Cause having them blithely carry on doing whatever is just as wrong as having them mysteriously able to hear the order.
(0011040)
KeldorKatarn   
2009-07-03 17:55   
Exactly. I'd stay away from changing this. Making AI ships unable to communicate doesn't really help gameplay but can potentially break a mission to great frustration to the player. I'd leave this as-is. Maybe one could scramble the comm window animation if the comm system is gone, but not the sound and the text.

But I'd vote for not doing anything about this. This is Working As Designed. And changing it doesn't really improve gameplay. I doubt any player enjoys his wingmen being unable to communicate just because it is more realistic.

if the realism part bothers anyone ingame simply guardian the subsystems so they can only be damaged but not destroyed.
(0011043)
Goober5000   
2009-07-03 21:20   
Except that this isn't a gameplay breaker. The player has to cope with wingmen events that happen during the course of a mission. If one of his wingmates get disabled, the player would have to deal with it. It should be no different if one of his wingmates has his comm system disabled.

Furthermore, in both cases, the wingmate is perfectly capable of calling in support.
(0011044)
KeldorKatarn   
2009-07-03 21:34   
It is a gameplay breaker for Saga and it will probably be for many other mods. So if you do this, activate it by flag only.

otherwise we'd pretty much have to subsystem.guardian every single ship in our missions.
(0011045)
Goober5000   
2009-07-03 22:05   
It's not a game-breaker because the chance of any fighter having its comm system knocked out is approximately the same as the chance of the same fighter having its engine subsystem knocked out.

Do you subsystem-guardian every engine system for every ship in every mission in WCS?
(0011047)
karajorma   
2009-07-04 04:42   
(Last edited: 2009-07-04 04:42)
While the chance of having comms knocked out may be the same as engines, the effect knocking comms out has on the game currently is none.

The effect it would have after this change is not none. How large that would actually be remains to be seen but it is worth bearing in mind that since the game has not been balanced with this in mind there may be ships out there with comm systems that are exceedingly easy to knock out. The example of how it's easy to disable Nials in TBP comes to mind but in that case it's always been a well known thing and thus has always been part of the mission design.

In this case we'd suddenly be adding a factor that can make the game harder out of nowhere. The argument that the ship can call in support is of no use to mods and campaigns which didn't include support.

(0011048)
KeldorKatarn   
2009-07-04 10:43   
(Last edited: 2009-07-04 11:12)
"Do you subsystem-guardian every engine system for every ship in every mission in WCS? "

Yes. We do for all friendly ships! And we'd have to do this with comms for ALL ships.

Btw Goober. It is really amazing that I get along great with SCP as long as you are gone. This kind of attitude towards the mods "I don't care if it breaks you and I know better anyway" is REALLY getting on my nerves.

if I tell you it will break Saga then that's a fact and not open for opinion polls.

(0011049)
Goober5000   
2009-07-04 15:46   
Bah. Bah I say!

Okay, I'm going to add this as an ai_profiles flag.
(0011050)
KeldorKatarn   
2009-07-05 00:03   
(Last edited: 2009-07-05 00:04)
How about leaving it alone and working on bugs until someone actually asks for this and uses it?

(0011051)
karajorma   
2009-07-05 09:50   
In that case I'm asking.

While I might be worried about backwards compatibility I have no problem with this being an inclusion in missions from now on.
(0014547)
Goober5000   
2012-12-19 23:04   
Not a high priority, so deferring to 3.7.2.
(0015446)
Goober5000   
2013-11-21 00:54   
I've created a comm_between_player_and_ship() function as part of the scramble-messages enhancement. This could be used in the future to regulate communications from AI-controlled ships. It already has a hook to add a future AI profiles option.
(0016294)
Goober5000   
2014-09-24 02:41   
Feature request, not critical for 3.7.2.




View Issue Details
3066 [FSSCP] sound minor always 2014-06-19 16:24 2014-09-19 17:19
Axem  
m_m  
normal  
assigned  
open  
none    
none  
   
Triggered animation sounds don't appear to work
The $Sound: fields don't appear to be working correctly for triggered animations. See below for a test mod. Happens even if the sound references are retail indexes.
http://www.mediafire.com/download/oy65aa918ibnndw/CainTest10.rar

Play test mod, Press 1 to make the Cain move its arms and fire. Sounds should play when its arms begin and finish moving.
 
Notes
(0015897)
m_m   
2014-06-20 05:07   
This is weird, apparently playing sounds was never actually implemented and I have no idea where to actually implement it as the animation code is terribly complicated.
(0016286)
MageKing17   
2014-09-19 17:19   
I was taking another look at this today, and I thought I'd write down my findings so somebody else doesn't have to re-...research the wheel.

When animation.cpp was moved to modelanim.cpp, the following (commented out) lines were present in triggered_rotation::start():

vec3d sp;
vm_vec_rotate(&sp,&snd_pnt,&Objects[obj_num].orient);
vm_vec_add2(&sp, &Objects[obj_num].pos);
if(q->start_sound != -1)current_snd = snd_play_3d(&Snds[q->start_sound], &sp, &View_position, q->snd_rad) ;

(r3045, lines 207-210 if you want to look at the original.)
This code can't be used as the basis of a proper implementation of animation sounds for two reasons: one, snd_pnt does not exist. Two, obj_num is never set to anything but a default value of -1 (making one wonder why it's present at all).

Assuming someone can figure out the problem of figuring out the worldspace coordinates the sound should be coming from, the next hurdle is figuring out when the sounds should play. triggered_rotation::start() is a good place to fire off start_sound and begin playing loop_sound, and model_anim_submodel_trigger_rotate() would be a good place to update the position of loop_sound. It's also where animations appear to end (lines 499-502), although it doesn't seem like that is sufficient in and of itself... then again, it may be due to the counter-intuitive way in which triggered_rotation objects get reused. It's also worth noting that "instant" animations skip triggered_rotation::start(), so playing start_sound should also probably happen around lines 584-589.

Personally, I think triggered_rotation needs a couple of extra methods (like, say, ::end() and perhaps ::update()); triggered_rotation::end() could incorporate lines 500-501 as well as playing end_sound and stopping loop_sound, while triggered_rotation::update() could be limited to updating the 3D position of the loop_sound, or perhaps take the bulk of of the triggered_rotation-based logic in model_anim_submodel_trigger_rotate().

In hindsight, modelanim.cpp probably needs significant refactoring to fix this issue properly.




View Issue Details
1951 [FSSCP] multiplayer crash random 2009-07-05 16:30 2014-09-10 22:50
FUBAR-BDHR  
Echelon9  
high  
feedback 3.6.11  
reopened  
none    
none  
   
Standalone crashes - Ship <ship>does not have subsystem <subsystem> linked into the model file
Been getting a bunch of new standalone crashes in the last couple of weeks. Looks like it's 2 different ones but they may be connected since they both crash at the same line sometimes. First one is a bunch of assertions that always seem to start when a Lilith model is loaded. This usually leads to the second one which is a crash but this crash also happens on it's own. Attaching logs
1951.rar (46,094 bytes) 2009-07-05 16:32
http://scp.indiegames.us/mantis/file_download.php?file_id=1296&type=bug
fs2_open_vp_1733.log (190,919 bytes) 2009-07-08 16:02
http://scp.indiegames.us/mantis/file_download.php?file_id=1298&type=bug
fs2_open_both.rar (6,320 bytes) 2009-07-09 00:57
http://scp.indiegames.us/mantis/file_download.php?file_id=1299&type=bug
fs2_open-07-11-09.log (184,591 bytes) 2009-07-11 19:59
http://scp.indiegames.us/mantis/file_download.php?file_id=1300&type=bug
fs2_open-07-18-09.log (88,164 bytes) 2009-07-19 03:20
http://scp.indiegames.us/mantis/file_download.php?file_id=1302&type=bug
players1.jpg (168,365 bytes) 2009-08-15 17:51
http://scp.indiegames.us/mantis/file_download.php?file_id=1313&type=bug
jpg

players2.jpg (184,912 bytes) 2009-08-15 17:52
http://scp.indiegames.us/mantis/file_download.php?file_id=1314&type=bug
jpg

lilith.txt (8,979 bytes) 2009-08-25 18:50
http://scp.indiegames.us/mantis/file_download.php?file_id=1322&type=bug
1951.txt (25,778 bytes) 2010-07-08 15:50
http://scp.indiegames.us/mantis/file_download.php?file_id=1534&type=bug
1951_logs.rar (27,379 bytes) 2010-07-09 18:47
http://scp.indiegames.us/mantis/file_download.php?file_id=1535&type=bug
1951_3_6_15.rar (83,714 bytes) 2012-12-01 22:56
http://scp.indiegames.us/mantis/file_download.php?file_id=1999&type=bug
1951_3_6_15_2.rar (97,436 bytes) 2012-12-13 12:29
http://scp.indiegames.us/mantis/file_download.php?file_id=2044&type=bug
fubar_m18.fs2 (22,340 bytes) 2012-12-19 23:40
http://scp.indiegames.us/mantis/file_download.php?file_id=2073&type=bug
1951_3_6_19.rar (96,842 bytes) 2013-03-28 22:57
http://scp.indiegames.us/mantis/file_download.php?file_id=2144&type=bug
 
Notes
(0011053)
FUBAR-BDHR   
2009-07-05 16:33   
Just a note that this was with retail FS2 data running on the standalone.
(0011062)
FUBAR-BDHR   
2009-07-08 16:03   
Attached additional log. First time seen on the MediaVP standalone. Slightly different set of problems but crashed at the same spot.
(0011063)
FUBAR-BDHR   
2009-07-09 00:15   
OK this has officially become an epidemic. Attached another log. This one shows something that I don't know if the others do or not. The Lilith model loads fine at least one time before it goes nuts and starts with the assertions on another load.
(0011075)
FUBAR-BDHR   
2009-07-11 19:58   
No crashes in today's session using the RC3 no warnings build. Quite a few asserts but they are all the same. This was with the MediaVP. Attaching log just in case.
(0011083)
portej05   
2009-07-14 04:22   
Really need the callstack for this one.
The culprit is vm_project_point_onto_plane, which is only called from 3 places, but tracing through is going to be very hard without knowing which one is being called.
(0011091)
FUBAR-BDHR   
2009-07-19 03:22   
(Last edited: 2009-07-19 03:25)
Well it seems the big problems are well patched. Standalone did crash once in yesterdays games. I've seen the same crash before. Log attached. I asked them if someone dropped before the game started and was told that someone was lost in mission load. Same mission was played after restart with no crash.

(0011092)
portej05   
2009-07-19 03:31   
I'd still like to see a callstack from when this occurs since it implies that a vector being passed to vm_project_point_onto_plane hasn't been normalised, which is really bad.
Are there any instructions for getting this to occur?
(0011094)
FUBAR-BDHR   
2009-07-19 03:46   
Didn't seen any nul vec3d errors today just the the one crash.
(0011105)
FUBAR-BDHR   
2009-07-25 18:19   
Still no luck on getting a debug trace. It's up for testing but since today was the normal Saturday games they were using 3.6.10. Did get another one of those dropped player crashes. Had the debug_filter turned on. I'd attach the file but it's 75meg and even zipped still over a meg. You can grab it here: http://fubar5.fubar.org/mantis/fs2_open-07-25-09_MVP_1733.rar
(0011106)
portej05   
2009-07-26 22:08   
FUBAR: With this one, it might be worth the inconvenience of dropping some players in order to get a callstack - Asserts should never be ignored (who stuck Cmdline_nowarn into Assert?)
(0011108)
FUBAR-BDHR   
2009-07-27 00:32   
Already planned and the server to do that is up and running. Just waiting on our main tester to get unsick and give it a go. I didn't want to use the main Saturday games since you never know what version they are running, if they are using the MediaVPs or not, if they have any rogue tables, etc. That and there aren't that many multi players now. Hate turning new players off because of testing crashes.
(0011126)
FUBAR-BDHR   
2009-08-06 20:17   
Well we got to hits with the debugger yesterday. One as a client but it was a null vec3d so it's possibly related. The other was on the standalone and involved the player drop problem (still have the debugger open on this one). The think is it doesn't look like it was actually a player drop. I just happened to check on the standalone at the right time to actually see it happen. 6 IP addresses where showing as connected on the standalone but I could only see 3 players in the status window. Right after that it crashed. I asked and there were 6 or 7 people in the game. Looking at the multi.log earlier today I noticed that there was a FS2NetD refresh right about the time of the crash. This makes me wonder if it is that refresh that is causing the issue. It does cause problems for normal hosting such as the awarding of all medals in debrief bug.
(0011127)
FUBAR-BDHR   
2009-08-06 22:32   
OK I just saw this about to happen again. 3 players on server and even chatting but none showing in the player info pull down. Checked the debug log on the stnadalone and it had just done a FS2netD refresh. I hit reset all before it crashed and when the joined again the player info screen was fine. Definitely something going on here even if it's not related to the crash.
(0011136)
FUBAR-BDHR   
2009-08-15 17:55   
(Last edited: 2009-08-15 17:57)
Attached 2 screen shots of what appears to be the cause of the crash. You'll notice 7 IP connections showing but only 4 players. Seems that when one of those "ghost" players goes to start a mission or respawn it crashes.

Almost positive this is related to 1827

(0011159)
FUBAR-BDHR   
2009-08-25 18:50   
(Last edited: 2009-08-25 18:52)
While most of the stuff relating to this seems to be fixed or known I did get the Lilith problem again last night. We were discussing it last night but Wanderer had to leave and I felt the sudden need to get horizontal so we didn't make much progress. Took a second look at it today and it seems (big guess here)it's looking for an already cached subsystem at the wrong location. sip->subsystems[j].model_num is 515 and sip->model_num is 8583.

I'll attach the call stack and variables. I still have the debugger open so I can't get the fs2_open.log right now. Mission was cet_m03 which only has one Lilith. I'll be checking the SCP IRC channel periodically tonight so if you need more info and I'm logged in there just ask.

(0011856)
chief1983   
2010-04-05 12:55   
Changing the subject because this title could get confusing very soon.
(0011857)
FUBAR-BDHR   
2010-04-05 18:32   
Maybe we should change it to the actual error that is left.

Anyway think I had this happen again last night. Saw the server was crashed with a similar error but didn't have time to check it yet.
(0011858)
chief1983   
2010-04-05 19:03   
That or open a new bug that's not cluttered and close this one as fixed. If an issue was fixed this should probably be closed, it was never really supposed to be a parent type ticket.
(0012205)
FUBAR-BDHR   
2010-07-08 15:50   
Apparently not fixed. Just found a standalone crashed with it. Retail data. r6278.
(0012209)
FUBAR-BDHR   
2010-07-09 18:51   
Changed the topic to the error and uploaded the logs from yesterday's crash.
(0012214)
Echelon9   
2010-07-10 08:03   
This latest example looks to be a Debug build correctly catching a model problem with a Warning() call. Please open a new case for this, but I'd say it is a model bug (although if with Retail data we will have to look into it).
(0012224)
FUBAR-BDHR   
2010-07-10 15:54   
Nope not a model bug. This happens on a reload of a model that is already loaded although it's usually the Lilith for some reason. Somewhere one of the indexes is getting changed or stepped on in memory.
(0014021)
Goober5000   
2012-11-11 00:19   
Is this bug still a problem?
(0014026)
FUBAR-BDHR   
2012-11-11 11:23   
I have no clue at this point. The standalones were crashing so often with multiple issues I haven't tried to run one in over a year.
(0014029)
Goober5000   
2012-11-11 13:07   
The model code has been changed a lot in the past two years and the cause of this bug may have been fixed. It would help to run a standalone to be sure.
(0014159)
karajorma   
2012-11-23 02:08   
Has this one resurfaced?
(0014161)
FUBAR-BDHR   
2012-11-23 12:17   
With all the new warnings and FS2netD server going down they haven't been up long enough to really test.
(0014245)
FUBAR-BDHR   
2012-12-01 21:35   
Unfortunately it still lives. Just got it with retail data loading the Gany.

I'll pack up the logs and attach them as soon as I get out of the debugger.
(0014250)
Goober5000   
2012-12-02 00:13   
Is that the complete log? Because it doesn't display the expected -mod information at the beginning. Can you post the command line you used?
(0014251)
FUBAR-BDHR   
2012-12-02 00:38   
Standalone logs don't include that info for some reason.

Here it is. No mod was active. Retail data used.

C:\Games\FreeSpace2\fs2_open_3_6_15d_INF_SSE2.exe -nomotiondebris -missile_lighting -3dshockwave -post_process -3dwarp -warp_flash -snd_preload -standalone -fps -spec -glow -env
(0014434)
FUBAR-BDHR   
2012-12-13 12:29   
Another one this time with the Lilith again.
(0014548)
Goober5000   
2012-12-19 23:23   
Can you attach the mission that was loaded?
(0014550)
FUBAR-BDHR   
2012-12-19 23:41   
Sure but it's not specific to that mission.
(0014552)
Goober5000   
2012-12-20 02:02   
I've added some additional debug code. Please post the new warning message if it occurs again.
(0014614)
Goober5000   
2013-01-04 10:07   
Has anyone tested the debug code I added? Does this problem still occur?
(0014615)
FUBAR-BDHR   
2013-01-04 13:52   
I've had the debug code up since it was added. Unfortunately I've only seen a few uses of the standalones in the last couple of weeks and most of the time it has been 1 player just sitting there waiting for other players not actually playing. Hoping things will pick back up a bit once people get tired of their xmas presents and go back to playing FS2.
(0014761)
FUBAR-BDHR   
2013-03-10 04:42   
I have not seen an occurrence of this in months. Last one I had I believe was shortly before commits 9423 and 9424. Possible plugging those memory leaks fixed this issue?
(0014762)
Goober5000   
2013-03-10 15:23   
That's terrific news. I'm going to assume revision 9423 fixed this, as it's highly plausible that it's related.
(0014850)
FUBAR-BDHR   
2013-03-28 22:57   
Unfortunately this has occurred again. With the changes it hit an assert in model_get(). Attaching new log, stack, and variables.
(0015471)
Echelon9   
2013-11-30 20:21   
Can we get clear steps for which mission will most typically trigger this bug?

I would really like to see an AddressSanitizer-enabled standalone server report this bug, as we will get a precise measure of any memory corruption going on.
(0016271)
Goober5000   
2014-09-06 23:59   
Bump because we need steps to reproduce this.
(0016273)
Echelon9   
2014-09-10 10:08   
I'll try to reproduce, but any other assistance reproducing appreciated.
(0016274)
Goober5000   
2014-09-10 22:50   
Yeah, that comment was directed mainly at FUBAR.




View Issue Details
1607 [FSSCP] multiplayer minor always 2008-02-23 00:06 2014-08-30 01:07
Shade  
 
normal  
new  
open  
none    
none  
   
Rotating subsystems do not rotate for clients
Host sees them rotate just fine, but clients do not. However, clients can still get killed by a rotating subsystem hitting them and never know what happened - Seen this more than a few times in the 'Into the Lions Den' MP conversion when people stray near the comm nodes.

Replicating: Play Into the Lions Den (m-itld.fs2, it's in the mission pack) as a client and fly near a comm node to see it. Not too near though...
 
Notes
(0011209)
Zacam   
2009-10-05 01:22   
Just a note to add, still alive and kicking, this bug is.
(0016228)
Echelon9   
2014-08-17 00:40   
Is this still confirmed as a bug with current code?
(0016265)
karajorma   
2014-08-30 01:07   
I'm pretty sure it still exists.




View Issue Details
3100 [FSSCP] HUD tweak always 2014-08-22 23:33 2014-08-25 16:38
niffiwan  
 
normal  
new 3.7.2 RC3  
open  
none    
none  
   
Newly created hcf files are ignored until FSO is restarted
I found this while testing 0003099. If you save a new hcf file, it is ignored until FSO is restarted. i.e. when using the left/right arrows to change between the existing hcf files, the hud config screen does not change when the new file is selected.
Start FSO
Enter HUD config screen
Change one gauge (e.g. throttle) to be a different color
Save the config with any name
Use the left or right arrow to cycle through all the available hcf's
Note that the new file is part of the cycle, but its contents are ignored
Leave the hud config screen via the accept button
Re-enter, cycle the hcf's and notice that the new one still isn't used
Exit FSO and restart
Now the new HCF will work correctly
 
Notes
(0016255)
m_m   
2014-08-25 05:58   
The cause of this behavior is within the CFile system. FSO only fills the file lists at startup and when a file is created or deleted the CFile system will not adjust the file lists accordingly.
(0016257)
niffiwan   
2014-08-25 16:38   
OK, that makes sense. Now I wonder if there's a function to "add/append" a new file to the filelists... :)




View Issue Details
2661 [FSSCP] user interface minor always 2012-06-02 14:50 2014-08-18 16:19
z64555 Acer Aspire 3680  
Microsoft Windows  
low XP SP3  
new 3.6.13  
open  
none    
none  
   
Bank axis does not work with Rx, Ry, Rz
When mapped to the Rx, Ry, or Rz axis, the Bank control does not function (i.e. any position of the joystick will not roll the craft).
Note: You must have a controller that has an Rx, Ry, or Rz axis to begin with, or have controller drivers/software that can reconfigure it's axiis.

1. Configure your controller to have one or all of the R axiis
2. Run FSO
3. Open Options, and map the R axis you just configured your controller to have
4. Close Options, and Open the Tech Room
5. Select a mission from the Mission Simulator and run it (I suggest one of the training missions)
6. Try to bank in mission
Additional Platform Specs:
 Intel Celeron M (1.86 GHz)
 2GB RAM
 Mobile Intel 945(OpenGL 1.4)

 
Notes
(0013625)
z64555   
2012-06-02 17:00   
Probably a derp:

3.6.14 RC6 has the same issue
(0013628)
iss_mneur   
2012-06-02 19:41   
Based on the code in joy_get_pos (joy.cpp:940) it appears only 4 axis are actually used at any one time by FSO even if 6 are supported.
(0013630)
z64555   
2012-06-03 00:11   
It also doesn't matter if it's a DirectInput device or not, (joy.cpp::1246).

So, I guess it's safe to say that joy.cpp has potential for updates. :)
(0016238)
emkay   
2014-08-18 16:19   
I know, it's an old one, but is this still an issue? I tried it with my Joypad and it works perfectly (at least when using the Rx axis).




View Issue Details
2894 [FSSCP] Build system minor N/A 2013-06-29 08:36 2014-07-23 22:57
Firewave  
chief1983  
normal  
feedback 3.7.0 RC2  
open  
none    
none  
   
Compiler warning fixes for clang
I got the 3.7.0 RC2 source code and compiled it with clang 3.3 on ubuntu 13.04. Most of the warnings are fixed by the attached patch.

Some notes:
- the void casting is done to get rid of "set, but not read" warning about variables, that are only being used in conditional code like Assert() or mprintf(), that is not being called in an NDEBUG build
- code/graphics/2d.cpp <-- there's a bug, that it didn't use the actual mode, that could be changed by the parameters
- code/hud/hud.{cpp|h} <--- that was missing the virtual destructor in the base object, which can cause problems with polymorphic objects
- code/ai/aibig.cpp <-- it might be possible, that code where I disabled the priority1 and priority2 variables can be removed alltogether

I will add an additional report for the remaining warnings.
scp_clang_fixes.diff (55,416 bytes) 2013-06-29 08:36
http://scp.indiegames.us/mantis/file_download.php?file_id=2231&type=bug
 
Notes
(0015147)
chief1983   
2013-06-29 09:09   
Awesome, thanks for going through that!
(0015148)
z64555   
2013-06-29 10:18   
Modifications to controlsconfig.cpp in this patch look good to go.

I'm unsure about the deliberate use of void-casting to ignore the "set, but not read" warnings. Since it seems most of the variables that you have applied the void cast to are used solely, I would suggest maybe using #ifndef NDEBUG {} #else {} directives. This might be more cluttered, however.
(0015872)
Echelon9   
2014-06-14 19:05   
Can we have a redone set of Clang warnings against the latest RC source code?

There's been significant changes to the source code in the last year, so I'm not sure how much these old reports are still valid.
(0015931)
chief1983   
2014-06-27 10:19   
I wonder if the user who submitted it is even checking up on this still. Would be nice to see though. I don't have a Linux-Clang box unfortunately though, so I can't really reproduce these warnings myself. Closest I can get is Apple's Clang or FreeBSD 10's. That latter might be a good one to start with though.
(0015933)
oldlaptop   
2014-06-29 15:48   
(Last edited: 2014-06-29 15:53)
Build logs as of r10840 from clang 3.4.1 (Debian clang version 3.4.1-4 (tags/RELEASE_34/dot1-final) (based on LLVM 3.4.1)) on Debian testing amd64:

Default CFLAGS/CXXFLAGS:
http://plantmonster.servebeer.com/~oldlaptop/fso/clang-3.4.1.release.log

-Weverything (should be every warning clang knows how to emit) and C/C++ standards set to C99/C++03. This is probably uselessly long at 12MB(!), but posting for completeness.
http://plantmonster.servebeer.com/~oldlaptop/fso/clang-3.4.1.release.weverything-c99-c++03.log

I'm perfectly willing and able to make more builds with different CFLAGS/CXXFLAGS if anyone wants.

(0015965)
chief1983   
2014-06-30 10:12   
So I guess we need to try to apply this patch and see how many it cleans up, if any of the hunks still apply?
(0015967)
Echelon9   
2014-06-30 10:38   
Actually, I think it may be easier to review the logs oldlaptop has provided directly. For instance, I just committed a number of the more straight forward ones in 10860.

Can I suggest to oldlaptop that you prepare the clang logs with a debug configuration. There are sections of debug only code, which for instance may mean an otherwise unused variable is used.

I'm not aware of any release only code.
(0015968)
Echelon9   
2014-06-30 11:25   
oldlaptop should run the clang warning log again with debug config and r10862. Should be plenty less warnings.
(0015975)
oldlaptop   
2014-06-30 17:00   
Same build options (but with --enable-debug) as of r10862:

(defaults - this is almost 150K smaller) http://plantmonster.servebeer.com/~oldlaptop/fso/r10862.clang-3.4.1.debug.log


(-Weverything, C99, C++03 - still absurdly large) http://plantmonster.servebeer.com/~oldlaptop/fso/r10862.clang-3.4.1.debug-Weverything-c99-c++03.log
(0015980)
Echelon9   
2014-06-30 20:16   
(Last edited: 2014-07-01 10:13)
Thanks oldlaptop for re-running. I think I can get that list down even further reasonably quickly. Give me a few days.

Update: Looks like oldlaptop's server is done for now.

(0016008)
ngld   
2014-07-01 16:38   
(Last edited: 2014-07-02 12:42)
I guess it's no-ip.com or Microsoft causing the problem rather than oldlaptop's server: https://www.noip.com/blog/2014/06/30/ips-formal-statement-microsoft-takedown/

Edit: oldlaptop created a new domain:
http://plantmonster.ddns.net/~oldlaptop/fso/r10862.clang-3.4.1.debug.log
http://plantmonster.ddns.net/~oldlaptop/fso/r10862.clang-3.4.1.debug-Weverything-c99-c++03.log

(0016009)
oldlaptop   
2014-07-01 17:25   
(Last edited: 2014-07-02 15:20)
plantmonster.ddns.net should also work now, or as soon as the DNS records get propagated.

[EDIT] as should plantmonster.net

(0016026)
Echelon9   
2014-07-05 11:48   
Okay, I've address a great many more of the clang warnings with revision 10885.

Would be interested in seeing what is left. Am aware of the "missing field 'type' initializer" ones.
(0016038)
oldlaptop   
2014-07-07 16:13   
(Last edited: 2014-07-07 16:13)
Down to 56K with default flags now:

http://plantmonster.net/~oldlaptop/fso/r10887.clang-3.4.1.debug.log
http://plantmonster.net/~oldlaptop/fso/r10887.clang-3.4.1.debug-Weverything-c99-c++03.log

(0016042)
Echelon9   
2014-07-09 06:03   
A number of the Weverything warnings have now been addressed as of r10904.
(0016077)
oldlaptop   
2014-07-16 16:55   
Sorry about the delay. Logs as of r10918:

http://plantmonster.net/~oldlaptop/fso/r10918.clang-3.4.1.debug.log
http://plantmonster.net/~oldlaptop/fso/r10918.clang-3.4.1.debug-Weverything-c99-c++03.log
(0016086)
niffiwan   
2014-07-17 19:26   
Added another patch from MageKing17 that clears up some more issues, compiles OK with gcc 4.4.7 & 4.8.0, I'll commit this tonight.
(0016088)
MageKing17   
2014-07-17 20:28   
It was already committed in r10921.
(0016123)
oldlaptop   
2014-07-23 22:57   
Logs as of r10963:

http://plantmonster.net/~oldlaptop/fso/r10934.clang-3.4.1.debug.log
http://plantmonster.net/~oldlaptop/fso/r10934.clang-3.4.1.debug-Weverything-c99-c++03.log




View Issue Details
2873 [FSSCP] FRED graphics minor sometimes 2013-05-15 22:17 2014-07-03 11:28
FUBAR-BDHR  
The_E  
normal  
acknowledged 3.6.19  
open  
none    
none  
   
Texture replacement crashing FRED when set to files that were added after FRED was opened
I've got this crash a number of times now but can't figure out a way to reliably reproduce it. It is always caused by the same thing but doesn't always happen. If you have FRED open and copy a new texture into the maps directory it can cause FRED to crash. This can happen while saving or loading a mission using the newly added texture.
Again it's random but the following has caused it:

Open FRED, place a model to be texture replaced in FRED. Save mission. Copy new texture to the data\maps folder. Go into texture replacement and assign the texture you just copied to the ship. Save the mission. It may or may not crash.

Another version is to have FRED open, copy a map into data\maps, then load a mission that uses that map. Of course this one involves changing/fixing the texture replacement in notepad which is still the only way to do texture replacement on some ships.
Stack:

     fred2_open_3_6_19_SSE2-DEBUG.exe!debug_int3(char * file, int line) Line 768 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!WinAssert(char * text, char * filename, int linenum) Line 966 + 0x13 bytes C++
> fred2_open_3_6_19_SSE2-DEBUG.exe!bm_unlock(int handle) Line 1786 + 0x2c bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!bm_lock(int handle, unsigned char bpp, unsigned char flags, bool nodebug) Line 1728 + 0x9 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!opengl_create_texture(int bitmap_handle, int bitmap_type, tcache_slot_opengl * tslot) Line 933 + 0x15 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle, int bitmap_type, float * u_scale, float * v_scale, int tex_unit) Line 1055 + 0x11 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle, int bitmap_type, float * u_scale, float * v_scale, int stage) Line 1110 + 0x19 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!opengl_render_pipeline_program(int start, const vertex_buffer * bufferp, const buffer_data * datap, int flags) Line 722 + 0x1c bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!gr_opengl_render_buffer(int start, const vertex_buffer * bufferp, int texi, int flags) Line 1273 + 0x15 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!gr_render_buffer(int start, const vertex_buffer * bufferp, int texi, int flags) Line 755 + 0x18 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!model_render_buffers(polymodel * pm, int mn, bool is_child) Line 4730 + 0x1e bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!model_render_children_buffers(polymodel * pm, int mn, int detail_level) Line 4493 + 0xf bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!model_really_render(int model_num, matrix * orient, vec3d * pos, unsigned int flags, int objnum) Line 2977 + 0x13 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!model_render(int model_num, matrix * orient, vec3d * pos, unsigned int flags, int objnum, int lighting_skip, int * replacement_textures) Line 2023 + 0x19 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!render_one_model_htl(object * objp) Line 913 + 0x47 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!obj_render_all(void (object *)* render_function, bool * draw_viewer_last) Line 281 + 0x9 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!render_models() Line 672 + 0xe bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!render_frame() Line 1520 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CFREDApp::OnIdle(long lCount) Line 526 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWinThread::Run() Line 621 + 0x17 bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!CWinApp::Run() Line 832 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 47 + 0xd bytes C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26 C++
     fred2_open_3_6_19_SSE2-DEBUG.exe!__tmainCRTStartup() Line 275 + 0x2c bytes C
     fred2_open_3_6_19_SSE2-DEBUG.exe!WinMainCRTStartup() Line 189 C
     kernel32.dll!750b33aa()
     [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
     ntdll.dll!77539ef2()
     ntdll.dll!77539ec5()
     fred2_open_3_6_19_SSE2-DEBUG.exe!send_ship_kill_packet(object * objp, object * other_objp, float percent_killed, int self_destruct) Line 2525 + 0x41 bytes C++

Autos from BM_Unlock()


        bitmapnum 618 int
+ bm_bitmaps 0x01ecd138 struct bitmap_entry * bm_bitmaps {filename=0x01ecd138 "cursorweb.ani" signature=9410 palette_checksum=0 ...} bitmap_entry [4750]
+ bm_bitmaps[bitmapnum] {filename=0x01ee5378 "EAC_Freighter_02_Grn.dds" signature=12226 palette_checksum=0 ...} bitmap_entry
+ bm_bitmaps[bitmapnum].filename 0x01ee5378 "EAC_Freighter_02_Grn.dds" char [32]
        bm_bitmaps[bitmapnum].handle 3444368 int
        handle 618 int
 
Notes
(0015949)
Goober5000   
2014-06-29 23:13   
The E, was this the issue that was fixed in r10717?
(0015959)
The_E   
2014-06-30 02:08   
No, this is a separate, likely unrelated issue. The fix in 10717 was an edge case that resulted in an invalid operation on a vector; this looks to me like a general limitation of the virtual filesystem FS uses.




View Issue Details
1982 [FSSCP] gameplay feature always 2009-08-22 20:08 2014-06-30 11:47
FUBAR-BDHR  
Sushi_CW  
normal  
assigned 3.6.11  
reopened  
none    
none 3.6.11  
   
Ships with no afterburners call afterburner_start and afterburner_stop
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.
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".
0001982 .patch (3,489 bytes) 2009-11-10 17:57
http://scp.indiegames.us/mantis/file_download.php?file_id=1342&type=bug
 
Notes
(0011160)
karajorma   
2009-08-26 01: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 03: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-27 20: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 18: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 19: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 08:04   
(Last edited: 2009-11-09 08: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 17:57   
Patch uploaded. Waiting for approval.
(0011277)
karajorma   
2009-11-14 04:51   
Looks fine to me. Committed.
(0011282)
Sushi_CW   
2009-11-14 10: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 04: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 10: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 17: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 18: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-17 21: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 16: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-29 23:21   
Is the issue in fact resolved? If it is, we should resolve the ticket.
(0015962)
Admiral MS   
2014-06-30 06:03   
(Last edited: 2014-06-30 11: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
2032 [FSSCP] Build system feature N/A 2009-11-10 11:38 2014-06-30 10:06
chief1983  
chief1983  
low  
assigned  
open  
none    
none  
   
Build request system
Take concepts from the nightly build scripts to expand this into a way for users to request a custom build configuration via an automated system.
Something like a cron job that runs on the build systems, and frequently checks for a new build request. The configuration in the request is built, then uploaded, then the request is modified as completed and a link made available to user who requested it. Not sure how this is going to work exactly, but hopefully builds will only take 30-45 minutes, or less if we get good hardware/hosting for the build machines.
 
Notes
(0015956)
Goober5000   
2014-06-29 23:26   
Bump for feedback. Is this going to be worked on or can we close it?
(0015963)
ngld   
2014-06-30 09:56   
I've got a buildbot for FSO. You can already request builds (https://build.tproxy.de/builders/fs2-trunk-linux and https://build.tproxy.de/builders/fs2-trunk-windows) but the only option you can change is the SVN revision. I could extend this if needed.

Builds for linux usually take less than 5 minutes and around 15 minutes (7 minutes compiling, 7 minutes upload) for windows.

To download a build you have to click on the build number, then look for the "upload" step in "Steps and Logfiles". There should be a link to either trunk-...-linux.tar.gz or trunk-...-windows.7z.
(0015964)
chief1983   
2014-06-30 10:06   
Nifty. I also have been working on this, slowly, the upgrades to my build system that allow release building also have helped it move in a direction to have more control over what is built. It's moving.




View Issue Details
2867 [FSSCP] FRED minor always 2013-05-09 02:12 2014-06-29 23:15
FUBAR-BDHR  
Goober5000  
low  
assigned 3.6.19  
open  
none    
none  
   
Save in retail format isn't removing some newer features
Wanted to save a mission in retail format for some previous version testing. Ran 3.6.9 and got crashes on the fog multiplier stuff and +use table score.

Probably opening up a can of worms on this one.
Open FRED. Save whatever is there all you need is the default ship. Do a file-new just to be on the safe side. Open the mission back up. Set save type to retail format. Save the mission. Open in notepad and you will see the fog multiplier stuff still there and the +use table score.
 
Notes
(0015103)
karajorma   
2013-05-31 04:35   
The problem once again is that no one seems to have the faintest clue how to use the compatibility stuff.

I'm pretty much of the opinion that if no one wants to fix it, it should be ripped out and replaced with something easier to understand.
(0015105)
FUBAR-BDHR   
2013-05-31 05:02   
It's not the ;; FSO whatever compatibility stuff it's the save in retail format that should just be skipping non-retail stuff entirely.
(0015290)
Goober5000   
2013-09-23 01:33   
Yeah, version-specific commenting is one thing, but saving in retail format is pretty straightforward.




View Issue Details
2660 [FSSCP] user interface text always 2012-06-02 14:36 2014-06-24 13:00
z64555 Acer Aspire 3680  
z64555 Microsoft Windows  
low XP SP3  
confirmed 3.6.13  
open  
none    
none  
   
Joystick Axis Mis-mapping
When I try to map the Rotation axiis, I can only map two of them successfully and both are not mapped accordingly. I've verified the operation of the controller in Window's Game Controller Utility, and the R axiis are mapped accordingly and are functional.

Currently, the axiis are like so:
DirectInput FSO
Rx Rz
Ry None
Rz Rx
Note! You must have a controller driver/software that can have its axiis reconfigured.

1. Configure your controller to use axiis Rx, Ry, and Rz in lieu of X, Y, and Z
2. Verify operation in the game controller calibration utility
3. Run FSO, and open the Options menu
4. Try to configure the Rx, Ry, and Rz axiis to any of the ship control axiis
I'm using a Sony PS3 DualShock controller along with the MotionInJoy 0.6.0005 drivers.

In case you don't know, the drivers allow you to fully configure each and every control on the DualShock, and use DirectInput as it's main API.

The fact that the Game Controller calibration utility shows everything is functioning, tells me that the driver's are not the main issue for the R axiis mapping.
Additional Platform Specs:
 Intel Celeron M (1.86 GHz)
 2GB RAM
 Mobile Intel 945(OpenGL 1.4)

 
Notes
(0013626)
z64555   
2012-06-02 17:00   
Probably a derp:

3.6.14 RC6 has the same issue
(0013627)
iss_mneur   
2012-06-02 19:28   
Just to clarify, this is case of the labels not matching the actual axis as reported by DirectInput, correct?
(0013629)
z64555   
2012-06-02 22:01   
That it is.
(0015904)
dostatochno   
2014-06-22 19:09   
(Last edited: 2014-06-22 20:18)
As of 3.7.2 RC3, a significant relative of this bug remains.
As noted below, some inputs are completely ignored in actual gameplay.


When using a wired or wireless 360 controller on the computer directly, the second stick is misinterpreted:
   Actual | Interpreted | In-Game
 D.I./Xinput | by FSO | Behavior
  Rx / Rx | Ry | Control binds to Ry in config but is ignored in gameplay.
  Ry / Ry | Rx | Input actuates the control bound to Rx

Also with a Logitech Rumblepad 2:
 Actual | Interpreted | In-Game
  D.I. | by FSO | Behavior
   Z | Z | Input actuates the control bound to Z
   Rz | Rx | Input actuates the control bound to Rx

...and When using a 360 controller on another computer via Steam in-home Streaming:
Actual | Interpreted | In-Game
 DI/Xinput | by FSO | Behavior
  ? / Rx | Rx | Input actuates the control bound to Rx
  ? / Ry | Ry | Control binds to Ry in settings but is ignored in gameplay.

Other notes:
1) It would be awfully nice if half-axes (i.e. 360 controller triggers) could be bound to controls which are normally buttons
2) It would also be nice if an analog stick's axes could be bound to Look up/down/left/right so the view isn't locked to 90 degree increments on orthogonal axes.

(0015912)
z64555   
2014-06-24 13:00   
This should be one of the things to be fixed when the SDL antipodes branch gets into trunk. I'll have to check to see if I did anything about the Ry, Rz axes at some point...




View Issue Details
3062 [FSSCP] FRED minor always 2014-06-16 06:14 2014-06-16 18:16
Maslo66 PC  
Windows 7 SP1  
normal Ultimate 64-bit  
new  
open  
none    
none  
   
Background modifications wont save after importing background in FRED
If I import background from EveOfDestructionRedux.fs2 from fsport\fsport-missions.vp and save the mission, I get two errors

First Error:
C:\Users\Ondro\Desktop\mission\test.fs2(line 146):
Error: Required token = [#Wings] or [$Name:], found [+new: GTC_Orff].

ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fred2_open_3_7_2_RC3.exe! <no symbol>
fred2_open_3_7_2_RC3.exe! <no symbol>
fred2_open_3_7_2_RC3.exe! <no symbol>

Second Error:
C:\Users\Ondro\Desktop\mission\test.fs2(line 147):
Error: Required token = [#Wings] or [$Name:], found [+new: GTC_Orff].

ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fred2_open_3_7_2_RC3.exe! <no symbol>
fred2_open_3_7_2_RC3.exe! <no symbol>
fred2_open_3_7_2_RC3.exe! <no symbol>

If I make any modifications to the background (adding Suns or nebulae), it wont save them (they disappear immidiately after the saving is done).
1. Extract EveOfDestructionRedux.fs2 from fsport\fsport-missions.vp
2. Open FRED
3. Import background 1 from EveOfDestructionRedux.fs2
4. Save the mission (DEBUG build crashes here, regular build just shows the errors above)
5. Add Suns or nebulae
6. Save the mission (the additions disappear)
FRED2_OPEN v3.7.2 RC3

Mods:
FSPort MediaVPs v3.4 (including 2014-shp.tbm - Unofficial patch for FSPort MediaVPs to use with MediaVPs 2014)
FSPort v3.4
MediaVPs 2014
fred2_open.log (22,398 bytes) 2014-06-16 06:14
http://scp.indiegames.us/mantis/file_download.php?file_id=2403&type=bug
 
Notes
(0015887)
MageKing17   
2014-06-16 18:16   
This sounds like version-specific comments causing problems again.




View Issue Details
2943 [FSSCP] Build system feature always 2013-10-26 05:55 2014-06-04 15:05
ni1s  
chief1983  
normal  
assigned  
open  
none    
none  
   
CMake build system files
CMake build system files for fs2_open, fred and wxfred.

Note that these are incomplete and in some places just plain wrong.

Tested on Gentoo Linux and Windows 7(64bit)
cmake.patch (61,495 bytes) 2013-10-26 05:55
http://scp.indiegames.us/mantis/file_download.php?file_id=2280&type=bug
 
Notes
(0015370)
ni1s   
2013-10-28 15:54   
Git repo for this: https://github.com/nisselarsson/fs2_open_patchbucket.git
(0015791)
chief1983   
2014-06-04 15:05   
Another competitor now is https://github.com/asarium/fs2open.github.com/tree/cmake




View Issue Details
3044 [FSSCP] graphics minor always 2014-05-16 09:42 2014-05-16 09:42
fightermedic  
 
normal  
new 3.7.2 RC1  
open  
none    
none  
   
Thruster-Jets for non player ships not rendering reliably
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
 
There are no notes attached to this issue.




View Issue Details
3034 [FSSCP] scripting minor always 2014-04-20 16:32 2014-04-21 04:14
zookeeper  
 
normal  
new  
open  
none    
none  
   
Throttle flickers when using LUA_FULL_CONTROLS
Using the attached script (as tables/whatever-sct.tbm) shouldn't really do anything, yet it causes the player's throttle to flicker, seemingly between what it should be and the previous value.

I haven't found a workaround or found anything that one might be supposed to do to prevent the issue. It's also not because setControlMode() is called every frame; the same thing happens for instance with an $On Gameplay Start hook.
#Conditional Hooks

$State: GS_STATE_GAME_PLAY

$On Frame: [

    ba.setControlMode(LUA_FULL_CONTROLS)

]

#End
 
Notes
(0015706)
m_m   
2014-04-21 04:14   
I can reproduce this issue. What is the intended behavior of LUA_FULL_CONTROLS?




View Issue Details
2052 [FSSCP] multiplayer crash random 2009-11-24 18:13 2014-04-21 03:01
FUBAR-BDHR  
Echelon9  
normal  
assigned 3.6.11  
open  
none    
none  
   
Standalone - Int(3) ship_get_indexed_subsys - Player drop related?
Looks like this one might be caused by corrupted data from a client disconnect. Multi.log didn't show a disconnect but there seem to be a lot of issues in FS2_Open.log right before the crash. Attaching logs and info.
3.6.11 r5666
ship_get_indexed_subsystem.rar (209,642 bytes) 2009-11-24 18:13
http://scp.indiegames.us/mantis/file_download.php?file_id=1359&type=bug
 
Notes
(0015472)
Echelon9   
2013-11-30 20:25   
Have we had any more recent reports? Significant code change has occurred over last 3 years.

Would be good to trigger on an AddressSanitizer-enabled standalone server to get a precise view of any memory corruption going on.




View Issue Details
2297 [FSSCP] multiplayer crash have not tried 2010-08-25 16:19 2014-04-21 03:00
FUBAR-BDHR  
Echelon9  
normal  
assigned 3.6.13  
open  
none    
none  
   
Standalone crash trying to respawn beta 4 which isn't even in mission
This one just doesn't make any sense. Mission CoopSM2-01.fs2 from the 3.6.12 MediaVPs. Crash on subsystem index 167 (pilot) which doesn't even exist(index goes from 166 to 173) from ship beta4 which also doesn't exist. Beta wing is in the mission but is a reinforcement wing with 1 wave of 3 ships. No beta 4.

Also of interest was that 2 ships were on the respawn list. Beta 4 and the Warspite which shouldn't respawn either.

I did try seeing if you could assign a player to beta wing and you can't.

Attaching stack dump and variables. Logs don't show anything but I'll attach them as soon as I get out of the debugger.
beta4wtf.txt (40,057 bytes) 2010-08-25 16:19
http://scp.indiegames.us/mantis/file_download.php?file_id=1565&type=bug
2297.rar (844,190 bytes) 2010-08-26 19:56
http://scp.indiegames.us/mantis/file_download.php?file_id=1566&type=bug
 
There are no notes attached to this issue.




View Issue Details
2175 [FSSCP] multiplayer crash have not tried 2010-04-06 02:56 2014-04-21 03:00
FUBAR-BDHR  
Echelon9  
normal  
assigned 3.6.12 RC1  
open  
none    
none  
   
Crash on standalone from player respawning/observer/rearm scenario - aicode 15550
Looks like support attempted to rearm an observer or something like that. Attaching stack, variables, and logs.
3.6.13 r6005. Retail data.
aicode_15550.txt (57,160 bytes) 2010-04-06 02:56
http://scp.indiegames.us/mantis/file_download.php?file_id=1469&type=bug
2175.rar (473,159 bytes) 2010-04-06 02:58
http://scp.indiegames.us/mantis/file_download.php?file_id=1470&type=bug
 
There are no notes attached to this issue.




View Issue Details
1983 [FSSCP] multiplayer feature sometimes 2009-08-23 03:15 2014-04-21 03:00
FUBAR-BDHR  
 
normal  
feedback 3.6.11  
reopened  
none    
none 3.6.13  
   
Discussion: Hand off nebula rendering to clients completely from standalone
Debugger call stack and variables attached.

Basically your_basic_hot_sauce is turning up null along with start and strike.
3.6.11 r5524
hot_sauce.txt (3,692 bytes) 2009-08-23 03:15
http://scp.indiegames.us/mantis/file_download.php?file_id=1319&type=bug
 
Notes
(0011152)
Wanderer   
2009-08-23 05:41   
(Last edited: 2009-08-23 05: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 15:48   
Fixed in rev 7288
(0012737)
The_E   
2011-06-28 17: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 05: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
2019 [FSSCP] multiplayer crash random 2009-11-04 18:41 2014-04-21 02:59
FUBAR-BDHR  
Echelon9  
normal  
assigned 3.6.11  
open  
none    
none  
   
Assert: Weapon_info[weapon].subtype == WP_MISSILE on standalone
Seen this a couple of times now. Not sure what is causing it but at least one time it appeared it was trying to fire a beam weapon as a secondary but that was in FSPort. This time it was the retail data standalone. Attaching stacks and variables.
3.6.11 r5625.
wp_missile.txt (73,311 bytes) 2009-11-04 18:41
http://scp.indiegames.us/mantis/file_download.php?file_id=1340&type=bug
2019.rar (148,028 bytes) 2012-12-11 00:23
http://scp.indiegames.us/mantis/file_download.php?file_id=2042&type=bug
2019_retail2.rar (81,056 bytes) 2012-12-30 14:23
http://scp.indiegames.us/mantis/file_download.php?file_id=2078&type=bug
 
Notes
(0014420)
FUBAR-BDHR   
2012-12-10 23:18   
(Last edited: 2012-12-11 00:02)
Just had 2 standalones go down with this. Circumstances on both are nearly identical.

Server 1 is retail data
Server 2 is mediavp data
Server 1 was mission M-01b
Server 2 was mission M-01
Server 1 went down with both secondary weapon indexes showing 129
Server 2 went down with both secondary weapon indexes showing 126
Primary weapons and ships on both were default
Ships on both were default
Both were Alpha 1
Both were the one and only player ship

I've tried to reproduce this myself on another standalone running the same revision and retail data with no luck. I've also tried tracking down the player (FS2NetD handle Niklan) from both crashes to see what settings were being used on his end but that name is not on IRC or registered on forums under any of the search options.

I'll be attaching logs from both servers.

That was with r9418

Stack:

     fs2_open_3_6_15d_INF_SSE2.exe!debug_int3(char * file=0x010a0524, int line=963) Line 768 C++
     fs2_open_3_6_15d_INF_SSE2.exe!WinAssert(char * text=0x010ac868, char * filename=0x010a6082, int linenum=11015) Line 963 + 0x13 bytes C++
> fs2_open_3_6_15d_INF_SSE2.exe!ship_fire_secondary(object * obj=0x0129d4d8, int allow_swarm=0) Line 11015 + 0x2c bytes C++
     fs2_open_3_6_15d_INF_SSE2.exe!obj_player_fire_stuff(object * objp=0x0129d4d8, control_info ci={...}) Line 746 + 0xb bytes C++
     fs2_open_3_6_15d_INF_SSE2.exe!multi_oo_process() Line 1369 + 0x47 bytes C++
     fs2_open_3_6_15d_INF_SSE2.exe!multi_do_frame() Line 1263 C++
     fs2_open_3_6_15d_INF_SSE2.exe!game_do_networking() Line 1103 C++
     fs2_open_3_6_15d_INF_SSE2.exe!game_do_state_common(int state=2, int no_networking=0) Line 6442 C++
     fs2_open_3_6_15d_INF_SSE2.exe!game_do_state(int state=2) Line 6455 + 0xb bytes C++
     fs2_open_3_6_15d_INF_SSE2.exe!gameseq_process_events() Line 407 + 0x14 bytes C++
     fs2_open_3_6_15d_INF_SSE2.exe!game_main(char * cmdline=0x0015232f) Line 7086 + 0x5 bytes C++
     fs2_open_3_6_15d_INF_SSE2.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x0015232f, int nCmdShow=10) Line 7155 + 0x9 bytes C++
     fs2_open_3_6_15d_INF_SSE2.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C
     fs2_open_3_6_15d_INF_SSE2.exe!WinMainCRTStartup() Line 182 C
     kernel32.dll!7c817077()
     [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
     user32.dll!7e46c930()

(0014590)
karajorma   
2012-12-30 10:26   
Has this one appeared since?
(0014594)
FUBAR-BDHR   
2012-12-30 12:45   
(Last edited: 2012-12-30 14:25)
Think I got this one yesterday but haven't had a chance to check the log on it.

Confirmed same issue. Secondary weapon indexes are 129 and 121 and it's retail data.

Logs attached. Noticed that secondary weapon indexes in ship do not match those in ship_info and ship_info ones appear to be valid.

(0014703)
FUBAR-BDHR   
2013-02-11 15:32   
Had another version of this same issue show up today on the FSPort-MVP server. Error was: ASSERTION: "Polygon_models[num]" at modelread.cpp:2974. Ship had a secondary index of 56 which is the MX-50#Shivan which wasn't even in the mission and showed skipped during load in the log. Probably didn't get the standard crash because it is a valid index and a secondary weapon.

Anyway another instance of the index being wrong for the ship causing an issue on a standalone.




View Issue Details
3017 [FSSCP] localization major always 2014-03-09 14:37 2014-03-16 09:26
Yarn x64  
karajorma Windows 7  
normal  
acknowledged 3.7.1  
fixed  
none    
none  
   
Localization "hacks" no longer used
Ever since Karajorma's strings.tbl addition was implemented at revision 9761, certain localization features (such as translating the ETS labels and fixing certain non-English letters) stopped working. This happens because the code no longer changes the values of the lcl_?? variables in localize.cpp, even though those features still read from thess variables.
I have attached a patch that provides a possible fix for this bug.
mantis3017.patch (1,452 bytes) 2014-03-09 14:37
http://scp.indiegames.us/mantis/file_download.php?file_id=2329&type=bug
 
Notes
(0015664)
karajorma   
2014-03-16 09:25   
Fix committed to trunk@10496.




View Issue Details
3008 [FSSCP] graphics minor always 2014-02-16 14:54 2014-02-16 14:54
MatthTheGeek  
 
normal  
new 3.7.1  
open  
none    
none  
   
External weapon fire is off when $Show Primary Models: set to no
Weapons that have an external model will fire from the firepoint defined in the external weapon pof, REGARDLESS of whether $Show Primary Models is set to yes or no in the ship table, which makes weapon fire appear from thin air when it's set to no.

Small test mod here: https://www.dropbox.com/s/38o8cx8egij47tj/ExternalWepTest.rar

Test mod requires MVPs because the issue is not exactly easy to notice if you don't have muzzle flashes. Fly an Ulysses with Subachs, $Show Primary Models is set to (no yes) so that you can easily compare.

Confirmed on latest nightly, and nightly from 01/01/2014
1) Have a weapon with an $External Model File: with a firepoint that isn't at 0,0,0
2) Mount said weapon on a gun bank with $Show Primary Models set to no
3) Fire
4) In external view, notice that bullets don't spawn at the ship firepoint, but where the firepoint of the external weapon would be if it was rendered.
 
There are no notes attached to this issue.




View Issue Details
3003 [FSSCP] FRED feature N/A 2014-02-02 14:18 2014-02-02 14:18
Shadowwolf_IH Windows  
8  
normal 8.1  
new 3.6.14  
open  
none    
none  
   
replace texture sexp
Feature request allowing us to use a sexp to specify a parameter (such as is hull < x%, then allowing us to choose a ship, and replace the texture. This would allow for multiple damage textures to be switched between as the ship takes more damage.
n/a
n/a
 
There are no notes attached to this issue.




View Issue Details
2996 [FSSCP] graphics major always 2014-01-04 04:37 2014-01-04 04:39
MetalDestroyer  
 
normal  
new 3.7.1  
open  
none    
none  
   
Flickering screen when using resolution higher to 1080p
Using this nightly :
http://www.hard-light.net/forums/index.php?topic=86479.0

Just after a mission is loaded, the flickering screen happens when playing with a resolution like 2560x1440, or 2880x1620 @ 60 Hz.
For information, I'm playing with a 27" LCD monitor (Asus VG278H 3D Vision 2 Ready 120 Hz). Natively, the monitor support a max resolution of 1080p. But can be overidden to support higher resolution within Downsampling techniques.

For most games, using this unsupported resolution works pretty well.
Having monitor that support those resolutions natively or with an unsupported way within downsampling techniques.
For the unsupported, the resolution is set within Graphic card driver (Catalyst Control Center or nVidia Control Panel).
There's option to customize resolutions and refreshrate and also an option to tell where the scaling will be done (by the monitor or by the GPU). Well, at least on nVidia card.
 
Notes
(0015566)
MetalDestroyer   
2014-01-04 04:39   
Forgot one thing, after those resolution are set. They are available in the launcher as valid resolution, so you can choose them.




View Issue Details
2984 [FSSCP] graphics minor always 2013-12-21 11:10 2013-12-21 11:10
MatthTheGeek  
 
normal  
new 3.7.1  
open  
none    
none  
   
-trans doesn't work on cockpit pof
-trans textures don't show at all on top of other geometry when in a cockpit pof (using $Cockpit POF file: in ships.tbl).

You can find a simple test mod here https://www.mediafire.com/?ppc5vmdu5y8x3ob . Cockpit will be visible on the GTF Ulysses, just start Massive Battle or something.

The bottom middle screens aren't rendered and the two side screens are cut by the geometry.
 
There are no notes attached to this issue.




View Issue Details
2827 [FSSCP] multiplayer block always 2013-03-28 22:09 2013-12-04 16:49
Hunter  
 
high  
feedback  
reopened  
none    
none  
   
Problems configuring multiplayer connections
Thread renamed to reflect non widespread nature of the original reporter's problem

It doesnt matter how much you play with port forwarding, dmz or going over to friends houses, we are permablocked. This has been an ongoing problem for many many years and has kept me from playing for a long long time. The only standalones availilble for play run 400ms here in america and is completely unplayable. Please help us find a way to get us back online!!!
 
Notes
(0014852)
Echelon9   
2013-03-29 05:17   
While possible, it sounds a little hyperbolic to say definitively that all American DSL connections are somehow blocked without further evidence.

Have you discussed this on the Freespace Multiplayer sub-forum? http://www.hard-light.net/forums/index.php?board=135.0

I'm inclined to view this as more likely to be a configuration issue that can be more effectively resolved in the forums, rather than an engine issue or bug for fixing here on Mantis.
(0014853)
Hunter   
2013-03-29 05:52   
(Last edited: 2013-03-29 06:01)
5 connections i have access too, and 4 friends accross the states who also are in the same situation. Yeah ALL. I have spent TOO MUCH time trying to figure it out, and talking to people in the community i have on chat about this issue. We just want to play this game!!!

Fubars Standalones are generous but we arent on that side of the planet. 400ms in game is unplayable.

(0014854)
Echelon9   
2013-03-29 08:28   
Okay, but a Mantis issue for this type of problem you're experiencing isn't going to resolve much.

Better to test your configuration setup thoroughly on the forums / IRC where we can help you figure it out.
(0014855)
Zacam   
2013-03-29 08:54   
FUBAR's Standalones are in America, fyi.

Sounds more like an ISP or network (local) issue.
(0014856)
Hunter   
2013-03-29 08:57   
How can it be local when it affects friends in Wisconsin and Missouri aswell, If fubars servers are in america, then there is something seriously wrong with the new code. FS2 should be pingging below 100ms california to wisconsin 50ms in the PXO days
(0014857)
Zacam   
2013-03-29 09:15   
*sighs*

Well, for one, I can tell you that the networking portions of the code itself? Have not had anywhere near the kind of over haul that you think they have.

Granted, that may be a part of the problem in and of itself. What works for modem based IP stack play doesn't generally tend to scale well for broadband.

But if you and your friends are having HUGE ms latency issues reaching standalones (that are merely portaled off the FS2NetD on HLP), then either the Standalone hosts connections are having an issue, or your ISPs peering is having difficulty.

And as for it being a local issue (that repeats in various locations across the states) that can happen very easily if you've all made the same assumptions about your network setups.
(0014858)
FUBAR-BDHR   
2013-03-29 22:05   
Yep my standalones are in the US and up until a couple of months ago were on DSL. Now they are on Uverse but in this area that is actually still DSL. So DSL in the US is not blocked in any way by FS2netD. If your having issues it's elsewhere.
(0014859)
Hunter   
2013-03-29 22:21   
(Last edited: 2013-03-29 22:22)
How do i get 400ms on the same ISP as fubar. WTF

(0014920)
Zacam   
2013-04-13 19:42   
Maybe run a tracert (Trace Route) from your connection to the Standalone's IP address and view where the packets take the most time? That will be your problem, not FSO.
(0015489)
Echelon9   
2013-12-03 04:49   
Mantis is not for general support requests. Also not fire and forget bug tracking.
(0015501)
Hunter   
2013-12-03 22:42   
(Last edited: 2013-12-03 22:56)
Its still broken for everyone. Why was this closed. We are still waiting for this issue to be resolved. It seems like if your not a DEV you get the middle finger. I wonder if this game will ever be playable again. Nobody can host, not turey, not anyone I know. I posted this here because I was told to by members of your community.

This ticket needs resolution, not closure. People who wern't blocked and didn't change their internet are now blocked. The world is changing how the internet works. The problem is your code.

(0015502)
niffiwan   
2013-12-03 23:06   
o_O I've been able to connect to FUBAR's standalones and play a game. Not that they're up at the moment, but go back 3-6 months when they were and it was OK. If we can't reproduce the problem, it makes it exceedingly difficult to troubleshoot.

Maybe organise a time (using the Multi Forum) to connect to the #multi IRC channel and attempt to work through the problems in realtime? Maybe you could also run that tracert that Zacam suggested in April and post the results?
(0015504)
Hunter   
2013-12-04 12:18   
(Last edited: 2013-12-04 12:24)
Fine, I will be uploading video to youtube showing you configurations on everyones connection!!! We arent idiots and two of us are employed in IT. But apparently you need a walk through. I have been playing this game for 13 years, I know how to set it up.

(0015505)
niffiwan   
2013-12-04 16:31   
(Last edited: 2013-12-04 16:32)
Hey - if you're in IT can you provide packet captures of your connection attempts as well?

It'd also help to have a read of this:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

(0015506)
chief1983   
2013-12-04 16:49   
Pretty sure there are definitely some connection establishment bugs in the code, not sure how old they are but they're definitely there. I have run a standalone at my house that I have not been able to connect to from work, but others can, and even from within the same house it can be somewhat of a crapshoot. It should not be that difficult for computers on the same LAN to connect, and any computer with port forwarding set up for anyone to connect to, should be connectable by everyone, assuming there's not blocking going on on the client's side. But that does not currently seem to be the case, and now that the *nix standalone itself seems to be getting pretty stable and usable, figuring out why they're so difficult to connect to was going to be one of the next things I pushed for. I just don't think it's any one specific bug.




View Issue Details
2972 [FSSCP] graphics minor always 2013-12-03 18:44 2013-12-03 18:44
Droid803  
 
normal  
new 3.7.1  
open  
none    
none  
   
Inconsistent Thruster Particle Generation
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.
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.
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."
 
There are no notes attached to this issue.




View Issue Details
1893 [FSSCP] multiplayer trivial random 2009-03-07 04:37 2013-12-03 06:57
FUBAR-BDHR  
 
normal  
feedback 3.6.9  
open  
none    
none  
   
Clients occasionally jump from place to place.
This is one of those old retail bugs that I thought had long since vanished. Tonight someone was reporting it over and over again in one mission (MT-07). It's been a long time so I don't remember the exact circumstances. If I had to guess the client jumps from spawn point to spawn point while waiting to respawn. While this is going on his ship may actually be in game. Whether it's AI controlled or just flying a straight line I really don't know. They are able to respawn at some point possibly after their ship gets killed again.
3.6.10 r5088. I'm pretty much reporting this as something to watch out for. I wasn't running debug tonight so I don't have a log. I'm guessing it's lag related as tonight we had some of the biggest FS2 games I can remember since retail. This happened with at least 7 if not 8 people in a TvT. Standard hosting no standalone involved. It was a pretty common occurrence in retail.
 
Notes
(0015495)
Echelon9   
2013-12-03 06:57   
Any more recent reports? There have been plenty of code base changes in the intervening period that may have resolved this issue.




View Issue Details
2486 [FSSCP] multiplayer minor sometimes 2011-08-21 16:41 2013-12-03 06:56
Lester  
 
normal  
feedback 3.6.13  
open  
none    
none  
   
Respawning near ship sporadically doesn't work for player-controlled ships
Pretty much self explanatory. This newly rediscovered feature could help both multi projects very much, as it doesn't ask for a work-around.

It's apparently a retail feature and doesn't work on all missions except Knife Fight.

Issue reproduced using retail data in a mission by QuantumDelta. Said mission is attached
LetsSee.fs2 (6,781 bytes) 2011-08-21 16:41
http://scp.indiegames.us/mantis/file_download.php?file_id=1679&type=bug
 
Notes
(0015494)
Echelon9   
2013-12-03 06:56   
Can we get some more information on what the expected behaviour is, and in what way the current behaviour is different.

I'm not sure what I should be looking for in the attached mission.




View Issue Details
2778 [FSSCP] multiplayer minor have not tried 2013-01-10 18:01 2013-12-03 04:43
FUBAR-BDHR  
karajorma  
normal  
assigned 3.6.15  
fixed  
none    
none  
   
Assert on standalone resulting from divide by 0 caused by game_skill_level being out of range
Yea that's a mouthful but no idea how to state it better.

Had a standalone crash with an Assert(t_goal < delta_t) from approach() in aicode.cpp. Turs out the value of aa (as well as w_max) was -1.#INF000. This was eventually traced back to a set of divide by 0 due to Ai_info[Ships[objp->instance].ai_index].ai_turn_time_scale on line being -0.0 in ai_turn_towards_vector() line 1160. After some more digging the root of the problem was found in init_aip_from_class_and_profile() where the value was set incorrectly as game_skill_level was 222 (valid range is 0-4).

There are asserts for this all over the code except in 2 key areas: Reading from pilot file and sending/receiving multiplayer packets. The only way I can figure that this could happen is if the client who was the host had a corrupted pilot file with the 222 value and that got sent to the host.

So other then the obvious adding some code that checks the values sent and received and probably verifying after the read from the pilot file (I haven't checked the new pilot code) can you think of anything else that could have caused this or done to fix it?

Also probably should add a check before those divide by 0s.
2778_multimsg.patch (1,111 bytes) 2013-01-13 15:41
http://scp.indiegames.us/mantis/file_download.php?file_id=2096&type=bug
 
Notes
(0014630)
niffiwan   
2013-01-10 20:07   
Do you know what version of FSO the client was running? i.e. is it the new or old pilot code that might be at fault?
(0014631)
FUBAR-BDHR   
2013-01-10 20:49   
Unfortunately as with most standalone issues I don't have any information client side outside of the pilot names.
(0014636)
FUBAR-BDHR   
2013-01-12 16:56   
Attached patch that should catch this and reset in multimsg. I'll put it up on the standalones for testing next time I update them.

This doesn't address the pilot file or the /0.
(0014659)
karajorma   
2013-01-24 08:48   
I suspect I've seen this issue in a slightly different form. I have a pilot which always crashes the options screen with an out of range value. Unfortunately I was busy fixing other bugs at the time so I didn't have the chance to figure out what caused it.
(0014679)
karajorma   
2013-02-01 23:03   
Well I took a look at it and I'm still not sure where the corruption client side is coming from. I think the patch in addition to patching init_aip_from_class_and_profile() with a sanity check would be a good solution so I'll commit that but leave this open so that I can take a better look at it when I'm better equipped to look at bugs.
(0014680)
karajorma   
2013-02-01 23:41   
Fix committed to trunk@9520.
(0014760)
FUBAR-BDHR   
2013-03-09 18:02   
Interesting I just got the warning for sending a packet from the host on one of the standalones. Skill level was 129. Since the receive packet check didn't trigger it seems like something is going wrong on the standalone itself to cause this issue.
(0015037)
FUBAR-BDHR   
2013-05-06 05:21   
Just had the Port stadalone go down with this warning so the skill level is still somehow getting corrupted. Runnin r9668




View Issue Details
2012 [FSSCP] multiplayer major always 2009-10-28 20:01 2013-12-01 22:08
FUBAR-BDHR  
 
normal  
feedback 3.6.11  
open  
none    
none  
   
Reinforcements not working for clients in TvT
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.
3.6.11 r5620
2multibug.fs2 (7,930 bytes) 2009-10-28 20:01
http://scp.indiegames.us/mantis/file_download.php?file_id=1337&type=bug
 
Notes
(0014591)
karajorma   
2012-12-30 10: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-01 22:07   
(Last edited: 2013-12-01 22: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.





View Issue Details
2389 [FSSCP] multiplayer minor always 2011-01-31 01:04 2013-12-01 06:16
bigchunk1  
 
normal  
feedback 3.6.12  
open  
none    
none  
   
Multiplayer fighters with ballistic primaries spawn with negative ammo counts
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.
 
Notes
(0013992)
karajorma   
2012-10-26 03:14   
Is this still an issue?




View Issue Details
2129 [FSSCP] multiplayer crash have not tried 2010-02-15 18:30 2013-12-01 05:38
FUBAR-BDHR  
 
normal  
new 3.6.11  
open  
none    
none  
   
Assert: (signature >= NPERM_SIG_MIN) in multiutil.cpp line 214
Got this on the retail data standalone. Absolutely no idea on this one. Mission was Cet_M07.fs2 Attaching stack and variables.
3.6.11 r5868. I have the log and will attach it later. Leaving the debugger open for now so it's locked. Doesn't appear to be anything special in it.
nperm_sig_min.txt (14,106 bytes) 2010-02-15 18:30
http://scp.indiegames.us/mantis/file_download.php?file_id=1425&type=bug
2129.rar (1,000,056 bytes) 2010-02-17 17:07
http://scp.indiegames.us/mantis/file_download.php?file_id=1429&type=bug
 
There are no notes attached to this issue.




View Issue Details
2757 [FSSCP] multiplayer crash have not tried 2012-12-18 17:47 2013-12-01 05:38
FUBAR-BDHR  
Valathil  
normal  
feedback 3.6.15  
open  
none    
none  
   
ASSERTION: "(team_index != -1) && (slot_index != -1)" at multiteamselect.cpp:876
Possible this was caused by a drop during loading or file xfer as there is an indication of such an event near the end of the standalone log.
2757.rar (134,190 bytes) 2012-12-18 17:47
http://scp.indiegames.us/mantis/file_download.php?file_id=2069&type=bug
2757_2.rar (219,877 bytes) 2012-12-18 17:55
http://scp.indiegames.us/mantis/file_download.php?file_id=2070&type=bug
 
Notes
(0014529)
FUBAR-BDHR   
2012-12-18 17:55   
Make that 2 standalones crashed with the same thing. One retail and one mediavp. Both running r9431.
(0014533)
Valathil   
2012-12-18 20:27   
Added an assert in Trunk @ 9454 to give me a better crash dump. Please report when it crashes with this new version.
(0014560)
karajorma   
2012-12-22 00:41   
I'm not certain that assert is quite correct. If you look at multi_ts_init_objnums() both of those values being -1 is quite legal as that function calls multi_ts_get_team_and_slot() for every single ship.

Now it might be okay to leave the assert as is and make multi_ts_init_objnums() only call it for things marked as PLAYER_SHIP.
(0014576)
Valathil   
2012-12-25 13:11   
I changed it around a bit so it only triggers in the circumstance that OP reported




View Issue Details
2377 [FSSCP] multiplayer crash always 2011-01-11 19:28 2013-11-30 21:29
SDM  
The_E  
normal  
assigned 3.6.13  
open  
none    
none  
   
Crash when pressing F2 after death but before respawn - Assert: model_instance_num < (int)Polygon_model_instances.size()
The game crashes every time I died and pressed F2 before I respawned. Although I changed the sound to ensure consistency, it probably crashes even without changing sounds, but that has not been tested yet as there were not enough multi games to conduct further testing.
Call stack:

WinAssert(char*, char*, int) + 981
model_get_instance(int) + 591 (modelread.cpp:2987)
model_clear_submodel_instances(int) + 493 (modelread.cpp:4536)
ship_model_update_instance(object*) + 1466 (ship.cpp:12268)
obj_move_all_post(object*, float) + 5626 (object.cpp:1218)
obj_move_all(float) + 4462 (object.cpp:1431)
game_simulation_frame() + 10078 (freespace.cpp:4025)
game_frame(bool) + 4658 (freespace.cpp:4399)
game_do_frame() + 604 (freespace.cpp:4814)
game_do_state(int) + 1419 (freespace.cpp:6596)
gameseq_process_events() + 1283 (gamesequence.cpp:409)
game_main(char*) + 2121 (freespace.cpp:7061)
fs2_open.log (45,931 bytes) 2011-01-11 19:28
http://scp.indiegames.us/mantis/file_download.php?file_id=1631&type=bug
 
Notes
(0012723)
Zacam   
2011-06-22 20:00   
(Last edited: 2011-06-22 20:13)
Able to reproduce on Antipodes 7267.

F2 pressed during "death spin" or "respawn" screen will result in the following
(after hitting Accept):

Assert: model_instance_num < (int)Polygon_model_instances.size()
File: modelread.cpp
Line: 2872

ntdll.dll! NtWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_13d_SSE2.exe! SCP_DumpStack + 354 bytes
fs2_open_3_6_13d_SSE2.exe! WinAssert + 208 bytes
fs2_open_3_6_13d_SSE2.exe! model_get_instance + 106 bytes
fs2_open_3_6_13d_SSE2.exe! model_clear_submodel_instances + 39 bytes
fs2_open_3_6_13d_SSE2.exe! ship_model_update_instance + 192 bytes
fs2_open_3_6_13d_SSE2.exe! obj_move_all_post + 577 bytes
fs2_open_3_6_13d_SSE2.exe! obj_move_all + 352 bytes
fs2_open_3_6_13d_SSE2.exe! game_simulation_frame + 1229 bytes
fs2_open_3_6_13d_SSE2.exe! game_frame + 469 bytes
fs2_open_3_6_13d_SSE2.exe! game_do_frame + 239 bytes
fs2_open_3_6_13d_SSE2.exe! game_do_state + 854 bytes
fs2_open_3_6_13d_SSE2.exe! gameseq_process_events + 237 bytes
fs2_open_3_6_13d_SSE2.exe! game_main + 782 bytes
fs2_open_3_6_13d_SSE2.exe! WinMain + 330 bytes
fs2_open_3_6_13d_SSE2.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_6_13d_SSE2.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes

polymodel_instance* model_get_instance(int model_instance_num)
 model_instance_num 0 int

void model_clear_submodel_instances( int model_instance_num )
 model_instance_num 0 int
+pmi 0xcccccccc {model_num=??? root_submodel_num=??? submodel=??? } polymodel_instance *
+pm 0xcccccccc {id=??? version=??? filename=0xccccccd4 <Bad Ptr> ...} polymodel *
 i -858993460 int

void ship_model_update_instance(object *objp)
+objp 0x01184170 struct object * Objects {next=0x011843a4 prev=0x01179d88 signature=1 ...} object *
+pss 0xcccccccc {next=??? prev=??? system_info=??? ...} ship_subsys *
+psub 0xcccccccc {flags=??? name=0xccccccd0 <Bad Ptr> subobj_name=0xccccccf0 <Bad Ptr> ...} model_subsystem *
 model_instance_num 0 int
+shipp 0x0167df78 struct ship * Ships {objnum=0 ai_index=0 ship_info_index=32 ...} ship *

(0013994)
karajorma   
2012-10-26 06:38   
Client side or server side?
(0013998)
karajorma   
2012-10-28 06:19   
This error does appear to be linked to E's change in r6878. The Polygon_model_instances vector is empty so the assert is triggered.

This may just be a case of an overzealous assertion so I'm going bounce this over to The E for checking.
(0015476)
Echelon9   
2013-11-30 20:59   
(Last edited: 2013-11-30 21:29)
Still present as of SVN r10175.

Prior to reaching the Assert, game_level_close() has been called which will lead to a call to model_instance_free_all().

model_instance_free_all() contains the call to Polygon_model_instances.clear().





View Issue Details
2965 [FSSCP] graphics minor always 2013-11-27 08:22 2013-11-27 08:24
ssmit132  
 
normal  
new 3.7.0  
open  
none    
none  
   
Weapon glowpoints appear to stay in origin position if using external models
If a ship shows external models for secondary weapons, and the models for those weapons have glowpoints, then the glowpoint effects will not be positioned correctly, instead acting as if the ship is at the mission origin.
I've attached a small test mod to show this error. It contains a modified stock model of the GTF Hercules - with secondary firing points moved to the outside of the model so that the missiles are easily visible to start with - as well as a table that enables external weapon models for the Hercules, and a mission containing both a player and AI Hercules to test with.

Once in the mission, switching to external view and zooming out so that the mission origin (to the right and behind the player's starting position) is visible should show the missile glowpoints. They will remain there regardless of where either of the ships is located, but they still respond to their associated secondaries being fired (i.e. firing a secondary will cause the glowpoint to jump backwards and then move forwards slowly, as per reloading of external secondaries). It doesn't seem to matter whether it is the player's or the AI's ship that has the secondaries.

MV_Assets from the 3.6.12 Media VPs is required as that contains the secondary weapons with glowpoints.
Version in use was "fs2_open_3_7_0".

I was busy creating a mission to take screenshots in, which included the player having a ship class that uses external weapons (TF Zelos). During gameplay I noticed an odd set of glows in the distance, and when retrying the mission I found that the glows that were added to the Media VP missiles stayed in the same position in the gameplay area when the player ship moved.

I haven't tested this with primary external weapon models with glows or secondary weapons that have a different model for external weapons with glows.

Hopefully I've given enough information here.
Externals_test.zip (105,814 bytes) 2013-11-27 08:22
http://scp.indiegames.us/mantis/file_download.php?file_id=2298&type=bug
screen1553 - 28-11-2013 (arrow).png (170,258 bytes) 2013-11-27 08:23
http://scp.indiegames.us/mantis/file_download.php?file_id=2299&type=bug
png

screen1554 - 28-11-2013 (arrow).png (244,747 bytes) 2013-11-27 08:23
http://scp.indiegames.us/mantis/file_download.php?file_id=2300&type=bug
png
 
There are no notes attached to this issue.




View Issue Details
2948 [FSSCP] graphics minor always 2013-11-01 16:56 2013-11-01 19:30
MatthTheGeek  
 
normal  
new 3.7.0  
open  
none    
none  
   
Flickering glowpoints when different On and Off time
It seems the glowpoint start flickering when the On and Off times are different in the pof. I have attached an example pof which is a modified Herc, to use with mediavps_3612.

The blue glow points on the nose have equal On and Off time of 300ms and show properly.

The red glow point on the fin has an On time of 300ms and an Off time of 100ms and flickers wildly.

Confirmed on 3.7.0 final
Fighter06.rar (438,253 bytes) 2013-11-01 16:56
http://scp.indiegames.us/mantis/file_download.php?file_id=2286&type=bug
 
There are no notes attached to this issue.




View Issue Details
2924 [FSSCP] graphics minor always 2013-09-22 12:16 2013-10-20 12:24
fightermedic  
 
normal  
new 3.7.0  
open  
none    
none  
   
Team Color not applied to Cockpits and LODs
Team Colors are not applied to cockpits and all LODs that have no shaders rendered on them
 
Notes
(0015337)
zookeeper   
2013-10-20 12:24   
I think r9929 probably fixed the issue for LODs.




View Issue Details
2935 [wxFRED] feature N/A 2013-10-13 15:45 2013-10-13 15:45
z64555  
 
none  
new  
open  
none    
none  
   
Mission Simulation/Preview Feature for wxFRED
I'm stuffing this here in case I forget/ can't get around to implementing.

This feature would allow Fredder's to test out the mission they're working on inside of wxFRED, without needing to boot up the full instance of FSO. Four controls would be added, and their operation is similar to those on a vCR.

Play/Pause: Starts, pauses, or resumes the simulation. All editing functions are disabled during simulation, and most are enabled when the simulation is paused.

Rewind: Rewinds the simulation. Depending on memory needs and how the mission history is saved, this will likely be limited to a few minutes of game time.

Reset: Resets the state of the mission to the very beginning of the mission.

Fast Forward: Advances the simulation by playing at a slightly faster rate than normal.

Skip to End: Plays the simulation at the fastest rate without rendering. Use this to quickly test how a mission will end without sitting through the details.
Perhaps the most difficult control to implement would be the Rewind function, as it would require the complete state of the mission to be regularly saved.

A mission log of sorts would be required for the Skip to End control to be of any great use. The log would record when an AI shoots, engages, enters, dies, etc. and maybe also when certain sexp's and events are triggered.
 
There are no notes attached to this issue.




View Issue Details
2928 [FSSCP] graphics minor have not tried 2013-09-29 07:33 2013-09-29 07:33
fightermedic  
 
low  
new  
open  
none    
none  
   
afterburner trails rendered after engine is destroyed
afterburner trails are still being rendered after the engine subsystem they belong to is already destroyed, it looks rather weird if trails appear out of thin air
 
There are no notes attached to this issue.




View Issue Details
2927 [FSSCP] graphics minor always 2013-09-29 07:28 2013-09-29 07:28
fightermedic  
 
low  
new  
open  
none    
none  
   
thrusters not being rendered in cockpit view
the small slide/roll/reverse thrusters are not being rendered while in cockpit view, which is breaking immersion if parts of the ship that have thrusters on them are visible in said view
 
There are no notes attached to this issue.




View Issue Details
2915 [FSSCP] scripting minor always 2013-08-31 14:45 2013-09-01 04:55
FelixJim  
 
normal Win 7  
new 3.7.0 RC2  
open  
none    
none  
   
gr.drawMonochromeImage() dimensions define bounding box rather than image dimensions
Calling drawMonochromImage() with x1, y1, x2 and y2 will cause an image to be drawn at its default size with the top left corner at (x1,y1). Any part of the image outside of the box defined by x2, y2 will simply be cut off - the image will not be resized to fit like it is in drawImage().
Run FSO with the attached script in data\tables of the current mod.
drawMonochromImage-sct.tbm (431 bytes) 2013-08-31 14:45
http://scp.indiegames.us/mantis/file_download.php?file_id=2260&type=bug
 
There are no notes attached to this issue.




View Issue Details
2910 [FSSCP] user interface minor always 2013-08-18 09:02 2013-08-30 05:49
MatthTheGeek  
 
normal  
new 3.7.0 RC2  
open  
none    
none  
   
EFF/DDS corruption on cbanis
Memory corruption on the linked CBAnim (provided in a minimal retail-based mod folder and a test mission for convenience) - http://www.mediafire.com/?gh8gwy4m2p33dc8

This CBAni is an EFF using DDS files. It comes from WCS. Trying to run it on a release build causes a crash. Running it on a debug build causes what is shown on the attached screenshot.

After testing multiple FSO versions I have narrowed it down to somewhere between .14 RC7 and RC8 (works on RC7, doesn't work on RC8).

According to The_E, the same CBAni works fine when the files are converted to png.
fs2_open_3_7_1_SSE2_BP-DEBUG 2013-08-18 14-58-54-34.png (592,345 bytes) 2013-08-18 09:02
http://scp.indiegames.us/mantis/file_download.php?file_id=2255&type=bug
 
Notes
(0015255)
niffiwan   
2013-08-30 05:49   
I think the bug was introduced in r9109:

Allow generic_anim's to reuse bmpman and texture_cache slots and implement eff streaming. Changed talking heads to use generic_anim. Fixes Mantis 2417




View Issue Details
2909 [FSSCP] graphics feature always 2013-08-14 10:20 2013-08-14 10:20
Triikor  
Windows 7  
normal  
new  
open  
none    
none  
   
homeworld hyperspace anim/warp
ok well according to The E this is a bug in FSO's graphics memory management, so basically the Homeworld warp type doesn't work right now which since I'm doing a Homeworld mod, yeah...so I attached a little mod that has the heavy cruiser warping in. Glow map texture is being applied to the warp effect for whatever reason.
Well any the ships that I've ported that use the $Warpin Type: Homeworld and $Warpout Type: Homeworld stuff have this issue so just put that on a ship and watch it warp
HWwarpbug.rar (664,890 bytes) 2013-08-14 10:20
http://scp.indiegames.us/mantis/file_download.php?file_id=2253&type=bug
 
There are no notes attached to this issue.




View Issue Details
2895 [FSSCP] Build system minor N/A 2013-06-29 08:37 2013-06-29 08:37
Firewave  
chief1983  
normal  
assigned 3.7.0 RC2  
open  
none    
none  
   
clang compiler warnings
These are the remaining clang 3.3 compiler warning with 3.7.0 RC2 after applying the patch submitted in issue 2894:

cfile/cfilesystem.cpp: In function ‘void cf_search_root_pack(int)’:
cfile/cfilesystem.cpp:673:45: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result [-Wunused-result]
cfile/cfilesystem.cpp:693:41: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result [-Wunused-result]
cmdline/cmdline.cpp: In function ‘void os_init_cmdline(char*)’:
cmdline/cmdline.cpp:785:24: warning: ignoring return value of ‘char* fgets(char*, int, FILE*)’, declared with attribute warn_unused_result [-Wunused-result]
cmdline/cmdline.cpp:823:24: warning: ignoring return value of ‘char* fgets(char*, int, FILE*)’, declared with attribute warn_unused_result [-Wunused-result]
globalincs/version.cpp: In function ‘int version_compare(char*, int*, int*, int*, int*, int*, int*)’:
globalincs/version.cpp:59:36: warning: ignoring return value of ‘char* fgets(char*, int, FILE*)’, declared with attribute warn_unused_result [-Wunused-result]
graphics/gropengldraw.cpp: In function ‘void opengl_scene_texture_shutdown()’:
graphics/gropengldraw.cpp:2370:26: warning: the address of ‘Distortion_texture’ will always evaluate as ‘true’ [-Waddress]
graphics/gropengltnl.cpp: In function ‘void gr_opengl_render_stream_buffer(int, int, int)’:
graphics/gropengltnl.cpp:1323:6: warning: variable ‘zbuff’ set but not used [-Wunused-but-set-variable]
hud/hud.cpp: In member function ‘virtual void HudGaugeTextWarnings::render(float)’:
hud/hud.cpp:2390:51: warning: the address of ‘Hud_text_flash’ will always evaluate as ‘true’ [-Waddress]
hud/hudparse.cpp: In function ‘void load_gauge_primary_weapons(int, int, int, SCP_vector<int>*, color*)’:
hud/hudparse.cpp:8326:57: warning: ‘base_res[1]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
hud/hudparse.cpp:8326:57: warning: ‘base_res[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
hud/hudparse.cpp: In function ‘void load_gauge_secondary_weapons(int, int, int, SCP_vector<int>*, color*)’:
hud/hudparse.cpp:8519:57: warning: ‘base_res[1]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
hud/hudparse.cpp:8519:57: warning: ‘base_res[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
io/keycontrol.cpp: In function ‘void ppsk_hotkeys(int)’:
io/keycontrol.cpp:1289:61: warning: suggest parentheses around ‘+’ in operand of ‘&’ [-Wparentheses]
model/modelread.cpp: In function ‘int model_load(char*, int, model_subsystem*, int, int)’:
model/modelread.cpp:2495:2: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
network/multiutil.cpp: In function ‘void dcf_multi()’:
network/multiutil.cpp:3240:8: warning: variable ‘new_flags’ set but not used [-Wunused-but-set-variable]
network/multi_team.cpp: In function ‘void multi_team_report()’:
network/multi_team.cpp:591:73: warning: array subscript is above array bounds [-Warray-bounds]
parse/parselo.cpp: In function ‘void vsprintf(SCP_string&, const char*, __va_list_tag*)’:
parse/parselo.cpp:3690:20: warning: ‘char’ is promoted to ‘int’ when passed through ‘...’ [enabled by default]
parse/parselo.cpp:3690:20: note: (so you should pass ‘int’ not ‘char’ to ‘va_arg’)
parse/parselo.cpp:3690:20: note: if this code is reached, the program will abort
weapon/weapons.cpp: In function ‘int weapon_create(vec3d*, matrix*, int, int, int, int, int, float, ship_subsys*)’:
weapon/weapons.cpp:4943:70: warning: operation on ‘* position’ may be undefined [-Wsequence-point]
 
There are no notes attached to this issue.




View Issue Details
2890 [FSSCP] SEXPs minor always 2013-06-06 18:09 2013-06-06 23:39
FUBAR-BDHR  
 
normal  
new 3.6.19  
open  
none    
none  
   
Inconsistent behavior in set-object-speed-z
At one time you could use this sexp to set a ships speed and based on the optional argument make a ship fly as fast as you wanted. The problem was that this only worked for 1 frame and the ship would quickly return to normal speed. The easy workaround was to put the sexp in a loop. This no longer works breaking older missions. The ship will show on the hud that it is moving at the velocity given in the sexp but does not appear to change the speed of the ship at all. For example the following event:

$Formula: ( every-time
   ( true )
   ( set-object-speed-z
      "EA Aurora 1"
      500
      ( true )
   )
)
+Name: Event name
+Repeat Count: 9999
+Interval: 1

In previous releases would make the ship fly at a velocity of 500. In current builds it just flys at default speed but when targeted the speed it is traveling at is indicated as being 500.

There is also a second issue here. Even with the ship traveling at normal speed weapon impacts seem to be based off of the 500 speed as well causing the ship to jump around when hit.
Run the attached mission in a current and older build such as 3.6.10. For the second part shoot the ship and watch it jump when hit which doesn't happen if the event is not present.
The first part of the bug was actually discovered by someone else and discussed on IRC. I thought a bug report had been filed but couldn't fine one. Here is the log of that conversation:

[05/09-02:04] <Doko> I'm having an issue with set-object-speed-Z. I have a ship aligned to fred's world axis and I'm specifing for the sexp to utilize the ships orientation (either true or false should achieve the same with its current heading) but it just refuses to move. The hud displays the ship moving at 20m/s but its not actually moving in space. X and Y works correctly moving the ship sideways or up down
[05/09-02:04] <Doko> am I understanding this sexp wrong or is something broken here
[05/09-02:08] <@The_E> Sure sounds like brokenness to me
[05/09-02:11] <Doko> hmmm the sexp doesn't seem to be broken per say. If I pitch the ship down 90 degrees and it to false the ship moves correctly. Its like if forward speed was protected... odd
[05/09-02:14] *** Plombo_ has quit IRC: Ping timeout: 194 seconds
[05/09-02:27] <FUBAR> set the optiona argument to true and make it a repeating event. If it's not repeating it will only move for 1 frame
[05/09-02:28] <Doko> It was hooked on a everytime var = 1
[05/09-02:29] <Doko> also tried with a when with a speed of 4000 to see if it would move that much in 1 frame
[05/09-02:29] <Doko> also tried with it set to false, still refuses
[05/09-02:39] <FUBAR> yea definately a bug. Targeted ship shows a speed of 500 but is moving at normal speed
[05/09-02:40] <Backslash> Doko, FUBAR, not a bug. long explanation incoming:
[05/09-02:40] * Doko listens
[05/09-02:41] <Backslash> short version: it is fixed by use-newtonian-damping (been a long time, might have the spelling wrong)
[05/09-02:41] <FUBAR> when was the behavior changed because it used to work with retail data
[05/09-02:42] <Backslash> it never worked with completely retail data
[05/09-02:42] <Backslash> basically, for some reason the engine doesn't apply damping to the ship's Z axis, it instantly goes to 0. So no matter what velocity you give Z, the very next frame it is instantly decreased to 0
[05/09-02:42] <FUBAR> it did if it was in a loop
[05/09-02:42] <Backslash> when I say 'for some reason' I mean I can see why in the code, I just don't know why [V] decided to do it that way
[05/09-02:43] <Backslash> once upon a time I attempted to fix it by applying damp to all three axes, but it was determined that since it was not done in retail, I had to make it optional
[05/09-02:43] <FUBAR> to prevent ships from flying off at light speed after collisions would be my guess (althogh player ships still did it)
[05/09-02:44] <Backslash> possibly, but that doesn't happen if the $damp value is set properly
[05/09-02:45] <FUBAR> apparently you've never been hit by a hecate jumpin in in RI and ended up 500000k away
[05/09-02:45] <Backslash> oh I have
[05/09-02:45] <Backslash> but that can happen on the X or Y axis too
[05/09-02:45] <FUBAR> still there is definatly a bug here becasue the speed is showing the set speed in the targeting window not the actual speed
[05/09-02:46] <Backslash> it is showing the set speed before physics happens, yes
[05/09-02:46] <Backslash> I wish there was a way to fix it. perhaps there is, it would be very nice
[05/09-02:46] <Backslash> this is also why in BtRL if you constantly turn your ship, your speed will continually increase
[05/09-02:47] <Backslash> cause as you turn, damp keeps your momentum on X (or Y), but Z gets instantly set to whatever your engine speed is... which then gets added to X's momentum as you continue to turn
[05/09-02:47] <BotenAnna> oh snap!
[05/09-02:47] <Backslash> rofl, your momentum
[05/09-02:47] <BotenAnna> oh snap!
[05/09-02:47] <Doko> lol
[05/09-02:48] <FUBAR> what I don't understand is if it the original behavior with retail data was to accelerate and immediately decelerate why the behavior was changed from that. I can see leaving it set with a flag but not beaking the old behavior. It was used frequently to make ships go faster then they should.
[05/09-02:48] <Backslash> I have not seen it working with retail data. I would be quite interested to see what build that worked with, because precedent would be nice
[05/09-02:50] <Backslash> it makes me sad, really, because I feel ships 'feel' more interesting with my fix
[05/09-02:50] <Backslash> set the damp high enough and you can do some fun afterburner slides
[05/09-02:51] <FUBAR> god can I test one thing without finding a bug or 2?
[05/09-02:52] <FUBAR> Just save the mission in retail format which didn't remove the fog multipliers so it doesn't work in older versions
[05/09-02:52] <FUBAR> Also it appears that the new pilot code may be showing all missions for campaings in the tech room before they are played.
[05/09-02:53] <Backslash> you are quite talented at bugfinding
[05/09-02:54] <FUBAR> it's getting annoying all I wanted to do was check some sound files last night and I'm on like bug 0000004 now
[05/09-02:55] <Backslash> was the 'save the mission in retail format' directed at me about the set-object-speed, or was that about another bug?
[05/09-02:55] <FUBAR> I found that testing the set-object-speed just now
[05/09-02:56] <FUBAR> and add +use table score to not being removed from retail save
[05/09-02:56] <Backslash> heh
[05/09-02:57] <FUBAR> got a uly moving at 630 in 3.6.9
[05/09-02:58] <FUBAR> guessing that is 500+velocity_ab
[05/09-02:58] <Backslash> 3.6.9 release?
[05/09-02:58] <FUBAR> looks that way has no revison after it and no debug
[05/09-02:59] <FUBAR> newer then rc8 older then 3.6.10
[05/09-02:59] <FUBAR> older then a 3.6.9 xt build too but that doesn't really mean anything
[05/09-02:59] <Backslash> nice. can I get the mission somewhere?
[05/09-03:00] <Backslash> there was a VERY short period of time where my fix was in trunk, but that got reverted when taylor noticed the difference from retail.
[05/09-03:00] <Backslash> it's actually just about unnoticable with retail data EXCEPT for big ships warping in.
[05/09-03:01] <FUBAR> (Link: http://fubar5.fubar.org/mantis/500speed.fs2)http://fubar5.fubar.org/mantis/500speed.fs2
[05/09-03:01] <Backslash> thanks
[05/09-03:01] <FUBAR> now I didn't disable the AI so it moves weird
[05/09-03:01] <FUBAR> by disable I mean play-dead
[05/09-03:02] <Backslash> is fine
[05/09-03:02] <FUBAR> just letting you know before you wonder why it's doing spirals
500speed.fs2 (3,005 bytes) 2013-06-06 18:09
http://scp.indiegames.us/mantis/file_download.php?file_id=2223&type=bug
 
Notes
(0015122)
Backslash   
2013-06-06 23:39   
Yeah, like I said above, I'm wondering if 3.6.9 was the short period of time I mentioned, or possibly the 3.6.9 build you had was not a release build. IIRC that was the era of CVS and before we had standardized proper build naming. You sure it didn't happen in 3.6.8?

Is there somewhere we keep old release builds like that?

Either way, unless it happens in builds like 3.6.8 and earlier, the only missions it breaks is ones that were developed under just 3.6.9 ... and really, all they need to be fixed is http://hard-light.net/wiki/index.php/Ai_profiles.tbl#.24use_newtonian_dampening: anyway. I do wish there was a better way to fix it for everyone. This and the BtRL turning behavior that results without is just stupid.




View Issue Details
1815 [FSSCP] multiplayer major sometimes 2008-11-10 22:33 2013-06-05 23:37
FUBAR-BDHR  
Goober5000  
normal  
assigned 3.6.9  
reopened  
none    
none  
   
Player AI ships do not initally attack on standalone
Been trying to figure this one out for awhile now. Sometimes the player AI ships just sit there at the start of a mission and basically let themselves be slaughtered. If given an order or they respawn they start behaving normally. I do not believe this behavior is happening during normal hosting.
Have notice in both TBP and FS2. Last noticed in Taylor's multi_test build dated 11/09. Attaching screen shot of them still sitting there in initial formation 1:15 into the mission. This was in M-01b.
screen0027.jpg (55,881 bytes) 2008-11-10 22:33
http://scp.indiegames.us/mantis/file_download.php?file_id=1143&type=bug
jpg
 
Notes
(0010175)
taylor   
2008-11-10 23:16   
I noticed this during testing a couple of weeks ago. It only happened once though, and I couldn't reproduce it, so I thought it was some weird fluke related to what I was working on at the time. I'll try and reproduce it again this weekend during testing and see if I can't track it down.
(0010242)
karajorma   
2008-11-20 15:05   
Does this one still occur now that I've changed the way initial orders work?
(0010245)
FUBAR-BDHR   
2008-11-20 19:25   
Yep. Just tried a quick run using the latest Knightly build (4955). AI just sat there doing nothing with a cap right in front of them. Even when the fighters arrived they sat there. Both BDHR standalones are running that build now.
(0010493)
karajorma   
2008-12-30 16:28   
I forgot that the changes I made last time would be carried out on the host, not the server. That means I need to include a change that may fix this bug. If it doesn't I'll take another look at it.
(0010504)
karajorma   
2009-01-04 07:03   
And another change, as soon as SVN is back up I'll commit it.
(0010508)
FUBAR-BDHR   
2009-01-05 18:12   
(Last edited: 2009-01-05 22:04)
So far I only tested the standalone not attacking part of the bug. It's still there. Fired up M01b and the AI just sat there. I even drew the enemy fighters withing 200 of them and nothing. In that mission the AI don't have any initial orders. Haven't tried any missions where the fighters actually have initial orders. I'll test that out tonight.

Just checked out the fix for 1633 and it seems to work just fine. Turns that TBP ground attack mission into a whole new ballgame.

(0010509)
karajorma   
2009-01-07 10:02   
So this one is fixed now? Or is there still an issue with stand alones?
(0010510)
FUBAR-BDHR   
2009-01-07 14:58   
Still an issue with the standalone but it's not an issue with initial orders. Normally a player AI ship with no orders will do whatever a normal AI would do. In most cases engage the enemy. For some reason they don't do that on a standalone they just either sit there or fly formation even when being shot at. When they respawn they return to normal behavior.

I'm wondering if there is some kind of timing issue where things like this and that arrival cue from that RI bug report don't get processed at mission start due to lag.
(0010549)
Goober5000   
2009-01-19 19:56   
(Last edited: 2009-01-19 19:56)
I wonder if this is related to the form-on-wing change. Try a recent build.

(0010552)
FUBAR-BDHR   
2009-01-19 20:39   
How recent? Already built or next Knightly?
(0010555)
Goober5000   
2009-01-19 21:14   
The most recent nightly build should have the fix.
(0010557)
FUBAR-BDHR   
2009-01-19 22:08   
Just tried r5045 and still the same behavior.
(0010626)
karajorma   
2009-01-31 12:10   
I tried it and noticed the same behaviour on both Standalone and normal multiplayer. The AI ships circle around in both for about a minute and then fly in to attack. In fact I actually had them attack more quickly on the standalone the first time.

If you fly towards the Moloch then the AI attack. Could this be the cause of the discrepancy you saw? Are you certain this isn't the default retail behaviour? I'll give the mission a try in FS2 but either both standalone and hosted server are doing the same thing now or it was simply a peculiarity of the fact that the ships in M1b don't appear to have initial orders from their behaviour (don't have a VP editor on this machine at the moment so I can't verify that).
(0010627)
karajorma   
2009-01-31 13:15   
Okay. Reverting Goober's revision 4958 seems to fix this and restore retail behaviour. I think I'll have to have a word with Goober over it.
(0010628)
karajorma   
2009-01-31 14:30   
Nope. It appears that this bug is intermittent and it merely happened to fix itself when I tried that.
(0010646)
Wanderer   
2009-02-03 14:34   
Looking at the code this seems to be some thing of an odd case. Problem seems to be caused by having ships without any goals or default orders in the mission while the actual target ship is just beyond the 'engagement limit' of the fighters (seemingly odd distances possibly due random checkup times, use of vm_vec_mag_quick and bbox).

Not sure if this actually is a bug or not.
(0010647)
FUBAR-BDHR   
2009-02-03 16:56   
Well no mission should play differently on a standalone then on a regular server. That and it's not retail behavior. Either one of those should be enough for it to be classified as a bug.

Wouldn't be near as bad if they would fight back when attacked. I've watched an entire wing get wiped out without taking evasive action of firing a shot in return. It's almost like the server doesn't even know they are AI ship until after respawn.
(0013887)
Goober5000   
2012-07-25 00:08   
Try RC7 and see if that fixes it. It rolls back revision 2170 (referenced by r4958) which was a small deviation from the retail behavior of wings.
(0014539)
Goober5000   
2012-12-19 00:48   
Bump for another test.
(0014546)
FUBAR-BDHR   
2012-12-19 22:58   
Just tried m-02b and while the ships didn't just sit in one place they didn't try to attack the enemy ships or even shoot. Just kind of flew at initial speed.
(0015101)
karajorma   
2013-05-31 04:11   
Fix committed to trunk@9683.
(0015102)
karajorma   
2013-05-31 04:24   
Committing the fix for 1863 appears to have closed this one automatically too. Can we confirm if it is actually fixed or not please?
(0015121)
FUBAR-BDHR   
2013-06-05 23:37   
Appears that this did not fix the issue. Started up a M-02b and the friendly AI just kind of sat around and got shot at still.




<
View Issue Details