[mobcdmoc3]

Tested this on 3.6.14RC6 and RC2. Running mediavps 3.6.12.

I didn't test a whole lot of them, but some of them just simply phase through other ships. Off the top of my head, I recall the Erinyes, the Hercules, and the Herc. Mk. 2 doing this, along with one new ship that I recently imported. However, when I try to repeat this bug in the campaign, these bugs are non-existent. The Herc. Mk. 2 behaves normally.

I thought that maybe the new ships.tbm file I added might have done something weird, but even after removing that, the problem persisted. That and a music.tbm file are all that I've added in terms of modding. I know I don't have any no collision flags in the missions I've created, so that's out of the question too. Can anyone offer any explanation?

There's a debug log attached to this post, in case that helps.

Secondly, can anyone explain to me what this means? I poked around with the debugger while trying to figure out what was wrong and this was spat out.

Code: [Select]

Boolean '+Dynamic' type unknown; assuming 'no/false'
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! SCP_DumpStack + 354 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! Warning + 430 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! stuff_boolean + 469 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! parse_ship_values + 6840 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! parse_ship + 1013 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! parse_shiptbl + 374 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! parse_modular_table + 267 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! ship_init + 578 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! game_init + 1645 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! game_main + 519 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! WinMain + 330 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_6_14_RC6_DEBUG_NO-SSE.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes


[attachment deleted by a ninja]

[z64555]

http://www.hard-light.net/wiki/index.php/Ships.tbl#.2BDynamic_Glide_Cap

Appears somewhere in the tables, "+Dynamic" was found instead of "+Dynamic Glide Cap."

Running through the .log, I see that it failed to open scripting.tbl, interface.tbl, armor.tbl.

The Shadow-shp.tbm is the culprit behind your +Dynamic error, just switch out the offending line with +Dynamic Glide Cap and it should be good to go...

May be a problem with shaders...

corvette2s-01.pof has a problem with its paths (path nodes 17, 25, and 15) as well as has a problem with its fighterbay and reactor subsystems...


Hmm, that's what I could read out of it so far.

[mobcdmoc3]

That's odd... After opening up the .tbm file and checking what you told me to check, I the +Dynamic Glide Cap thing there. Perhaps there's something wrong with the table in general? The part of the table where I found it is below.

Code: [Select]

$Slide accel: 2.0
$Slide decel: 2.0
$Glide:
+Dynamic Glide Cap: YES
$Autoaim FOV: 1
+Converging Autoaim
+Minimum Distance: 750.0
Regarding the corvette - That must be the Moloch, on the assumption the label is correct. I've never touched that thing before. Perhaps there's a bug?

[z64555]

Ok, that's the problem right there. $Glide expects a bool value, and the parser instead found +Dynamic.

so, just swap this bit of stuff into there and let's see if that fixes a few things:

Code: [Select]

$Glide:    YES
    +Dynamic Glide Cap:    YES

[mobcdmoc3]

That seems to have done the trick. Debugger no longer complains about that. Thanks for figuring that one out. Would this have broken anything?

Now that that's out of the way, does anyone have any idea why I'm flying through stuff? I think I'll also note that I *think* I get collisions from debris.

[The E]

Running through the .log, I see that it failed to open scripting.tbl, interface.tbl, armor.tbl.

*sigh*

How many times do I have to tell you people that this is not an error, and usually not important....
It isn't worth mentioning unless you know the mod in question has those tables (which, in the case of interface.tbl, is highly unlikely, since that tbl does nothing).