Author Topic: Assert: "bm_bitmaps[n].handle == bitmap_id"  (Read 428 times)

0 Members and 1 Guest are viewing this topic.

Offline Admiral Nelson

  • Resurrecter of Campaigns
  • 211
  • The GTA expects that every man will do his duty.
Assert: "bm_bitmaps[n].handle == bitmap_id"
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, 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?
If a man consults whether he is to fight, when he has the power in his own hands, it is certain that his opinion is against fighting.

 
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.
[19:31] <MatthTheGeek> you all high up on your mointain looking down at everyone who doesn't beam everything on insane blindfolded

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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?
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.

 
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
Can confirm, removing -3D shockwaves makes the assertion not happen in places where it would otherwise happen every time(unless time compression was used).
[19:31] <MatthTheGeek> you all high up on your mointain looking down at everyone who doesn't beam everything on insane blindfolded

 

Offline Admiral Nelson

  • Resurrecter of Campaigns
  • 211
  • The GTA expects that every man will do his duty.
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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. 
If a man consults whether he is to fight, when he has the power in his own hands, it is certain that his opinion is against fighting.

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.
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.

 
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.
[19:31] <MatthTheGeek> you all high up on your mointain looking down at everyone who doesn't beam everything on insane blindfolded

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.
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.

 
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.
[19:31] <MatthTheGeek> you all high up on your mointain looking down at everyone who doesn't beam everything on insane blindfolded

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.
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 m!m

  • 210
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.

 
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.
[19:31] <MatthTheGeek> you all high up on your mointain looking down at everyone who doesn't beam everything on insane blindfolded

 

Offline m!m

  • 210
Re: Assert: "bm_bitmaps[n].handle == bitmap_id"
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.