model spawn crash game

#1 Code, stack trace (ie during trigger: trace(1); <code of trigger> trace(0);), console log?

#2 So I did some trace(1) spawn code goes here trace(0) and nailed the issue to be when spawning that model as thought, I then started to insert other models instead of that model and got no issue with trigger a spawn what so ever.

I then tried to insert that very same enemy AI model as an hero in the character group instead and spawn that very same model as enemies with triggers as before.

It worked very well and no issue what so ever???? It has come to this, as long as I do not use a certain hero model then I can pretty much spawn any model as an enemy with triggers, but as soon as he is back in the group that certain enemy model will crash the game when a trigger effect spawn it.

Now that is odd. The hero model(who apparently cannot be a part of the group) is not in the same folder as the enemy model. They are not sharing the same texture, the same name either????

It is suppose to spawn two bots and it does it well when I remove my hero or the enemy(anything goes as long as one of them is removed).

Console trace enabled.
   Entering AIPlayer::tacticsSpawn(bot1, botspawn1, 0)
      Entering armor::onAdd(179, 12347)
      Leaving armor::onAdd() - return 
      Entering ShapeBase::maxInventory(12347, bow)
      Leaving ShapeBase::maxInventory() - return 1
      Entering ShapeBase::setInventory(12347, bow, 1)
         Entering ShapeBase::maxInventory(12347, bow)
         Leaving ShapeBase::maxInventory() - return 1
         Entering Weapon::onInventory(bow, 12347, 1)
         Leaving Weapon::onInventory() - return 
      Leaving ShapeBase::setInventory() - return 1
      Entering ShapeBase::maxInventory(12347, CrossbowClip)
      Leaving ShapeBase::maxInventory() - return 10
      Entering ShapeBase::setInventory(12347, CrossbowClip, 10)
         Entering ShapeBase::maxInventory(12347, CrossbowClip)
         Leaving ShapeBase::maxInventory() - return 10
      Leaving ShapeBase::setInventory() - return 10
      Entering ShapeBase::maxInventory(12347, bowAmmo)
      Leaving ShapeBase::maxInventory() - return 200
      Entering ShapeBase::setInventory(12347, bowAmmo, 200)
         Entering ShapeBase::maxInventory(12347, bowAmmo)
         Leaving ShapeBase::maxInventory() - return 200
         Entering bowAmmo::onInventory(bowAmmo, 12347, 200)
         Leaving bowAmmo::onInventory() - return 
      Leaving ShapeBase::setInventory() - return 200
      Entering bowImage::onMount(94, 12347, 0)
         Entering ShapeBase::getInventory(12347, bowAmmo)
         Leaving ShapeBase::getInventory() - return 200
         0 bowImage::onMount
      Leaving bowImage::onMount() - return 
   Leaving AIPlayer::tacticsSpawn() - return 12347
   Entering AIPlayer::tacticsSpawn(bot2, botspawn2, 0)
      Entering armor::onAdd(179, 12348)
      Leaving armor::onAdd() - return 
      Entering ShapeBase::maxInventory(12348, bow)
      Leaving ShapeBase::maxInventory() - return 1
      Entering ShapeBase::setInventory(12348, bow, 1)
         Entering ShapeBase::maxInventory(12348, bow)
         Leaving ShapeBase::maxInventory() - return 1
         Entering Weapon::onInventory(bow, 12348, 1)
         Leaving Weapon::onInventory() - return 
      Leaving ShapeBase::setInventory() - return 1
      Entering ShapeBase::maxInventory(12348, CrossbowClip)
      Leaving ShapeBase::maxInventory() - return 10
      Entering ShapeBase::setInventory(12348, CrossbowClip, 10)
         Entering ShapeBase::maxInventory(12348, CrossbowClip)
         Leaving ShapeBase::maxInventory() - return 10
      Leaving ShapeBase::setInventory() - return 10
      Entering ShapeBase::maxInventory(12348, bowAmmo)
      Leaving ShapeBase::maxInventory() - return 200
      Entering ShapeBase::setInventory(12348, bowAmmo, 200)
         Entering ShapeBase::maxInventory(12348, bowAmmo)
         Leaving ShapeBase::maxInventory() - return 200
         Entering bowAmmo::onInventory(bowAmmo, 12348, 200)
         Leaving bowAmmo::onInventory() - return 
      Leaving ShapeBase::setInventory() - return 200
      Entering bowImage::onMount(94, 12348, 0)
         Entering ShapeBase::getInventory(12348, bowAmmo)
         Leaving ShapeBase::getInventory() - return 200
         0 bowImage::onMount
      Leaving bowImage::onMount() - return 
   Leaving AIPlayer::tacticsSpawn() - return 12348
Console trace disabled. <-------------- last line in console game crash

Edit: I guess taking my old re skin model up from the bag again might be a better option after all :o)

#3 That is messed up. So if you don't use a model as an avatar and spawn a particular model is okay? But if you use it as an avatar and spawn the other model then it crashes? But only if the avatar was in a certain group?

Can you catch it with the debugger in Visual Studio? It would be interesting to the c++ code that is causing the issue. Perhaps it is related to the object class OnAdd or something.

#4 I get this error in my VS 2010 UL:

First-chance exception at 0x750cc41f in Dryadalum01_DEBUG.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0018928c..
Unhandled exception at 0x750cc41f in Dryadalum01_DEBUG.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0018928c..

in jdapistd.c

/*
 * Decompression initialization.
 * jpeg_read_header must be completed before calling this.
 *
 * If a multipass operating mode was selected, this will do all but the
 * last pass, and thus may take a great deal of time.
 *
 * Returns FALSE if suspended.  The return value need be inspected only if
 * a suspending data source is used.
 */

GLOBAL(boolean)
jpeg_start_decompress (j_decompress_ptr cinfo)
{
  if (cinfo->global_state == DSTATE_READY) {
    /* First call: initialize master control, select active modules */
    jinit_master_decompress(cinfo);
    if (cinfo->buffered_image) {
      /* No more work here; expecting jpeg_start_output next */
      cinfo->global_state = DSTATE_BUFIMAGE;
      return TRUE;
    }
    cinfo->global_state = DSTATE_PRELOAD;
  }
  if (cinfo->global_state == DSTATE_PRELOAD) {
    /* If file has multiple scans, absorb them all into the coef buffer */
    if (cinfo->inputctl->has_multiple_scans) {
#ifdef D_MULTISCAN_FILES_SUPPORTED
      for (;;) {
	int retcode;
	/* Call progress monitor hook if present */
	if (cinfo->progress != NULL)
	  (*cinfo->progress->progress_monitor) ((j_common_ptr) cinfo);
	/* Absorb some more input */
	retcode = (*cinfo->inputctl->consume_input) (cinfo);
	if (retcode == JPEG_SUSPENDED)
	  return FALSE;
	if (retcode == JPEG_REACHED_EOI)
	  break;
	/* Advance progress counter if appropriate */
	if (cinfo->progress != NULL &&
	    (retcode == JPEG_ROW_COMPLETED || retcode == JPEG_REACHED_SOS)) {
	  if (++cinfo->progress->pass_counter >= cinfo->progress->pass_limit) {
	    /* jdmaster underestimated number of scans; ratchet up one scan */
	    cinfo->progress->pass_limit += (long) cinfo->total_iMCU_rows;
	  }
	}
      }
#else
      ERREXIT(cinfo, JERR_NOT_COMPILED);
#endif /* D_MULTISCAN_FILES_SUPPORTED */
    }
    cinfo->output_scan_number = cinfo->input_scan_number;
  } else if (cinfo->global_state != DSTATE_PRESCAN)
    ERREXIT1(cinfo, JERR_BAD_STATE, cinfo->global_state);
  /* Perform any dummy output passes, and set up for the final pass */
GREEN ---> return output_pass_setup(cinfo);
}

The error above is when I run the game with the hero in the character group and the enemy in the bot spawn group.

Looks like it does not like the jpeg file I use for texture :o/

As soon as I remove the hero and use a enemy model in the character group instead I got a clean run(triggered spawn without crash) :o/ How odd.

Or the other way around I remove the enemy model and use the hero model in the character group and as an enemy also gives a clean run(triggered spawn without crash).

Perhaps the JPEG file is corrupted in some way.... seems to be the only reason now.

#5 So I change the texture of the hero model and now the triggered spawn works and no crash happens(90 procent of the time).

Now what is odd here is that when I use the hero model in his own folder and a enemy model(in another folder) like the hero model, just with a different texture, spawns I get a little lag/delay in the game(5-10 procent chance of crash as the spawn occurs).

It is like the engine says, hey I know this type of model and do not care that they are in different folders, have different names and texture, I simply look at this as re skinning a model(which often cause in game lag on when a model is on the run/move).

Now if a model not of the hero model type is spawn no lag/delay occur.

#6 @Dwarf King,
Maybe this is a silly question, but can you get by without using JPG? It sounds like there is definitely a bug in there. Maybe make everything PNG and see if it still does this?

#7 @Demolishun
Not silly at all, I shall try that out this evening(I mean all I need is to convert the texture file in Photoshop element).

#8 Your models that share the same base dont have the same material references in them do they ?

#9 @Andy that was the issue. Thanks.

#10 text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler

#11 Sounds like a latent bug somewhere in the core of something. When I get to this point of spawning things on the fly I will let you know if I run into this. At that point I may have an incentive to work this out.

#12 Sorry about jumping into this late, not sure my info will help much but i'll toss it out there anyway.

I was having an identical crash on mission load, that Tim from mgt proposed might have been a clash of naming with a class name, he said this was a problem he had had before. In the end i pretty much ended up with a new mission file that got rid of the issue. So it is almost certainly something in the mission file that caused the issue to appear.

not much help i know, sorry

#13 You were getting bad_alloc exceptions? That usually indicates being out of memory. Were you running particularly low on RAM, or have a lot of programs running during those tests?

#14 text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler text filler