GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[Nash]

hey, I noticed an issue in DB2 & children that I fixed in DBX that I figured you should be aware of, the UDMF spec requires that unknown data in textmaps be preserved by editors that don't understand them.

https://github.com/anotak/doombuilderx/ ... 6806fbbbf4
here's my DBX commit that might work with some adaptation in GZDB-BF i think, assuming that GZDB didn't diverge too much from DB2 there
feel free to use it if it helps at all

i had a bugfix to this
https://github.com/anotak/doombuilderx/ ... d03fbb370d
in case you do use it

Why don't you send pull requests to the GZDBBF repo directly? ZZYZX is probably busy ATM but it would definitely help him lighten the load if you just sent a PR.

[anotak]

Why don't you send pull requests to the GZDBBF repo directly? ZZYZX is probably busy ATM but it would definitely help him lighten the load if you just sent a PR.

it's not a pull request and it's not GZDB-BF code that i linked, it's code from a different DB2 fork (DBX). it may or may not be compatible with GZDB-BF at all, it was just meant to be helpful if ZZYZX happens to find it to be helpful. i mainly posted informing him of the issue that GZDB-BF forgets root-level UDMF properties which the spec says it should preserve. this issue affects all DB2 children editors at the time of writing this post, though I fixed it in the github version of mine at the moment.

[Xane123]

This happened to me today:
If you look in this room at the specific direction pointed in the screenshot, the cursor becomes black

That's the same glitch I have and when I just tested and confirmed the lights are messing it up.

The subtractive light blackening glitch

I tested it by putting down a subtractive light, getting the glitch, then undo/redo. Every time the light changed to a player start, the crosshair returned to normal. When this is fixed, someone let me know as I'm not sure how easy it is to just copy my modified configuration and ACS script files in with every update...

[Batandy]

This happened to me today:
If you look in this room at the specific direction pointed in the screenshot, the cursor becomes black

That's the same glitch I have and when I just tested and confirmed the lights are messing it up.

jpg3.jpg

I tested it by putting down a subtractive light, getting the glitch, then undo/redo. Every time the light changed to a player start, the crosshair returned to normal. When this is fixed, someone let me know as I'm not sure how easy it is to just copy my modified configuration and ACS script files in with every update...

Since this has happened to me again with a new map, i think i found it: After i put subtractive lights it seemed to work fine, the issue started when i put actors with 3d models inside the map, looking at the models, the renderer glitches out with the subtractive maps. Disabling the "Model rendering mode" fixed it.
In short, 3d models and subtractive lights seems to clash and glitch out the renderer

[Rachael]

I have one suggestion that's going to sound wild and crazy, but bear with me:

Change all default textures to "-NOFLAT-". It's easy enough making a simple wad containing this lump for vanilla compatibility, meanwhile every source port that supports missing textures will properly show that hey, there's a missing texture here.

The main reason I suggest this is because of the discussion taking place in this thread and I think it really brings up a very good point that we shy away from these perfectly good textures just because they're default, and while it may be too late to "fix" such a stigma it's better to try earlier on even if it is late, than later.

Plus, that reuses the texture in more of a sense of what it was meant for, anyway.

[Accensus]

I second this. It would mostly solve the issue of hard-to-find missing textures. Inb4 "use missing textures check" - that one sucks because you have to check it after every vertical floor adjustment, because it doesn't show hidden textures. The "-NOFLAT-" tex is easier to see amongst proper textures, while the HOM tends to blend in with the surrounding walls.

[Kappes Buur]

Change all default textures to "-NOFLAT-". It's easy enough making a simple wad containing this lump for vanilla compatibility, ....

That is even easier, no need to make a separate resource wad
viewtopic.php?f=44&t=54957&start=645#p1021909

[Rachael]

The resource wad would be to prevent Vanilla from crashing out to DOS when it can't find -NOFLAT-.

Source ports don't need it - they usually don't have a problem with it because they have better error handling and they can substitute in their own "missing texture" if -NOFLAT- is not found. (I'm just using GZDoom's version of it because it's already there, it's available, and it won't flood the console with errors, although I suppose one may actually want that)

[printz]

I have one suggestion that's going to sound wild and crazy, but bear with me:

Change all default textures to "-NOFLAT-". It's easy enough making a simple wad containing this lump for vanilla compatibility, meanwhile every source port that supports missing textures will properly show that hey, there's a missing texture here.

The main reason I suggest this is because of the discussion taking place in this thread and I think it really brings up a very good point that we shy away from these perfectly good textures just because they're default, and while it may be too late to "fix" such a stigma it's better to try earlier on even if it is late, than later.

Plus, that reuses the texture in more of a sense of what it was meant for, anyway.

God please no. I prefer my test maps to have sane textures, not garbage. Besides, I see it as plain weird that you consider default textures compromised. I never do that when looking at others' wads and you shouldn't either. Neither if you're a map author making maps with these default textures as a possibility...

[Rachael]

God please no. I prefer my test maps to have sane textures, not garbage. Besides, I see it as plain weird that you consider default textures compromised. I never do that when looking at others' wads and you shouldn't either.

You can always change the defaults back in the menu.

Yes - the default textures are compromised. I do not do enough mapping, myself, to "see it" in others' works. But I know where those people are coming from, having played a lot with DN3D's Build in my earlier days. Texture 0 in Duke Nukem 3D looks like total ass - not because it's a bad texture but it's because it's the default one that appears in Build. So yeah, I think the kind of change I proposed is needed. STARTAN2/CEIL1_1/FLOOR0_1 are good textures. There's no need to trash them by making them a default.

[printz]

We're the majority who consider that the default textures are fine. So make it an opt-in feature, not opt-out.

[Gez]

Anotak's DBX has random default textures, and I think it's a cool idea.

[Rachael]

We're the majority who consider that the default textures are fine. So make it an opt-in feature, not opt-out.

It's already opt-in. And where did you get the idea you're in the "majority"?

[abbuw]

There's two really annoying bugs I've been running into.

If you happen to be using vertex slope things, they don't show the sloping until you toggle enhanced effects off and on.

---

The roll of a flatsprite isn't consistent to GZDoom. they seem to be flipped around. Here's a map if you need it.

---

[Kappes Buur]

If you happen to be using vertex slope things, they don't show the sloping until you toggle enhanced effects off and on.

That broke after r2986.