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.
Locked
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Did that problem start recently (i.e. when the OBJ support and more versatile texture loading was implemented), or did you have it before? From googling it looks like it's a problem with two threads accessing the same image. I can't reproduce it, but I might simply be lucky since I only got 4 threads and you got 6.
User avatar
Ozymandias81
Posts: 2062
Joined: Thu Jul 04, 2013 8:01 am
Graphics Processor: nVidia with Vulkan support
Location: Mount Olympus, Mars
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Ozymandias81 »

Mmmh well I have to say that this happens mainly only from INTERMAP, in fact if I rename it the problem doesn't occur (but not always though, may happen XD), but once it gets saved, then reload it 99% happens and only from INTERMAP though.
I fear that it become more frequent with OBJ support, even if BoA doesn't have any .obj models atm. And that thread thing is ouch, I even tried to remove old .dbs/backups and cache files...
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Since I can't reproduce it it's pretty hard to look into. The crash dump says it's crashing in ComputeNamesWidth, which was introduced in 3059+. Can you check out 3058 and see if it crashes, too?
User avatar
Ozymandias81
Posts: 2062
Joined: Thu Jul 04, 2013 8:01 am
Graphics Processor: nVidia with Vulkan support
Location: Mount Olympus, Mars
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Ozymandias81 »

Well did a test right now, and while I didn't get any issues in 2d-3d mode switch or placing actors on map, I got a crash once I have created a sector using "Start Rectangle Drawing" as I am used to (CTRL+SHIFT+D on my config)
GZCrash.txt
new crash under r3058 64bit with folder structure per resource
(14.59 KiB) Downloaded 30 times
And if I use the .pk3 file, I get some stuttering while I switch things using "T" in 3d mode, but no side effects... until then I return to 2d mode and draw a rectangle as I did before
GZCrash.txt
crash produced using .pk3 file with the same method as previous
(62.19 KiB) Downloaded 26 times
This is another attempt, setting off Models and trying to add a sector with manual linedef handling: same crash
GZCrash.txt
third and last attempt, always under 3058
(12.66 KiB) Downloaded 25 times
So with r3058 at least maps loads but I can't add any new sectors, unless I do a copy of the map, rename the wad name, open it and build some sectors: in that case it works... Very weird.
Spoiler:
PS: Using vanilla Doom 2 config UDMF and building up a new map doesn't create any issues to me, this with 3058 or 3067
Last edited by Ozymandias81 on Fri Jun 21, 2019 10:58 am, edited 1 time in total.
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Well, if it's suddenly crashing in a completely different part it might not be the program, but maybe something is wrong with your computer? Damaged RAM or something like that. Or it's simply not strong enough the handle the map.
User avatar
Ozymandias81
Posts: 2062
Joined: Thu Jul 04, 2013 8:01 am
Graphics Processor: nVidia with Vulkan support
Location: Mount Olympus, Mars
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Ozymandias81 »

It isn't sudden crash but something which happens sistematically when I do the mentioned things above, only in that case. Map isn't complicated at all, figures that I can edit C2m0_b which is one of the biggest maps on BoA... Also why switching to 3058 map is loaded correctly? I wonder :/
User avatar
Ozymandias81
Posts: 2062
Joined: Thu Jul 04, 2013 8:01 am
Graphics Processor: nVidia with Vulkan support
Location: Mount Olympus, Mars
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Ozymandias81 »

It seems I have "fixed" my issue somehow: it was coming from my GZBuilder.cfg file stored inside my %AppData/Local/Doom Builder folder.
Gonna leave here both configs, also I must say that I have removed an old SharpCompress.3.5.dll file from my GZDB folder, even if errors where occuring with it removed. Now doesn't. Thank you again for the help :D (btw I am with r3067)
GZBuilder.7z
old cfg
(8.16 KiB) Downloaded 27 times
GZBuilder.zip
new cfg, which has been practically not edit at all
(4.27 KiB) Downloaded 26 times
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

Is there any way for a user to have a bit more control over the decisions that GZDB makes when deciding which sector sidedefs should be assigned to?

I have noticed that, under certain circumstances, GZDB can get it "wrong" (i.e. it has made the wrong decision from my perspective). Structures like this seem to confuse it really quite easily:





The staggered (grey and brown) crates in particular seem to be something that causes problems. A few times in a few maps, a similar setup has ended up with much weirdness going on. The staggered crates were originally a single square sector. I added enough vertices to the lines to create the staggered shape (I hadn't even split the sector at that point). At some point while moving the vertices to create the shape, GZDB decided that every line in the surrounding area needed to be allocated to a new sector and the values for that sector were taken from another one that was not particularly close to the ones in the screenshot and had totally different properties. As a result, floor height, ceiling height and flats all changed, really messing up the entire area. Fortunately, I spotted it happening and could just use undo to fix it, but every time I tried to make the shape, same thing happened. I had almost the exact same thing happen on other parts of the map and on other maps too (map gets a clean bill of health from the error checker).

All I have to do to the above to mess it up is move one vertex a bit. When I do that, GZDB goes into "heavy thinking mode" (the busy cursor appears for a second or two) and then everything in the area has a new sector allocation.




I know that I can press Ctrl while moving the vertices and that stops the sector reallocation happening, but it stops it completely. So that means if I want to put lines/vertices on top of each other and have them merge, they won't.


The other crate structure (the green and brown one with the little grey one on top) also caused similar problems. The lower part was a single sector. When I drew a new sector in it to become a different coloured crate, again, GZDB got very confused and reallocated all the surrounding lines to a new sector in a similar way to described above.


The only way that I could figure out a solution was to save the map, open it in DeePsea, make the changes there, save and then go back to GZDB.

So, is there a way to exert more control over these decisions somehow? Generally GZDB is really good at this kind of stuff and drawing even quite complicated shapes over each other doesn't fool it at all. But these kind of "mistakes" crop up quite a bit too.
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

I've never seen that happen. Can you create (and supply) a map as small as possible and reprocude the results there?
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

I'll see what I can do when I get home from work. Chances are that deleting stuff to make a simpler map will stop the problem, but I'll see what I can do.

It's happened a fair bit for me in the last couple of weeks or so though.

BTW the map is in zdoomhexen mode in case that's relevant.
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

PM sent with a link to the map from the screenshots. Every time I tried trimming it down to something manageable, sooner or later the problem stopped happening before the map got small enough, so I just uploaded the whole thing edited to not need custom resources (all textures replaced with defaults) and to remove all things except a player 1 start spot.

The test version of the map still shows the problem and even though it is in ZDoomHexen format, copying and pasting the whole thing into UDMF still shows the problem, so it's not specific to ZDoomHexen.
User avatar
Kappes Buur
 
 
Posts: 4114
Joined: Thu Jul 17, 2003 12:19 am
Graphics Processor: nVidia (Legacy GZDoom)
Location: British Columbia, Canada
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Kappes Buur »

I sort of replicated the sectors, both in DiHF and UDMF, from your screenshots, just to see what happens on my end
Spoiler:
Moving any linedefs and/or vertices did not affect sector heights.
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

To be honest, I'm not really surprised (thanks for trying though). Trying to cut the map in my pictures down to a simple example removed the problem.

I got a PM back from boris. I'm sure he wouldn't mind me sharing this:

"It somehow screws up when tracing the sector outlines. It's a pain in the ass to debug because the map is so big. In the meantime you can fix the problem by deleting linedef 5621."

I knew that the map was likely to be problematic as a test map because of its size/complexity but I hoped that it would shed some light on the issue.

It's interesting to note that the line boris identified is just a 32 unit 2 sided line with the same sector on either side (the same sector as the crates are in) about 1100 units from the crates. Deleting it does indeed stop the problem happening in this particular location.
Wondercat57
Posts: 9
Joined: Thu Apr 06, 2017 2:45 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Wondercat57 »

I would like to make a request regarding full brightness. Sometime in the past--back when MaxEd was still working on the original, I think--there was a change to sync the 2d top down view and the 3d visual mode for full brightness. While I know I can toggle it on and off by using the B key, it quickly becomes annoying when working in dark areas that require full brightness in the 3d visual but are not as difficult to see in the 2d top down version.

Is there a way to make this sync an option?
User avatar
TheMafla
Posts: 18
Joined: Wed Jun 20, 2018 8:28 am
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by TheMafla »

Hi, I have a question. Is there a preview mode of the game? something like a window that you can have on the side where you can see a part of the map of how it would look in the game? something like what Unity has and UE4.
Locked

Return to “Abandoned/Dead Projects”