"Access Violation"

[RecruitMonty]

Originally Posted by Mobhack

As far as I recollect Scenhack does not read scenario info text, display lbms or shps etc.

When exactly does it crash e.g. "Scenario loads OK but when I go to screen X and select unit Y .. kaboom!". In order to debug something, one needs to know exactly what path is taken to get to the fault. That is far more helpful than a vague and woolly statement of "it has an access violation error!" with no specifics.

For instance - is everything OK until you go to open the formation detail screen. (Which would point you to something being wrong formations wise with the OOB in question I'd infer!).

Then what is special about the scenario that causes the crash?. Do other scenarios using that hacked OOB load OK?. If they work OK, then what's the difference - uses some particular unit or formation or weapon the others don't, perhaps?. Or uses something that's no longer there since it got edited out of that OOB...

It is purely a problem with ScenHack. In-game everything is fine. No crashes whatsoever. Just one or two scenarios in ScenHack fail to register properly when I click on the "make tables" function under the SQL tab - specifically six of mine all of which use modified OOBs (units from 35, 44, and 42).

Other Scenarios I've made have, however been processed by ScenHack without any problems and have produced tables in SQL without incident. These also used the same OOBs and even the same units in some cases.

I hope that clarifies things.

The game runs fine. It is just ScenHack that isn't happy and only in the case of those six scenarios. It loads incomplete tables for those scenarios and I get those two error messages each time (one for one half and one for the other).

It is not the Borland problem. I downloaded the fix for that and everything runs great now.

I have a disk version of the game so I've got full functionality.

Incidentally, I did a "Broken Link" check in the vanilla OOBs recently - USA and found a whole bunch of units with Nationality set to "0". Is this a bug?

[DRG]

Originally Posted by RecruitMonty

Incidentally, I did a "Broken Link" check in the vanilla OOBs recently - USA and found a whole bunch of units with Nationality set to "0". Is this a bug?

NO it's not a "bug"...........it's a way to build a company sized formation with sub formations that ONLY show up in the company but not on their own.

[RecruitMonty]

NO it's not a "bug"...........it's a way to build a company sized formation with sub formations that ONLY show up in the company but not on their own.

Gotcha.

[scorpio_rocks]

Originally Posted by DRG

NO it's not a "bug"...........it's a way to build a company sized formation with sub formations that ONLY show up in the company but not on their own.

Neat Trick! I had never realised this must immediately incorporate into my own custom OoBs.

[RecruitMonty]

Originally Posted by scorpio_rocks

Neat Trick! I had never realised this must immediately incorporate into my own custom OoBs.

Indeed. It is not a bad idea. Would fix some of the clutter in my OOBs too.

[Mobhack]

It is purely a problem with ScenHack. In-game everything is fine. No crashes whatsoever. Just one or two scenarios in ScenHack fail to register properly when I click on the "make tables" function under the SQL tab - specifically six of mine all of which use modified OOBs (units from 35, 44, and 42).

Other Scenarios I've made have, however been processed by ScenHack without any problems and have produced tables in SQL without incident. These also used the same OOBs and even the same units in some cases.

I hope that clarifies things.

In which case then its probably something you have done in the barfing scenarios themselves that has caused a problem with the database table-building for some reason.

for example - have you done say, cross-attaching in the suspect ones but not in the ones that pass? Or put new leader names in and/or renamed units (but not in the ones that pass)?

Whatever it is that you did differently is the likely problem. It would be handy to know that, if you can isolate whatever that was.

If you could zip up a problem (and an OK) scenario (and any altered OOBs it needs too, any altered SHP and leader names etc as well) I'll be able to run that through the debugger and see what the thing is falling over trying to read in.

cheers
Andy

[RecruitMonty]

Originally Posted by Mobhack

In which case then its probably something you have done in the barfing scenarios themselves that has caused a problem with the database table-building for some reason.

for example - have you done say, cross-attaching in the suspect ones but not in the ones that pass? Or put new leader names in and/or renamed units (but not in the ones that pass)?

Whatever it is that you did differently is the likely problem. It would be handy to know that, if you can isolate whatever that was.

If you could zip up a problem (and an OK) scenario (and any altered OOBs it needs too, any altered SHP and leader names etc as well) I'll be able to run that through the debugger and see what the thing is falling over trying to read in.

cheers
Andy

OK. Thanks for the offer! That is a pretty big zip file though. I'll see what I can do. Will get on it by Friday - weekend at the latest.

It can't be cross-attaching or leader names as in both cases I've done that liberally. Same goes for loadouts, leader names and unit designations.

[RecruitMonty]

Originally Posted by Mobhack

In which case then its probably something you have done in the barfing scenarios themselves that has caused a problem with the database table-building for some reason.

for example - have you done say, cross-attaching in the suspect ones but not in the ones that pass? Or put new leader names in and/or renamed units (but not in the ones that pass)?

Whatever it is that you did differently is the likely problem. It would be handy to know that, if you can isolate whatever that was.

If you could zip up a problem (and an OK) scenario (and any altered OOBs it needs too, any altered SHP and leader names etc as well) I'll be able to run that through the debugger and see what the thing is falling over trying to read in.

cheers
Andy

Dear Andy,

I've given it a thought and I think the best thing I can do is recommend you download the mod itself - since all of the scenarios I'm having trouble with use most of the mod files anyway.

Then I'll send you a dropbox link by PM to the broken scenarios, which you can then download separately and check over.

That is, if you still fancy taking a peak.

I'll provide the links to the relevant posts in the mod section below:

Version 1.1P (the full mod compatible with v10 minus the recent updates):

http://forum.shrapnelgames.com/showp...&postcount=368

Version 1.1.5P (a mini update to 1.1P, which should be installed in case I missed anything from it in the latest version of the mod):

http://forum.shrapnelgames.com/showp...&postcount=396


Latest version (incl. nine scenarios, which are problem free vis-a-vis ScenHack and one which isn't - Scen. 413):

http://forum.shrapnelgames.com/showp...&postcount=400

[DRG]

Originally Posted by RecruitMonty

Dear Andy,

I've given it a thought and I think the best thing I can do is recommend you download the mod itself - since all of the scenarios I'm having trouble with use most of the mod files anyway.

It's Andys call to make but I can assure you he is more than busy enough with the two official games without a new puzzle to deal with so really.......don't expect any action on this until after the updates are released.