[Wet Orange Ostrich Toilet]

I get this strange error whenever I try to boot up FRED. Can anyone help me with it?

Unknown lookup_type in stuff_int_list
ntdll.dll! ZwWaitForSingleObject + 12 bytes
KERNELBASE.dll! WaitForSingleObject + 18 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! SCP_DumpStack + 354 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! Error + 284 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! stuff_int_list + 557 bytes
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
fred2_open_3_7_4_SSE2-DEBUG.exe! parse_ship_values + 11396 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! parse_ship + 938 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! parse_shiptbl + 444 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! parse_modular_table + 331 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! ship_init + 464 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! fred_init + 825 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CFREDView::OnCreate + 103 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CWnd::OnWndMsg + 2634 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CWnd::WindowProc + 68 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! AfxCallWndProc + 267 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! AfxWndProc + 181 bytes
USER32.dll! SetManipulationInputTarget + 83 bytes
USER32.dll! DispatchMessageW + 2298 bytes
USER32.dll! DispatchMessageW + 1328 bytes
USER32.dll! InSendMessageEx + 176 bytes
ntdll.dll! KiUserCallbackDispatcher + 54 bytes
USER32.dll! CreateWindowExW + 409 bytes
USER32.dll! CreateWindowExA + 56 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! IsolationAwareCreateWindowExA + 198 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CWnd::CreateEx + 367 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CWnd::Create + 239 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CFrameWnd::CreateView + 422 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CFrameWnd::OnCreateClient + 45 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CFrameWnd::OnCreateHelper + 82 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CFrameWnd::OnCreate + 119 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CMainFrame::OnCreate + 55 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CWnd::OnWndMsg + 2634 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CWnd::WindowProc + 68 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! AfxCallWndProc + 267 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! AfxWndProc + 181 bytes
USER32.dll! SetManipulationInputTarget + 83 bytes
USER32.dll! DispatchMessageW + 2298 bytes
USER32.dll! DispatchMessageW + 1328 bytes
USER32.dll! InSendMessageEx + 176 bytes
ntdll.dll! KiUserCallbackDispatcher + 54 bytes
USER32.dll! CreateWindowExW + 409 bytes
USER32.dll! CreateWindowExA + 56 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! IsolationAwareCreateWindowExA + 198 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CWnd::CreateEx + 367 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CFrameWnd::Create + 270 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CFrameWnd::LoadFrame + 337 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CDocTemplate::CreateNewFrame + 407 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CSingleDocTemplate::OpenDocumentFile + 436 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CSingleDocTemplate::OpenDocumentFile + 43 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CDocManager::OnFileNew + 361 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CWinApp::OnFileNew + 45 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! CFREDApp::InitInstance + 2028 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! AfxWinMain + 174 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! WinMain + 24 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! invoke_main + 30 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! __scrt_common_main_seh + 346 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! __scrt_common_main + 13 bytes
fred2_open_3_7_4_SSE2-DEBUG.exe! WinMainCRTStartup + 8 bytes
KERNEL32.DLL! BaseThreadInitThunk + 36 bytes
ntdll.dll! RtlSubscribeWnfStateChangeNotification + 1081 bytes
ntdll.dll! RtlSubscribeWnfStateChangeNotification + 1028 bytes

[The E]

Does FSO 3.7.4 start normally?
Does 3.8RC1 start normally?

That error is impossible to hit, unless something very very weird is happening (as in, some sort of memory corruption: stuff_int_list is never called such that the lookup list type parameter is computed; it's always set in stone at compile time).

[Wet Orange Ostrich Toilet]

Does FSO 3.7.4 start normally?
Does 3.8RC1 start normally?

That error is impossible to hit, unless something very very weird is happening (as in, some sort of memory corruption: stuff_int_list is never called such that the lookup list type parameter is computed; it's always set in stone at compile time).

3.7.4 completely freezes up mere seconds after starting up.
I don't have 3.8RC1.

Also, this error occurred after making a table for a ship.

[The E]

Can you post that table entry?

[bomb3rman]

I sometimes have problems like this when I changed a table-file for a ship in a way that it was not supposed. (e.g. the model has 3 primary banks, but I defined only 2) -> crash of FRED.

Have you thought of taking the ship out and looking if the error occurs without the ship, too?

[The E]

I sometimes have problems like this when I changed a table-file for a ship in a way that it was not supposed. (e.g. the model has 3 primary banks, but I defined only 2) -> crash of FRED.

That's a completely different error message appearing at a completely different place during FRED execution though.

[Wet Orange Ostrich Toilet]

#Ship Classes

;;USB Piranha 
$Name:            USB Piranha
$Short name:         usfbomber1
$Species:            Terran
+Type:            XSTR("Strike Bomber", 3011)
+Maneuverability:         XSTR("Poor", 3012)
+Armor:            XSTR("Heavy", 3013)
+Manufacturer:         XSTR("USF Manufactories", 3014)
+Description:         XSTR("None", 3015)

$end_multi_text
+Tech Description: XSTR("WIP", 3016)
$end_multi_text     
+Gun Mounts:                     1
+Missile Banks:         2
$POF file:            usfbomber.pof
$Detail distance:            (0)
$ND:                      244 7 7
$ND:                      232 38 38
$ND:                      43 43 235
$ND:                      8 7 243
$Show damage:         YES
$Density:            1
$Damp:            0.35 
$Rotdamp:            0.5 
$Max Velocity:         0.0, 0.0, 110.0 
$Rotation time:         6.0, 5.75, 6.0 
$Rear Velocity:         0.0
$Forward accel:         4.0
$Forward decel:         2.0
$Slide accel:         0.0
$Slide decel:         0.0
$Expl inner rad:         50.0
$Expl outer rad:         100.0
$Expl damage:         25.0
$Expl blast:         2000.0
$Expl Propagates:         NO
$Shockwave Speed:         0.0
$Allowed PBanks:         ( "TLW-9 Arrow" "Subach HL-7" "Prometheus S" "Prometheus R" "Lamprey" "Circe" "Maxim" ) 
$Allowed Dogfight PBanks:   ( "Subach HL-7" "Prometheus S" "Prometheus R" "Lamprey" "Circe" "Maxim" )
$Default PBanks:         ( "Prometheus R" "Subach HL-7")
$Allowed SBanks:         ( "Rockeye" "Hornet" "Tornado" "Trebuchet" "Stiletto II" "Piranha" "Cyclops" "Cyclops#short" "Hornet#Weak" "EMP Adv." "Infyrno" "Rebel Bomb" "HS-14 Sidewinder"  ) 
$Allowed Dogfight SBanks:   ( "Rockeye" "Hornet" "Tornado" "Trebuchet" "Stiletto II" "Piranha" "Cyclops" "Cyclops#short" "Hornet#Weak" "EMP Adv." "Infyrno" "Rebel Bomb" )
$Default SBanks:         ( "Hornet" )
$SBank Capacity:         ( 90, 70)
$Show Secondary Models:         ( YES )
$Shields:            300
$Shield Color:         100 100 255
$Power Output:         4.0
$Max Oclk Speed:         150.0
$Max Weapon Eng:         80.0
$Hitpoints:            675
$Flags:            ( "player_ship" "default_player_ship" "bomber" "in tech database")
$AI Class:            Captain
$Afterburner:         YES
   +Aburn Max Vel:      0.0, 0.0, 170.0
   +Aburn For accel:      0.7
   +Aburn Fuel:      50.0
   +Aburn Burn Rate:      60.0
   +Aburn Rec Rate:      35.0
$Countermeasures:         20
$Scan time:            2000
$EngineSnd:            127
$Closeup_pos:         0.0, 0.0, -45
$Closeup_zoom:         0.3               
$Score:            10
$Subsystem:            communications,   10, 0.0
$Subsystem:            navigation,      10, 0.0
$Subsystem:            weapons,      20, 0.0
$Subsystem:            sensors,      10, 0.0
$Subsystem:            engine,         35, 0.0
#End

[Wet Orange Ostrich Toilet]

Wait, I have no idea what happened or how it happened, but I think the error somehow fixed itself.

[bomb3rman]

I sometimes have problems like this when I changed a table-file for a ship in a way that it was not supposed. (e.g. the model has 3 primary banks, but I defined only 2) -> crash of FRED.

That's a completely different error message appearing at a completely different place during FRED execution though.

Yes I know, just wanted to explain that I also had problems with FRED when changing tables.

But I also see my problem in this table:

+Gun Mounts:                     1

$Default PBanks:         ( "Prometheus R" "Subach HL-7")

What happens if you delete the "Subach HL-7?

+Missile Banks:         2

$Default SBanks:         ( "Hornet" )

And put a second missile in Default SBanks?

[Wet Orange Ostrich Toilet]

But I also see my problem in this table:

+Gun Mounts:                     1

$Default PBanks:         ( "Prometheus R" "Subach HL-7")

What happens if you delete the "Subach HL-7?

+Missile Banks:         2

$Default SBanks:         ( "Hornet" )

And put a second missile in Default SBanks?
[/quote]

That was a different error that I somehow overlooked, thanks.

[bomb3rman]

You're welcome, happens to me, too

[Wet Orange Ostrich Toilet]

And the error has reappeared.

EDIT: I swear to god, FRED's messing with me, the error disappeared again but now one of my ship sort of disappears in the mission it's supposed to be in (as in, you can still target it but speed shows 0 and Distance shows NaN.)

[The E]

Check the model's Moment of Inertia entry (look in the pof). If there are NaN values in there, that would be a likely cause.

[Wet Orange Ostrich Toilet]

Check the model's Moment of Inertia entry (look in the pof). If there are NaN values in there, that would be a likely cause.

Nope, double checked that already.
I did however manage to temporarily fix it by stealing another ship's table.

[Goober5000]

This is definitely a memory corruption issue, which explains the bizarre behavior in the first place, the error spontaneously fixing itself, and the NaN.

+Gun Mounts: and +Missile Banks: are only for the ship loadout display and should not affect the list parsing.

If this error happens again, let a coder know.  It will be necessary to trace through the mod using a debug build.