Page 36 of 97

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Fri Jun 16, 2017 11:46 pm
by VGA
How do I migrate to this fork?

I was thinking maybe put its updater in the original GZDB's folder and run it? :D

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sat Jun 17, 2017 1:03 am
by Kappes Buur
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.
Spoiler:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jun 18, 2017 2:28 am
by Nash
@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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jun 18, 2017 11:54 pm
by ZZYZX
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Tue Jun 20, 2017 1:09 am
by VGA
They changed them to fix this:

viewtopic.php?f=7&t=56938

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Tue Jun 20, 2017 8:11 am
by Gez
Only DONTLIGHTSELF/SEESDAGGER really needed to be changed, though.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jun 25, 2017 1:37 am
by Nevander
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):
Spoiler:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jun 25, 2017 10:10 am
by ZZYZX
Does enabling/disabling high quality help? Wait... R-what? 734? :shock: :shock: :shock: 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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Mon Jun 26, 2017 5:55 pm
by Kappes Buur
Nevander wrote:.... I am still on R734 of normal GZDoom Builder, so you know it may be old.
Oh, good one. :)

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)         
Because it is that old, Codeimp or any other programmer no longer even want to look at it anymore.

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

Posted: Tue Jun 27, 2017 3:12 pm
by Nevander
RIP me. I missed a "2." It should have said R2734.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Wed Jun 28, 2017 9:07 pm
by Empyre
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Thu Jun 29, 2017 8:04 am
by Wondercat57
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

Posted: Thu Jun 29, 2017 9:36 am
by Empyre
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

Posted: Thu Jun 29, 2017 7:58 pm
by ZZYZX
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 probably possible.
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 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: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.
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).

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Thu Jun 29, 2017 8:52 pm
by Empyre
ZZYZX wrote:
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 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.
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.

I would prefer to use the Zandronum UDMF config to try to avoid using features that Zandronum doesn't support yet.