[Fixed] GZDoomBuilder-bugfix becoming unresponsive when saving (bsp-w32 issue)

[Phobus]

I'm currently on 2.3.0.3067 (57054c1), but I've seen this issue with other version over the last few years too. Basically, the editor is working just fine and then, seemingly arbitrarily, I'll click "Save" and GZDB-bf will think about it for a little before becoming unresponsive, needing to be closed and thus losing me my last x minutes of work. The map in question is then reliably impossible to save in GZDB-bf when a comparable level of editing is done, although sometimes I can save minor progress before hitting this problem again.

 

This seems to be limited to Doom format mapping (using the Doom 2 config, for example), whilst I've not noticed this happening in UDMF and haven't used HeXen format recently enough to test. If I go to DBX, the map can be edited and saved just fine and this changed map can normally be worked on more in GZDB-bf again afterwards.

 

Does anybody else suffer this problem? If I get another map I can reliably reproduce this problem with, I'll try and upload it so that this can be more widely tested.

Edited July 16, 2019 by Phobus

[zzzornbringer]

i've had some issues with configuration files, because i just copied over the newest bugfix version over a pretty old version. maybe you could try a clean install, make sure to save your key configuration, if you have any keys custom bound. i fixed the issue by deleting all configuration files and just copying over the current version again. don't have any other issues thus far.

[Kappes Buur]

7 hours ago, Phobus said:

I'm currently on 2.3.0.3067 (57054c1), but I've seen this issue with other version over the last few years too. ....

 

What operating system are you running?

Which version, x32 or x64?

 

Just some random thoughts ...

GZDBBF_r3067 must be/is compiled with .NET Framework 4.6 since version r3018. Therefore it is not compatible with versions before that. Old versions were all for a 32 bit OS, but the new versions are downloadable for either x32 or x64.

 

Because of the update to .NET Framework 4.6 it is necessary to also upgrade your OS and the SlimDX version. The editor should not be installed in either Project Files or Project Files (x86) but in a dedicated directory.

 

The configuration file is stored in AppData/Local.

[Phobus]

I said I would, so here you go:

 

An example

 

Adding 11 or more linedefs to this map (whether by splitting lines or adding sectors) reliably crashes this in GZDoomBuilder-bugfix. If somebody downloads this and has a go, do they get the same result?

[Phobus]

@Kappes Buur - thanks for replying! I'm on Windows 10 Pro 64-bit (OS build 17134.885 currently, according to the "About" section). The editor is installed in my Doom folder, which is outside of any Program Files folders on that drive. I don't believe I'm out of date with anything, but I'll check SlimDX now. Bear in mind that the program runs just fine until it arbitrarily stops responding whilst saving, and I've not noticed this with UDMF mapping so far, just Doom format, so I think it's something a bit deeper in the program than what I'm running it on.

 

Edit: I've just updated my SlimDX from the link you provided. This hasn't made a difference to the saving problem, although I had to breach 661 lines this time to have saving make the program go unresponsive.

 

Edit again: Switching to "Boom: Doom 2 (Doom format)" seems to have solved the problem, which further confuses me. I just added another 200+ lines, saving frequently, with no freezing. I'll have to keep working on the map in this format and see if the problem comes up again, or see if making another map in "Doom: Doom 2 (Doom format)" causes the same problem to arise (which I believe it will and did before).

Edited July 16, 2019 by Phobus

[boris]

14 minutes ago, Phobus said:

I said I would, so here you go:

 

An example

 

Adding 11 or more linedefs to this map (whether by splitting lines or adding sectors) reliably crashes this in GZDoomBuilder-bugfix. If somebody downloads this and has a go, do they get the same result?

Works fine for me.

[Kappes Buur]

What a coincident, just the other day I was doing this

Spoiler

 

but I digress.

 

I added a bunch of linedefs into your map

Spoiler

 

and saved. No crash, it went very smoothly.

[Phobus]

And if you tried the same thing in Doom: Doom 2 (Doom format), do you get the same result? If not, then this is obviously something I'll just have to work around, because if it can't be reproduced reliably, it can't be fixed.

 

I just opened up a different, finished map in Doom: Doom 2 (Doom format) and tried to change a thing type and, when saving, GZDB-bf became unresponsive again. It's as though it can't save a map file over a certain size in that format for me.

Edited July 16, 2019 by Phobus

[Kappes Buur]

Spoiler

 

Same result, no crash, no slow-down.

 

[Phobus]

Hmm... Thanks for checking. This is a problem with my setup, installation or something, then.

[Kappes Buur]

Unless you have a custom setup, in which case save the file somewhere first, I would delete the config file, GZBuilder.cfg, in AppData/Local and let GZDBBF generate a new one. Then either set up your settings again from F5 or copy from the saved file.

 

While there, take a look at the logfile, or upload it. It might tell you whats going on.

[Phobus]

I would suggest, having looked at the log, that the issue is actually the nodebuilder, as the last thing in the log is GZDoomBuilder telling bsp-w32 to compile the nodes in the temporary build file and output to a different temporary file. I shall try and a different nodebuilder, as that is the key difference between my Doom configs and my Boom ones. Thanks for pointing me there, I didn't think to look for any log files or anything.

 

Sure enough, changing to ZenNode, like the Boom configurations have, fixes the problem. Interestingly, DeepBSP was also no good for me. So, the program is fine after all, but my Node Builder config was doing me over. How very 90s of me...

 

Thanks for your help!

Edited July 16, 2019 by Phobus

[Kappes Buur]

ZenNode is somewhat outdated,

you could try ZokumBSP for DOOM/2 or BOOM/2 and ZDBSP for all the GZDoom configs.

 

Spoiler

 

[Phobus]

Thanks for that link - I've downloaded it and had a good look through the accompanying text file. Interesting stuff. I'll be sure to make use of it in place of ZenNode as you've suggested.