GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[Kappes Buur]

And another one:

How did you install r3072?
By ways of the automatic updater?
Manually?
What was the previous version which did work?

[SanyaWaffles]

I can confirm 3072 is crashing, but for me I don't even get a dump or a stack trace. Especially in 3D mode.

I am currently trying an older build to see if it works.

I am using Windows 10 x64.

32-bit crashes less gracefully, 64-bit just "closes".

[Kappes Buur]

I can confirm 3072 is crashing, ...

An exert from my tutorial on installing the GZDoombuilder family of editors

Update info:
As of version r3018 GZDoom Builder - Bugfix requires the latest .NET Framework

While not mentioned as required software, the upgrade to .NET Framework 4.6 also means
that SlimDX must be upgraded to the SlimDX End User Runtime for ".NET 4.0 from SlimDX's
website. Download either "x86 Download" or "x64 Download" depending which version of
the editor is installed.

[SanyaWaffles]

A bit of a problem: I cannot find SlimDX. The website you link is down.

EDIT: To clarify, slimdx.org itself is down. I found a mirror but I dunno if it's the most current version.

EDIT2: Okay, trying it with the GZDB x64 with SlimDX x64

EDIT3: Still crashes. Seems to get worse if I leave the program running.

[Kappes Buur]

Strange, SlimDX.org is down for me as well.

I uploaded the two SlimDX versions to Mediafire:

• SlimDX End User Runtime .NET 4.0 (January 2012)x86
• SlimDX End User Runtime .NET 4.0 (January 2012)x64

Did you delete the old GZBuilder.cfg file before updating?
What was the last version which did work?

[SanyaWaffles]

This is weird. I can't find my GZBuilder.cfg anywhere in my user profile.

As for the bug, I compiled a version of GZDBBF and it seems to crash in clr.dll - the common language runtime. Ouch.

[Ozymandias81]

This is how I "install" (always have portable versions of softwares, I prefer this way) GZDoom Builder:

1) Download latest devbuild from drdteam website
2) Install SlimDX .NET 2.0 january 2012
3) Install SlimDX .NET 4.0 x86/64 january 2012
4) Install Microsoft XNA Framework Redist 3.0
5) Make sure that MSVC (both x86 and x64) installed are 2008, 2010, 2012, 2013 and 2017, but installing first 2015 then getting it updated with WIndows Update that overwrite the version

I am on Win7 64bit Sp1 with .NET Framework 4.7.2

NEVER REUSE OLD CONFIG OR OLD PLUGINS/STUFF

And if crashes happens frequently because you have installed last MaxED installer, be sure to follow this so you can exclude some occasional crashes (and it depends by mod complexity btw).

All of this I did uninstalling GZDoom Builder from pc (months ago) and unzipping on a new folder latest devbuild

[SanyaWaffles]

So I ran a memtest yesterday to rule out my computer's memory being bad. It passed all four passes.

I ran it on a spare laptop I happened to have. It doesn't seem to crash there.

this means to me there's something corrupting the install on this machine.

I did a fresh clean install for everything in terms of GZDB-BF on my main workstation. It still crashes after using it a while in Visual 3D Mode, even after getting rid of GZBuilder.cfg and nuking the original install directory.

I'm not sure exactly what's going on, but it appears it's something to do with my install of Windows 10 perhaps.

Next I'm gonna try just the bare minimum - DOOM2.wad and gzdoom.pk3 being loaded, and go around in some basic map and see if I can reproduce it.

If that fails... I'm considering wiping and reinstalling Windows 10 (a painful process) and reporting back.

However it still seems to be crashing in the clr.dll, which I cannot debug at all.

[SanyaWaffles]

Sorry to double post but I wanted to update:

I did some testing with just DOOM2.WAD and gzdoom.pk3. No crashes.

So I tried using an ipk3 instead of a directory for loading my TC's assets.

So far it has not crashed.

I will edit this post with more information, so far it's holding.

EDIT: Seems it complains when I use a directory as opposed to a pk3/ipk3. Otherwise it runs smooth as ice.

[Graf Zahl]

So I am not the only one having had problems getting GZDB to work at all. In light of the desire to port it to Linux, I think that even for Windows all those crusty and outdated backend components need to be replaced by something that's a) more modern and b) less problematic to get working, even if it means refactoring the code on a larger scale.

Depending on installable user runtimes for dependencies is a first grade recipe for problems.

[SanyaWaffles]

SlimDX's website has been down, making it hard to get official redistributables - as I pointed out in the Linux porting thread. This is not a good sign, especially since this is a vital component to the map editor.

I feel switching to OpenGL will be better in the long run.

I still wonder why GZDB-BF is crashing at clr.dll when using directories. It makes no sense to me why a loose directory would have more problems than a ZIP file, considering you gotta deal with compression.

[Kappes Buur]

SlimDX's website has been down, making it hard to get official redistributables - as I pointed out in the Linux porting thread. ...

I provided alternate download links in my post 7 posts up.
Also in my tutorial about installing the DB family of editors in Windows.

[Tormentor667]

How did you install r3072? By ways of the automatic updater? Manually? What was the previous version which did work?

This is occassional. Sometimes it works automatic, sometimes I need to install it manually. GZDB starts and works, the errors just happen sometimes during mapping sessions. I just downloaded the latest version now and made sure to install SlimDX (just as described in your website), let's see if it does any better.

A big problem sometimes is (and this only happens in Visual mode, never in 2D mode) that during mapping it crashes, but without a error message. The program simply closes. I noticed that this doesn't happen though if things are deactivated in Visual Mode ("T"), so they are not visible. But it happens quite often when turning the view and things are activated (visible) in Visual Mode. I guess sometimes something breaks when the editor is loading or buffering models or sprites or both.

[SanyaWaffles]

SlimDX's website has been down, making it hard to get official redistributables - as I pointed out in the Linux porting thread. ...

I provided alternate download links in my post 7 posts up.
Also in my tutorial about installing the DB family of editors in Windows.

Glad you did that, should help for now. Still, SlimDX seems to have been discontinued which is not a good sign.

A big problem sometimes is (and this only happens in Visual mode, never in 2D mode) that during mapping it crashes, but without a error message. The program simply closes.

Are you using loose directories? I've been having this problem with directories... for now using PK3s or WADs has circumvented the problem.

[Enjay]

I've had what Torm describes: visual mode just exiting GZDB entirely without a message or option to save or anything. I have also noticed that pressing T to switch off Things in visual mode seems to prevent this happening. (A dirty workaround might be for GZDB to remember the viewing state between sessions - i.e. were bright mode and hidden highlights enabled and what state were things toggled to. It would be a nice feature to have regardless of whether it helped with the crash or not IMO.)

In my case the crashes happened with resources loaded from WADs and PK3s. No loose directories were involved. Graphics (including sprites) are a mixture of PNG and Doom format. To give an idea of size, resource loading typically takes 23-25 seconds on startup.

Possibly related: I have noticed that in a mod with lots of sprites, having Things enabled can really slow down visual mode anyway. If I pan my view around in such a mod, there is very noticeable stuttering and pausing presumably as resources are accessed. If it was a game, it would be unplayable. It's like playing an online game with very high ping. Again, switching off Things helps here. I take it that there is no caching of resources in GZDB?

And more, in one particular mod, the key sprites had been replaced with very large hi-res versions. Even if I couldn't see them, panning around the map would cause significant stuttering when Things were enabled. Pressing T stopped the stuttering.

I was working with a custom config for the above mod anyway so I decided to try redefining the keys to use much smaller graphics and, rather than modify the WAD, I put the graphics in the same folder that GZDB loads its internal sprites from and defined the keys in the config to use these new "internal" sprites. Result: stuttering significantly reduced and I have not had a crash like Torm describes with this mod since. Worked like a charm.

Aside: I wonder if there is any merit in having a custom user folder for user-created "internal" sprites rather than mixing them with the official ones? Since discovering that it is possible to create my own "internal" sprites, I've actually found the feature very useful for other situations.

Sorry about any typos. This was done on my phone.