GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Any utility that assists in the creation of mods, assets, etc, go here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Fri Jun 21, 2019 10:08 am

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.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Ozymandias81 » Fri Jun 21, 2019 10:15 am

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...
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 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Fri Jun 21, 2019 10:30 am

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?
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Ozymandias81 » Fri Jun 21, 2019 11:38 am

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 10 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 8 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 10 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 11:58 am, edited 1 time in total.
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 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Fri Jun 21, 2019 11:58 am

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.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Ozymandias81 » Fri Jun 21, 2019 12:01 pm

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
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 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Ozymandias81 » Fri Jun 21, 2019 2:12 pm

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 8 times

GZBuilder.zip
new cfg, which has been practically not edit at all
(4.27 KiB) Downloaded 9 times
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 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Mon Jun 24, 2019 4:19 pm

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.
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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Mon Jun 24, 2019 11:07 pm

I've never seen that happen. Can you create (and supply) a map as small as possible and reprocude the results there?
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Tue Jun 25, 2019 1:06 am

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Tue Jun 25, 2019 12:20 pm

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Tue Jun 25, 2019 3:34 pm

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Tue Jun 25, 2019 4:01 pm

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.
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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Wondercat57 » Fri Jun 28, 2019 3:07 pm

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?
Wondercat57
 
Joined: 06 Apr 2017

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby TheMafla » Sun Jun 30, 2019 12:34 pm

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.
User avatar
TheMafla
 
Joined: 20 Jun 2018
Discord: None
Twitch ID: None

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: No registered users and 1 guest