Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Admiral Nelson on April 29, 2017, 11:11:11 am

Title: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: Admiral Nelson on April 29, 2017, 11:11:11 am
This Assertion crash comes in debug consistently in The Antagonist whenever the APE primary weapon is fired.  This weapon, as you may recall, creates a shockwave with every shot.  I found a similar, open but old Mantis entry (http://scp.indiegames.us/mantis/view.php?id=2865), that seems to be consistent with the behavior we are seeing in The Antagonist.  Any ideas on what this one might be?  Attaching two log files (from FrikgFeek) documenting this one; I also have observed the same thing happening in The Antagonist as well.

Any thoughts on what could cause this?

[attachment stolen by Russian hackers]
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: FrikgFeek on April 29, 2017, 11:41:49 am
A bit of extra info. Using 4x or higher time compression prior to firing the first shots seems to make the missions run completely fine even if the time compression is never used again.

How or why I have no idea.
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: AdmiralRalwood on April 29, 2017, 04:11:16 pm
Any thoughts on what could cause this?
The problem is that it could be just about anything texture-or-image-related, and whatever the problem piece of code is may not be temporally-related to when the actual assertion got hit. There have been multiple instances of this assertion being tripped, with completely different causes, and trying to track the actual cause is a ***** and a half (and debug logs are, unfortunately, more-or-less completely useless for this kind of thing; you pretty much need to be stepping through with a debugger when it happens, so you can look at all the relevant data in memory).

When you say the Mantis issue is consistent with the behavior you're seeing, does that include removing -3dshockwaves making the assertion stop?
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: FrikgFeek on April 29, 2017, 04:24:45 pm
Can confirm, removing -3D shockwaves makes the assertion not happen in places where it would otherwise happen every time(unless time compression was used).
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: Admiral Nelson on May 01, 2017, 07:54:21 am
The issue in this case turned out to be that the original author of The Antagonist did not provide a "+Shockwave name:" entry in the dinky shockwaves section of the APE weapon in weapons.tbl.  The assertion could therefore be related to either however the code handles a default value when this is not explicitly provided; or in the asset that is used by default. 
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: AdmiralRalwood on May 01, 2017, 12:50:55 pm
The issue in this case turned out to be that the original author of The Antagonist did not provide a "+Shockwave name:" entry in the dinky shockwaves section of the APE weapon in weapons.tbl.  The assertion could therefore be related to either however the code handles a default value when this is not explicitly provided; or in the asset that is used by default. 
Hey, that's rather helpful; I'll see if I can track it down later.
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: FrikgFeek on May 04, 2017, 01:13:39 pm
Ok... I'm running into this assertion again... with a standard MVPs shockwave from a cruiser exploding. It happens when a mission is the 2nd mission loaded or if the mission is restarted. It also only happens if both -3d shockwaves and framebuffer shockwaves are enabled AND I'm running a fastdebug build.

It works perfectly fine if one of those flags is ticked off or if I'm running a standard build.
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: AdmiralRalwood on May 05, 2017, 05:30:56 pm
It works perfectly fine...if I'm running a standard build.
Well, assertions aren't checked in non-debug builds; that doesn't necessarily mean that it's fine, it just means that it's ignoring that the wrong bitmap is being used.
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: FrikgFeek on May 06, 2017, 07:35:58 am
Alright, it seems to work fine then. The shockwaves show up properly and there's no real slowdown, it's most likely broken behind the scenes but it's never noticed.

If this isn't a bug and is just debug builds getting stricter then MVPs shockwave assets should be fixed.
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: AdmiralRalwood on May 06, 2017, 11:14:58 am
If this isn't a bug and is just debug builds getting stricter then MVPs shockwave assets should be fixed.
This isn't an asset problem; this is an engine bug.
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: m!m on May 07, 2017, 11:13:22 am
I cannot reproduce this error with either The Antagonist or an exploding cruiser with the MediaVPs. The APE weapon in The Antagonist works perfectly fine and I see that the shockwaves show up properly.
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: FrikgFeek on May 07, 2017, 01:24:44 pm
The APE was fixed to not triggers this and the cause might not be a cruiser exploding. I tried reproing it in MediaVPs by ~K-ing a Cain and it didn't trigger but mission 3 from FSCRP 'Tango' triggers it at the start.
It starts with a Cain explosion so I assumed that was it, though it could be a cluster missile or something.

If you want to trigger this in The Antagonist remove the +shockwave name entry under $dinky shockwave for the APE-86.

[attachment stolen by Russian hackers]
Title: Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Post by: m!m on May 07, 2017, 03:45:41 pm
There is no +Shockwave name in the version I am using. Here is the relevant section from the table:
Code: [Select]
$Dinky shockwave:                                           
    +Shockwave damage:                                     25
    +Blast Force:                                          0
    +Inner Radius:                                         5
    +Outer Radius:                                         10
    +Shockwave Speed:                                    500

I just updated to the FSCRP version of the campaign but it also didn't crash with the original release.