Author Topic: Wierd Error: Assert?  (Read 1089 times)

0 Members and 1 Guest are viewing this topic.

Offline HLD_Prophecy

  • PVD_Hope in a former life
  • 29
Upon trying to launch my mod-in-progress, I'm getting this strange error:

Code: [Select]
Assert: mp->nverts > 1
File: modelread.cpp
Line: 2780

ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! WinAssert + 194 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! model_maybe_fixup_subsys_path + 169 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! model_set_subsys_path_nums + 307 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! model_load + 3732 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! techroom_select_new_entry + 450 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! techroom_do_frame + 782 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! game_do_state + 333 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! gameseq_process_events + 237 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! game_main + 782 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! WinMain + 330 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_7_2_NO-SSE-DEBUG.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes

I've done some model and table edits recently so they may be the cause. Anyone know what this means?

 

Offline niffiwan

  • 211
  • Eluder Class
From a quick look at the code I'd say one of your pof subsystem paths doesn't have enough vertices (i.e. points). Unfortunately the Assert doesn't tell you which subsystem has the problem... or even which ship  :blah:

(for any other coders looking at this)
Code: [Select]
// ensure that the subsys path is at least SUBSYS_PATH_DIST from the
// second last to last point.
void model_maybe_fixup_subsys_path(polymodel *pm, int path_num)
{
vec3d *v1, *v2, dir;
float dist;
int index_1, index_2;

Assert( (path_num >= 0) && (path_num < pm->n_paths) );

model_path *mp;
mp = &pm->paths[path_num];

Assert(mp != NULL);
Assert(mp->nverts > 1);

index_1 = 1;
index_2 = 0;

v1 = &mp->verts[index_1].pos;
v2 = &mp->verts[index_2].pos;

dist = vm_vec_dist(v1, v2);
if (dist < (SUBSYS_PATH_DIST - 10))
{
vm_vec_normalized_dir(&dir, v2, v1);
vm_vec_scale_add(v2, v1, &dir, SUBSYS_PATH_DIST);
}
}
« Last Edit: November 07, 2015, 08:36:33 pm by niffiwan »
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Presumably he knows which ship he just tried to select when it crashed, but yes, that could be made a more informative assertion.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline niffiwan

  • 211
  • Eluder Class
FYI, I've created a PR to change the Assert into an Error and provide some useful info.

Edit: it's been committed so the next nightly should tell you which ship, path & parent path has the issue.
« Last Edit: November 07, 2015, 11:03:05 pm by niffiwan »
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline HLD_Prophecy

  • PVD_Hope in a former life
  • 29
Problem solved!

Sooo... I took a closer gander at the .pof (It's the GTB Kronus [http://www.hard-light.net/wiki/index.php/GTB_Kronus] for future reference) and it turns out that the turret paths were empty. They each had one object labeled "Vertex 1" but this was basically empty. No paths. So I used the PCS Auto-Generate function to generate paths, and hey presto!

Works fine now, thanks a bunch! FRED'ers here are so helpful. You guys really go the distance. Making good progress on my mod now.  :)