GZDoom crashing.

[Skornedemon]

Currently running into a problem. A specific Modelpack is crashing GZDoom on boot(newest,and all revisions earlier). A slightly altered version of the model pack will load perfectly fine. I dont think the game even gets to loading past the resources?

I have the crash report attached here: http://www.mediafire.com/download/jul06 ... 282%29.zip

[Rachael]

What model pack are you using, and what modification are you making to it to make it stable again?

[Skornedemon]

Apologies for the really late response.

I'm running the FNAF2 mod, located here:

---

http://www.mediafire.com/download/ekofh ... dys2_1.rar

Whether you hate the mod idea or not, It's a stability problem either way.

Ive had, now, two different people crash trying to run it. Both seem to be model related.
If you try to run the game without models, it'll be just fine. It's something specific with those models and GZDOOM 2.1
Ive used the newest development release 2.1 and all prior versions. One computer had an Intel HD Graphics controller,another had some type of AMD card.
GZDoom 1.9 builds seem to run the game just fine(with slight modifications to the decorate to get it to run of course)

Ive tried two different methods of converting the models, one being this: http://forum.zdoom.org/viewtopic.php?f=37&t=35790
The other being Noesis' md3 exporter. Even with the first method that's literally designed for the best gzdoom results, it'll have the same crash.

EDIT:
Here's the crash report and specs of one of my tester's crash. I should mention it will always fatal error upon loading.
All their video drivers are updated.
AMD FX(tm)-8120 Eight-Core Processor, 3.10 GHz, 8gb Ram, 64-Bit OS Win 7 Ultimate
AMD Radeon HD 6800 series

---

http://www.mediafire.com/download/u49n4 ... Report.zip

Real quick though, it seems GZDoom 2.0 doesnt use nearly as much memory as GZDoom 1.9 and lower with this mod. Good work on however you achieved that.
(the FNAF2 download comes with a custom development build that allows more than 4GB of memory usage, i believe, so the mod can run on 64-bit systems)

[Rachael]

Whether you hate the mod idea or not, It's a stability problem either way.

That should be the least of your worries.

However there is a big issue.

This mod is a big download, and while someone (most likely Graf) may download it and nail down the problem, it often helps if the problem can be isolated to a mod with much fewer functions and demonstrating the crash "bare-bones" so to speak, without a lot of resources that would make debugging (which means running a special debug build that is not optimized and slowed down by debugging functions - the same build has to be restarted numerous times due to code changes, too) a whole lot slower.

This also helps to nail down what the problem really is - because it may also just be a runaway memory issue. (I have not looked at the reports myself)

Anyway, I will leave this be for now, hopefully I've helped you at least get the info Graf needs for this.

[Graf Zahl]

This got reported before. The mod simply runs out of graphics memory for the vertex buffers for this large amount of huge models.

I'm sorry, but this is something I can't fix for now because it requires some fundamental redesign of hoe model loading is handled. Currently the game loads all models at game startup, but it should really deal with models as with textures and precaching them on an as-needed basis.

But this is rather low on my list of priorities, especially considering that i do not really have the time to work on GZDoom at the moment.

[NeuralStunner]

Curiosity: Is there any way to catch this problem and make GZDoom abort more gracefully? (Just so users have a better idea what's happening.)

Admittedly, I'm unsure how much it would help, seeing how often version-related startup errors are reported as "crashes"...