GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
How do I migrate to this fork?
I was thinking maybe put its updater in the original GZDB's folder and run it?
I was thinking maybe put its updater in the original GZDB's folder and run it?
- 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
If you have been using DB2 or GZDB successfully then simply download from
https://devbuilds.drdteam.org/gzdbbf/ and un7zip into a folder.
I find it best to have a dedicated folder for each version.
https://devbuilds.drdteam.org/gzdbbf/ and un7zip into a folder.
I find it best to have a dedicated folder for each version.
Spoiler:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
@ZZYZX: https://github.com/coelckers/gzdoom/com ... 613c5a0a27 <-- this commit finally makes proper light flags instead of the old piggybacking hack, should GZDB-BF be adjusted for this? If yes will submit to the tracker. But I'd rather ask first.
I remember you had some difficulties when I asked for visual support for inherited dynamic lights, not sure if this change is relevant or not
I remember you had some difficulties when I asked for visual support for inherited dynamic lights, not sure if this change is relevant or not
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
This is not relevant. Purely backend change without any consequences on the DECORATE side from what I see.
Why are the flag names changed? What about people who have used the old flags? These exist, both in ZScript and DECORATE. Graf ∦ backwards compatibility.
Why are the flag names changed? What about people who have used the old flags? These exist, both in ZScript and DECORATE. Graf ∦ backwards compatibility.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Only DONTLIGHTSELF/SEESDAGGER really needed to be changed, though.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Got another strange thing going on that again I'm not sure if it's been fixed before or not. I am still on R2734 of normal GZDoom Builder, so you know it may be old.
Anyway, basically if I have imported my own things with sprites I have converted with SLADE, I get this cyan aliasing around the outside of the sprites. Note that this only happens with sprites I have edited in some way (using MS Paint) with a cyan background color, imported into SLADE, and converted.
Sprites from other things and the IWADs do not do this, they alias but they do so cleanly. It also only happens as you zoom out and the thing's display sprite gets smaller. Somehow GZDoom Builder thinks there is a cyan background still or something even though it was removed with SLADE during the conversion. I should also note I started with a BMP and converted it into transparent PNG.
Here's an image of what I mean (leftmost is far enough out to see it, center is the same thing zoomed in, and the rightmost is zooming in close in the editor when it looks normal):
Anyway, basically if I have imported my own things with sprites I have converted with SLADE, I get this cyan aliasing around the outside of the sprites. Note that this only happens with sprites I have edited in some way (using MS Paint) with a cyan background color, imported into SLADE, and converted.
Sprites from other things and the IWADs do not do this, they alias but they do so cleanly. It also only happens as you zoom out and the thing's display sprite gets smaller. Somehow GZDoom Builder thinks there is a cyan background still or something even though it was removed with SLADE during the conversion. I should also note I started with a BMP and converted it into transparent PNG.
Here's an image of what I mean (leftmost is far enough out to see it, center is the same thing zoomed in, and the rightmost is zooming in close in the editor when it looks normal):
Spoiler:
Last edited by Nevander on Tue Jun 27, 2017 3:12 pm, edited 2 times in total.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Does enabling/disabling high quality help? Wait... R-what? 734? That's like 2000 commits behind MaxED's latest version as well...
Well that explains it. Try the new one in a separate directory and see if it works.
Well that explains it. Try the new one in a separate directory and see if it works.
- 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
Oh, good one.Nevander wrote:.... I am still on R734 of normal GZDoom Builder, so you know it may be old.
r734 refers to a build of Doombuilder2 (2009-01-16) when GZDoomBuilder was nary a twinkle in some programmer's eye.
GZDoomBuilder was officially established with
Code: Select all
[r1494] by codeimp 2012-04-17 07:26:08
// Created branch for MaxED's GZDoom Builder. (starting revision 1493)
Take ZZYZX's advice and use the latest GZDB-BF.
Since DB2 works for you there should be no problem.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
RIP me. I missed a "2." It should have said R2734.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Is this where to ask for feature requests and/or report bugs? *(see EDIT)
If the Visual Mode would show Transfer Heights like it does 3D Floors and slopes, that would make it even more awesome.
When I load my map using the Zandronum Doom2 (UDMF) config, custom flats loaded from a pk3 won't show in the Visual Mode, nor in the Edit Sector box (but they do show in the Browse Flats box), but when I use the ZDoom Doom2 (UDMF) config, they display just fine, so it is probably a config file error.
*EDIT: I asked this question because it somehow escaped my notice that there was more than one page. It made me think that with so little discussion here, it might not be the right place to talk about GZDoom Builder. I feel a little bit silly now, but I'll leave this in the name of openness and honesty.
If the Visual Mode would show Transfer Heights like it does 3D Floors and slopes, that would make it even more awesome.
When I load my map using the Zandronum Doom2 (UDMF) config, custom flats loaded from a pk3 won't show in the Visual Mode, nor in the Edit Sector box (but they do show in the Browse Flats box), but when I use the ZDoom Doom2 (UDMF) config, they display just fine, so it is probably a config file error.
*EDIT: I asked this question because it somehow escaped my notice that there was more than one page. It made me think that with so little discussion here, it might not be the right place to talk about GZDoom Builder. I feel a little bit silly now, but I'll leave this in the name of openness and honesty.
-
- Posts: 9
- Joined: Thu Apr 06, 2017 2:45 am
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Is anyone else having problems with their resources? I have the resources setup and pulled from the correct folders on my computer, but I keep getting error messages saying that nothing is being found. I clear all of that out and when I get to the mapping section, every texture and object on the map comes up missing. I am currently using r2980 which is the most up-to-date.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I forgot a request: Please add the ability to edit maps inside a pk3. I know that's not trivial, but I also know that it is totally doable. If it helps, you can assume that the pk3 is properly configured with one-map wads in the maps folder, but it would be even better if you search the pk3 for wads and search those wads for maps because you know that not everyone will configure their pk3 correctly. Then again you might be doing them a favor by forcing them to configure their pk3 correctly.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
This is probably possible.Empyre wrote:If the Visual Mode would show Transfer Heights like it does 3D Floors and slopes, that would make it even more awesome.
This is related to numerous attempts to make GZDB behave like GZDoom with long texture names and Doom format flats. GZDoom is really [censored word] and cannot detect the format of Doom flats if they are using long texture name... (for whatever reason — GZDB can). Anyway, I'll see.Empyre wrote:When I load my map using the Zandronum Doom2 (UDMF) config, custom flats loaded from a pk3 won't show in the Visual Mode, nor in the Edit Sector box (but they do show in the Browse Flats box), but when I use the ZDoom Doom2 (UDMF) config, they display just fine, so it is probably a config file error.
This is planned, and even easy to implement, but improbable to happen right now given the amount of free time that I currently have. However, currently it's relatively easy to edit unpacked PK3s with both GZDB (just open the wad) and SLADE ("open directory" option).Empyre wrote:I forgot a request: Please add the ability to edit maps inside a pk3. I know that's not trivial, but I also know that it is totally doable. If it helps, you can assume that the pk3 is properly configured with one-map wads in the maps folder, but it would be even better if you search the pk3 for wads and search those wads for maps because you know that not everyone will configure their pk3 correctly. Then again you might be doing them a favor by forcing them to configure their pk3 correctly.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
The flats in question come from cc4-tex, and have the regular 8-character names, like GROUND22 and FLOOR72B. They display just fine in-game in Zandronum. They display in GZDoom Builder when I use the ZDoom UDMF config, but not when I use the Zandronum UDMF config, and even Map Analysis Mode complains about all the unknown flats when using the Zandronum UDMF config, but not when using the ZDoom UDMF config. Also, Doom Builder 2 has no problem with the flats, but it doesn't have a Zandronum-specific UDMF config.ZZYZX wrote:This is related to numerous attempts to make GZDB behave like GZDoom with long texture names and Doom format flats. GZDoom is really [censored word] and cannot detect the format of Doom flats if they are using long texture name... (for whatever reason — GZDB can). Anyway, I'll see.Empyre wrote:When I load my map using the Zandronum Doom2 (UDMF) config, custom flats loaded from a pk3 won't show in the Visual Mode, nor in the Edit Sector box (but they do show in the Browse Flats box), but when I use the ZDoom Doom2 (UDMF) config, they display just fine, so it is probably a config file error.
I would prefer to use the Zandronum UDMF config to try to avoid using features that Zandronum doesn't support yet.