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 wrote:i had a bugfix to thisanotak wrote: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
https://github.com/anotak/doombuilderx/ ... d03fbb370d
in case you do use it
GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.Nash wrote: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.
- Xane123
- Posts: 165
- Joined: Tue Nov 24, 2015 1:58 pm
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Inwood, WV
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
That's the same glitch I have and when I just tested and confirmed the lights are messing it up. 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 wrote:This happened to me today:
If you look in this room at the specific direction pointed in the screenshot, the cursor becomes black
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.Xane123 wrote:That's the same glitch I have and when I just tested and confirmed the lights are messing it up. 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 wrote:This happened to me today:
If you look in this room at the specific direction pointed in the screenshot, the cursor becomes black
In short, 3d models and subtractive lights seems to clash and glitch out the renderer
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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
-
- Posts: 4122
- 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
That is even easier, no need to make a separate resource wadRachael wrote: Change all default textures to "-NOFLAT-". It's easy enough making a simple wad containing this lump for vanilla compatibility, ....
viewtopic.php?f=44&t=54957&start=645#p1021909
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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)
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)
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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 wrote: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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
You can always change the defaults back in the menu.printz wrote: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.
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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
We're the majority who consider that the default textures are fine. So make it an opt-in feature, not opt-out.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Anotak's DBX has random default textures, and I think it's a cool idea.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
It's already opt-in. And where did you get the idea you're in the "majority"?printz wrote:We're the majority who consider that the default textures are fine. So make it an opt-in feature, not opt-out.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
If you happen to be using vertex slope things, they don't show the sloping until you toggle enhanced effects off and on.
Spoiler: ScreenshotsThe roll of a flatsprite isn't consistent to GZDoom. they seem to be flipped around. Here's a map if you need it.
Spoiler: Screenshots
- Kappes Buur
-
- Posts: 4122
- 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
That broke after r2986.abbuw wrote: If you happen to be using vertex slope things, they don't show the sloping until you toggle enhanced effects off and on.