[DYNRPG] ACCESS VIOLATION WHEN USING CLASSES

Posts

Pages: 1
I'm working on a DynRPG plugin to display gauges (health, mana, and ATB) and status conditions above both heroes and monsters (or just one of those or maybe even individuals, I'm hoping to manage plenty of configurability). I'm running into an error I don't know how to fix, though. I keep running into pop-up windows with messages like this:

Access violation in module 'DynGauge.dll' in with address 6A1C163C and offset 000000D8 of type Read occured.


By commenting out sections of code, I was able to determine that the problem seems to be with parts that attempt to use RPG classes within a class I made to handle individual Battlers' displays. For example:

void SetBattler( RPG::Battler * rBattlerPtr )

{
// Initialize variables
mBattlerPtr = rBattlerPtr; // Error 1
mCurHealth = rBattlerPtr->hp; // Error 2
mCurMana = mBattlerPtr->mp; // Can't even try this since error 1 happens
mCurATB = mBattlerPtr->atbValue; // Same as above
}


This section of code causes error messages when I try to copy the pointer to a Battler into a member variable of the class. I also tried doing just the line marked with "Error 2", to see if I could access the public attributes of the Battler through the rBattlerPtr parameter, which at least gets passed into the method okay, but no dice. In case anyone's wondering, the SetBattler method doesn't get called until after the Battler is drawn (using OnBattlerDrawn), so unless there's something I misunderstand about how that works, this shouldn't be a problem of the Battler being uninitialized.

Oddly enough, this snippet does work:

BattleDisplay()

{
// Initialize variables
mBattlerPtr = NULL;
mCurHealth = 0;
mCurMana = 0;
mCurATB = 0;
mDisplayPtr = RPG::Image::create( DISPLAY_WIDTH, DISPLAY_HEIGHT );
}


So I know it's possible to call a static method of an RPG class, at least. It appears to me DynRPG doesn't like its instances to be used from inside other classes, though.

So, anybody had similar experiences and figured out how to fix them, or have insight into DynRPG's internal workings that could explain this? Am I going to have to avoid interacting with DynRPG from within other classes?

In case anyone wants to look at the full source code for what I have so far, here's a GitHub repository for it: https://github.com/AubreyTheBard/DynGauge/tree/master
Hmmm, first, let's talk high-level stuff. That error usually means you're trying to call an RPG object at the wrong time (where it doesn't yet exist), or you're trying to use one in an incorrect way. Examples: Calling an RPG::Battler member when you're not in battle, or if the battler does not exist. They're basically things that could have the correct syntax, so the compiler doesn't catch it.

As far as your code goes, assuming your class compiled fine, the crash is going to stem from onFrame(). You can probably trim down the stuff you have btw:

void onFrame( RPG::Scene scene )
{

if (scene == RPG::SCENE_BATTLE)
{
inBattle = true;
for (int i=0; i<NUM_MONSTERS; i++)
{
// if (0 != RPG::monsters[i]->databaseId) { } // crash
if (RPG::monsters[i])
{
monsterBattleDisplay[i].SetBattler( RPG::monsters[i] );
}
}
}
else if (inBattle) inBattle = false;
}

With your original code, here's the problem though:
if (0 != RPG::monsters[i]->databaseId)
If RPG::monsters does not exist, RPG::monsters->databaseId wouldn't exist either, so as soon as it loops to a non-existent monster, it's going to crash.

To check if a monster exists, use:
if (RPG::monsters[i])

RPG::monsters is just a pointer after all, so you can compare it as if it were a boolean value.

Also, get rid of "#define NOT_MAIN_MODULE" because you don't need that anymore.

That should at least get you started. You might be trying to add too much to your class at once though, so I'd recommend making sure a few of the values and images work for a monster or two before you go wild with it. Start small. :P
Ah, that makes sense, anything involving a Battler pointer was causing problems because it was passing in faulty pointers in some cases. X) Thanks for the discerning eye, PepsiOtaku. The part I was having trouble with is no longer causing crashes. Still having similar issues with another part, but I'll post again if I can't figure it out.
Pages: 1