GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Mon Jul 29, 2019 7:21 pm

Tormentor667 wrote:And another one:


How did you install r3072?
By ways of the automatic updater?
Manually?
What was the previous version which did work?
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Wed Jul 31, 2019 10:58 pm

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".
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Wed Jul 31, 2019 11:31 pm

SanyaWaffles wrote: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.
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Wed Jul 31, 2019 11:41 pm

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.
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Thu Aug 01, 2019 12:11 am

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?
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Thu Aug 01, 2019 3:24 am

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.
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Ozymandias81 » Thu Aug 01, 2019 6:06 am

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
User avatar
Ozymandias81
Doom is a State of Mind... Out of Control.
 
Joined: 04 Jul 2013
Location: Mount Olympus, Mars
Github ID: Ozymandias81
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Thu Aug 01, 2019 6:56 pm

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.
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Thu Aug 01, 2019 7:53 pm

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.
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Graf Zahl » Wed Aug 07, 2019 12:29 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Thu Aug 08, 2019 7:12 pm

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.
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Thu Aug 08, 2019 10:39 pm

SanyaWaffles wrote: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.
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Tormentor667 » Thu Aug 08, 2019 11:46 pm

Kappes Buur wrote: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.
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Thu Aug 08, 2019 11:51 pm

Kappes Buur wrote:
SanyaWaffles wrote: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.

Tormentor667 wrote: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.
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Fri Aug 09, 2019 3:56 am

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.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 3 guests