[AV8R]

Hey All,

FSO Inventory:
FSO: 3.6.18
FSPort: 3.4
MVPs: 3.6.12

I'm having some strange things happen when I run FSPort 3.4 and play some of the original single missions. It seems when I first start FSO and start a mission (like "Loner" for example) the first time I play through with the skill level set on Easy, my wingmates seem to be very lacsidasical in their engagement - often getting whacked by the Shivans or the HOL ships quite readily - which shouldn't happen on Easy. If I move over to another mission (such as Order of the Eye), the same thing happens. After giving the "Engage Enemy" command I've later seen some fighters just sitting in space doing nothing and unless tell their wing to do something, they'll end up being canon-fodder for the enemy. Also I'll have to keep reminding them to press an attack (on a cruiser, for example) or they'll just move onto something else/get distracted after a minute or so, or worse, even ignore my orders (ie: I tell a wing to ignore a target and they'll attack it anyway!).

Now if I exit from the program and the launcher and re-enter FSO and play the same mission, it seems to work better - wingmen are on point and get the job done without nagging - it's like night and day. I've gotten into the habit of starting FSO after a fresh boot and starting a mission, exiting out, restarting FSO and restarting the mission to get the AI to react correctly. Very odd.

Another issue is with secondaries. The missions seems to remember the ships and secondaries I chose last time I played but doesn't reset them when starting the mission. While convenient, this has the side effect of ending up with negative numbers for missiles (-200 Hornets!) and having to hit the reset button to fix the condition and reassign primaries/secondaries.

So, as a test, I tried rebooting and started FSPort 3.4 in Debug mode and started "Loner" again (this time the missile counts were OK), but when I hit Commit FSPort crashed to the desktop with the following error:

For asteroid 'Small Asteroid', detail level
mismatch (POF needs 3)
ntdll.dll! KiFastSystemCallRet
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_18_DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_6_18_DEBUG.exe! Warning + 416 bytes
fs2_open_3_6_18_DEBUG.exe! asteroid_load + 424 bytes
fs2_open_3_6_18_DEBUG.exe! asteroid_create_all + 311 bytes
fs2_open_3_6_18_DEBUG.exe! game_post_level_init + 80 bytes
fs2_open_3_6_18_DEBUG.exe! game_start_mission + 373 bytes
fs2_open_3_6_18_DEBUG.exe! game_enter_state + 464 bytes
fs2_open_3_6_18_DEBUG.exe! gameseq_set_state + 310 bytes
fs2_open_3_6_18_DEBUG.exe! game_process_event + 242 bytes
fs2_open_3_6_18_DEBUG.exe! gameseq_process_events + 152 bytes
fs2_open_3_6_18_DEBUG.exe! game_main + 782 bytes
fs2_open_3_6_18_DEBUG.exe! WinMain + 330 bytes
fs2_open_3_6_18_DEBUG.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_6_18_DEBUG.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 239 bytes
ntdll.dll! RtlInitializeExceptionChain + 194 bytes

Attached is the log file for your enjoyment. I'm not so much concerned with the Asteroid error as much as I'm concerned about the AI behavior.

BTW, I'm getting this with a fresh pilot file. Anything you guys would suggest?

[attachment deleted by ninja]

[niffiwan]

The AI thing sounds very odd.  The FSO AI state should be reset every time you start FSO, so I would have thought that restarting would have no effect.  Would it be correct to say the AI does not work correctly the 1st time you play mission, when that mission is not the 1st one played in a session? i.e.

1) start FSO & play campaign mission, AI works OK
2) advance to next mission, AI does not work
3) exit FSO - go to step 1, except you're now playing the mission from step 2?

Another issue is with secondaries. The missions seems to remember the ships and secondaries I chose last time I played but doesn't reset them when starting the mission. While convenient, this has the side effect of ending up with negative numbers for missiles (-200 Hornets!) and having to hit the reset button to fix the condition and reassign primaries/secondaries.

The negative weapon counts bug & some other bugs concerning the saved loadout have been resolved in 3.7.0 RC2.

So, as a test, I tried rebooting and started FSPort 3.4 in Debug mode and started "Loner" again (this time the missile counts were OK), but when I hit Commit FSPort crashed to the desktop with the following error:

[snip]

Attached is the log file for your enjoyment. I'm not so much concerned with the Asteroid error as much as I'm concerned about the AI behavior.

BTW, I'm getting this with a fresh pilot file. Anything you guys would suggest?

I don't recall seeing that crash before, can you reproduce it with 3.7.0 RC2 (note that this has a new pilot format, the conversion process may cause your pilot to lose their stats)

[AV8R]

Thanks for the reply, Niffiwan. Actually, my issue is just the opposite of the example you gave:

1) After fresh reboot, start FSO and start a mission  (in my example, an FSPort single simulator mission) - AI is flaky and doesn't behave right.
2) Go to another mission, more of the same.
3) Exit FSO and Launcher. Restart launcher, FSO and mission.
4) AI behaves normally.

I will try 3.7 RC2 to see if missile counts and crash still happens. Maybe it will take care of the AI issue too?

Do I have to create another new pilot file? (Stats don't matter - these are new pilot files anyway).

[niffiwan]

Thanks for the reply, Niffiwan. Actually, my issue is just the opposite of the example you gave:

1) After fresh reboot, start FSO and start a mission  (in my example, an FSPort single simulator mission) - AI is flaky and doesn't behave right.
2) Go to another mission, more of the same.
3) Exit FSO and Launcher. Restart launcher, FSO and mission.
4) AI behaves normally.

Well.   Colour me x10

I will try 3.7 RC2 to see if missile counts and crash still happens. Maybe it will take care of the AI issue too?

Do I have to create another new pilot file? (Stats don't matter - these are new pilot files anyway).

It might help the AI issue, but I'm not sure.  No harm in trying

You don't have to create a new pilot for 3.7.0 RC2, FSO will attempt to convert your old pilots when it starts.

[AV8R]

Seems others have complained of complacent AI before (especially AI blindly ramming or bumping into ships, etc). So it's not only is the enemy AI getting flaky, it's the friendly AI too. Maybe they're starting a union behind our backs and going on strike? 

Anyway, I'll install 3.7 RC2, create fresh pilot files, reboot and report what I find.

[AV8R]

Ok, after downloading/installing 3.7 RC2, deleting old pilot files, creating a new one and rebooting, here's the deal:

1) Using 3.7 debug and then loading FSPort 3.4 and one of the single missions (Loner) crashes to the desktop:

For asteroid 'Small Asteroid', detail level
mismatch (POF needs 3)
ntdll.dll! KiFastSystemCallRet
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! Warning + 416 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! asteroid_load + 424 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! asteroid_create_all + 311 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! game_post_level_init + 80 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! game_start_mission + 373 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! game_enter_state + 550 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! gameseq_set_state + 310 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! game_process_event + 242 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! gameseq_process_events + 152 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! game_main + 782 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! WinMain + 330 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_7_0_RC2-DEBUG.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 239 bytes
ntdll.dll! RtlInitializeExceptionChain + 194 bytes

2) When running 3.7 RC2 (non-debug), AI seems more consistent (if I run a mission until the end, exit and rerun without rebooting I get roughly consistent outcomes).

3) Secondaries seem to reset properly before the mission now so there are no more negative missile counts.

Debug log is attached again, but it'll probably read the same. I don't know if FSPort or FSO is causing the asteroid crash.

Let me know if I can test anything else for you guys.

[attachment deleted by ninja]

[The E]

Code: [Select]

For asteroid 'Small Asteroid', detail level
mismatch (POF needs 3)
ntdll.dll! KiFastSystemCallRet
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_18_DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_6_18_DEBUG.exe! Warning + 416 bytes
fs2_open_3_6_18_DEBUG.exe! asteroid_load + 424 bytes
fs2_open_3_6_18_DEBUG.exe! asteroid_create_all + 311 bytes
fs2_open_3_6_18_DEBUG.exe! game_post_level_init + 80 bytes
fs2_open_3_6_18_DEBUG.exe! game_start_mission + 373 bytes
fs2_open_3_6_18_DEBUG.exe! game_enter_state + 464 bytes
fs2_open_3_6_18_DEBUG.exe! gameseq_set_state + 310 bytes
fs2_open_3_6_18_DEBUG.exe! game_process_event + 242 bytes
fs2_open_3_6_18_DEBUG.exe! gameseq_process_events + 152 bytes
fs2_open_3_6_18_DEBUG.exe! game_main + 782 bytes
fs2_open_3_6_18_DEBUG.exe! WinMain + 330 bytes
fs2_open_3_6_18_DEBUG.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_6_18_DEBUG.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 239 bytes
ntdll.dll! RtlInitializeExceptionChain + 194 bytes
le sigh

This is a warning, NOT A CRASH. You can click through it. Yes, it is annoying. Yes, I argued against this being anything more than a log warning. Yes, I was overruled.

[Fury]

This is a warning, NOT A CRASH. You can click through it. Yes, it is annoying. Yes, I argued against this being anything more than a log warning. Yes, I was overruled.

It'd be nice if FSO and FRED were consistent with what messages pop-ups when it detects a problem. Warnings should never cause a pop-up because they shouldn't stop you from playing the game anyway. If it does, perhaps it should be an error and not a warning. Any competent modder would (at least should) go through debug logs to ensure the mod is bug-free, displaying warning pop-ups only serves as a major headache for players and modders alike attempting to generate debug logs.

And as evidenced here, also can be taken as incorrect assumption of a crash or major game-breaking bug. Silly gooses those SCP devs.

[niffiwan]

It's funny that the behaviour is different on other platforms.  On Linux (& maybe OSX?), warnings don't create a popup, they just dump a message to STDOUT & the log.  Windows should probably do something similar 

[FUBAR-BDHR]

And if you don't pop up those warnings then you end up with mods and TC's releasing with bad data. 

[niffiwan]

yeah, I thought it over some more (I shouldn't post when I'm in a hurry), we've already got Error (fatal) > Warning (no warrantee) > Log (FYI).  No need to "nerf" the warnings, it's just in this case (when even retail data triggers this warning) it should probably be a Log instead. 

[Fury]

And if you don't pop up those warnings then you end up with mods and TC's releasing with bad data. 

Modders should always analyze debug logs as part of development process. If they don't, then they are bad modders.

I'd go as far as to hide actual error messages in debug and retail build pop-ups. When retail build encounters a problem, it displays only one message which says "Unrecoverable error encountered. Please run debug build or contact developer." Debug build in turn displays "Unrecoverable error encountered. Please see generated debug log for details or contact developer." Unrecoverable pop-up would only have terminate button.

As for problems that are recoverable, just swap "Unrecoverable" with "Recoverable" and you're good to go. This prompts developers to actually do their work properly and analyze debug logs. And this does it without bombarding anyone who tries to generate a debug log with various cryptic pop-ups. Recoverable pop-up would have continue and terminate buttons. Either the game finishes loading or encounters unrecoverable error, which would be the only case where'd you get two pop-ups. You would only get one recoverable error pop-up no matter how many were encountered.

[FUBAR-BDHR]

yeah, I thought it over some more (I shouldn't post when I'm in a hurry), we've already got Error (fatal) > Warning (no warrantee) > Log (FYI).  No need to "nerf" the warnings, it's just in this case (when even retail data triggers this warning) it should probably be a Log instead. 

Yea unfortunately this is a case where the code for the warning had a bug  probably since retail so didn't catch those either.   Like the old null moi warning it will just take some time before the mods get fixed but they should be fixed.  The few retail ones we'll just have to live with along with the slew of other retail warnings and bugs.     

[AV8R]

le sigh

This is a warning, NOT A CRASH. You can click through it. Yes, it is annoying. Yes, I argued against this being anything more than a log warning. Yes, I was overruled.

Thanks for the clarification.

But speaking as a non-developer (yet an IT Systems Analyst who knows the Windows platform very well), when you get dumped to the desktop and get a dialog box with negative information it says "crash" all over it. We all know that's normal Windows behavior (that fact you were overruled about how this "warning" gets displayed is dissappointing and leaves those who are not "in the know" here assuming that this to something it's not just by its behavior). Sure I could see there were other options to proceed and what not, but kicked to desktop +dialog has always equalled crash to me in the Windows troubleshooting world - as would most people. But now I know.

I'll keep testing 3.7 to see if the strange AI "retardation after bootup" continues or improves - it seemed better last night, but that was 1am and details are sketchy now.   

Also, I understand 3.7 has the new pilot code which makes the pilot file cross-mod compatible, correct? (one pilot file will work with most mods, like FSPort, FS2 and ST-R without having to makes seperate pilot files for each, right?). I'll check how well this works too and report any issues I may come across.

Thanks for everyone's input.

[Phantom Hoover]

I'm guessing The E pointed out all of those things.

[AV8R]

Ok, the lowered-IQ AI on first run phenomenon is no longer occuring - the pilots seem to be behaving as they should with the 3.7 RC2 exe.

Also the cross-mod pilot code seems to work well too - it's nice to be able to set all of your options/controls once and have the settings follow you into each mod. Very cool.

The only drawback is you have to change campaigns when switching between mods (i.e.: if you exit FSPort and go into FS2Open, you have to go to the campaign room when entering the FS2Open main hall as it'll say it can't find the current campaign). I guess it depends under which mod you create the pilot - whichever mod you create it under becomes the default campaign and if you open that mod no questions are asked but if you switch to another mod you have to select the campaign. Oh well, small price to pay.

[niffiwan]

The only drawback is you have to change campaigns when switching between mods (i.e.: if you exit FSPort and go into FS2Open, you have to go to the campaign room when entering the FS2Open main hall as it'll say it can't find the current campaign). I guess it depends under which mod you create the pilot - whichever mod you create it under becomes the default campaign and if you open that mod no questions are asked but if you switch to another mod you have to select the campaign. Oh well, small price to pay.

This happens when FSO can't find the pilots currently active campaign file (.fc2), which is normally the case when you switch mods.  If you change your campaign to one common to both mods (e.g. Freespace2 in some mods) before exiting FSO & switching mods, then this popup shouldn't appear.

[AV8R]

I dunno, I'm getting a different outcome.

I tested my theory by deleting all pilots and opening FSOpen (FS2) and creating a new pilot. I then entered FSPort (FS1) with the same new pilot and checked the settings. The campaign correctly defaulted to FreeSpace 1. When I went back into FSOpen (FS2) it again asked me choose a campaign, so I changed it to FreeSpace 2. I then exited FSOpen completely and went immediately back into FSOpen but this time I wasn't prompted to choose a campaign.

So I went back to into FSPort and I was not prompted to choose a campaign even though I had just set it to FS2 in FSOpen with the same pilot file. When I checked in the campaign room, the campaign was correctly set to FS1. So one more time I exited FSPort, entered FSOpen and was again prompted to choose a campaign.

For some reason, using a single pilot file between FSPort and FSOpen favors the campaign defaulting to FS1. Now, if you only enter FSOpen (FS2) the campaign will always stay set to FreeSpace 2 in the campaign room. But the minute you enter FSPort, the campaign will set itself back to FreeSpace 1 automatically and stay there until you open FSOpen again a reset the campaign back to FreeSpace 2 manually in the campaign room.

Perhaps there is something in the code of FSPort that automatically sets the campaign accordingly to FreeSpace 1 when you enter the mod? That being said, could this be done in FSOpen (where it defaults to the FreeSpace 2 campaign automatically?)

[niffiwan]

What you've said sounds like the behaviour I'd expect.  Fsport has a setting to make the Freespace (1) campaign the default (I didn't mention or account for this setting in my previous post). Since this is a new setting in FSO 3.6.18, retail Freespace2 doesn't set it, neither have the mediavps had a release since the setting was added.  If you were to run tests with an older mod, I believe the behaviour would be more like what I described, i.e. every time you switch to a new mod without the Freespace2 campaign selected, you'll be prompted that the current campaign can't be found.  e.g. switch between Vassago's Dirge & Transcend while selecting the mods campaign each time.

As for defaulting to the Freespace2 campaign any time a campaign can't be found, until recently you couldn't stop the Freespace2 campaign from being available in a mod, and some mods break the Freespace2 campaign.  So I don't think always defaulting to it is a good idea, and anyway, the problem will probably diminish as more mods release updates to include the "default campaign" setting.