Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Phobus

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

Recommended Posts

Posted (edited)

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 by Phobus

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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?

Share this post


Link to post
Posted (edited)

@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 by Phobus

Share this post


Link to post
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.

Share this post


Link to post

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

Spoiler

qYRih1h.png

 

but I digress.

 

I added a bunch of linedefs into your map

Spoiler

RhtPMns.png

 

and saved. No crash, it went very smoothly.

Share this post


Link to post
Posted (edited)

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 by Phobus

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)

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 by Phobus

Share this post


Link to post
Posted (edited)

ZenNode is somewhat outdated,

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

 

Spoiler

MFKvQak.png

 

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×