GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[Sarah]

GENTEK, I'm not personally available to help more than my initial suggestion; your response is a bit ambiguous, do you mean loading the engine pk3 failed, or do you mean that loading the engine pk3 with your project's resources didn't solve your problem? In either case, let's not clutter up this topic anymore, if I were you I'd ask for help here; I suspect this is an issue that is contributing to the ZScript fear.

[GENTEK]

When I use GZDoom.PK3 + MyMOD.PK3 I don't see my Actors in GZDB! I will try the link thanks again dude!

[Xaser]

Random left-field suggestion: Since this fork seems to have caught on, how about a project name update? "GZDoomBuilder-Bugfix" isn't exactly the most memorable thing in the world.

I don't really have any suggestions aside from maybe "GZDB+" -- or maybe be cheeky and call it "QZDoom Builder" if Rachael agrees+permits.


[/me erects a shed and posts a "COLORS WANTED" sign. ;]

[ZZYZX]

1. As for gzdoom.pk3 — I'm thinking about either picking up the engine PK3 or shipping at least the zscript.txt hierarchy with GZDB. That'll be done soon.
It might as well work without doing that but I'll have to understand why exactly nothing works without gzdoom.pk3 and how many things depend on it (aside from the x11r6 color parser).

2. As for the name — ZZDoomBuilder?
Note that even if it gets renamed, all the links (DRDTeam, GitHub) will remain as-is for backward compatibility, otherwise people won't be able to update from ancient versions or report bugs properly.

[Sarah]

ZDoomBuilder? More or less just state that this editor is for ZDoom and it's child ports?

One issue I see with picking up the pk3 is that some of us don't use mainline builds. My own fork of GZD-GPL uses "engine.pk3". Perhaps a master specification option under Map Options that lets us point to whatever engine pk3 we need to use?

[ZZYZX]

ZZDoomBuilder, not ZDoomBuilder. ZZ -------------------------------------------------------------------->

Perhaps a master specification option under Map Options that lets us point to whatever engine pk3 we need to use?

And then it's no different from the current way of pointing it to an archive.
I personally think that picking up the archive called the same as the exe file (i.e. gzdoom.pk3 for gzdoom.exe, zdoom.pk3 for zdoom.exe, zandronum.pk3 for zandronum.exe, zdaemon.wad for zdaemon.exe...) would work, with additional check that you don't have these files loaded manually (by checking the directory/lump structure to match the system archives, gzdoom.pk3 is quite distinct from user PK3s, if you look at it closely).

Alternatively, I might as well actually make an error message stating that you need the main archive to work. The same as the current message "you don't have IWAD loaded".
The problem here is that with some ports (e.g. Zandronum) due to how weird their main archives are, many warnings are produced (namely the duplicate SNDINFO definitions).
So the only way here would be ignoring warnings during parsing of the internal stuff unless explicitly enabled in settings.

+it actually only breaks in specific cases without the main archive: if you use named colors (like "blue" instead of 0000FF) or if you add DECORATE/ZScript (especially ZScript, DECORATE works somehow, but ZScript needs proper inheritance data).
This actually might be a bug with the ZScript parser, will need to check if it's possible to use classes from the game configuration for ineritance.

[Sarah]

Pardon the slightly testy response I think I misread you, you seem to be aware that some of us (me) break the rules and don't do things by the book.
What I will re-say is that I'd prefer to just see a warning for not having an engine pk3 loaded (zdoom, gzdoom, ect.). I don't use the testing features, or autoload resources, that's what the resource menu is for, imo. So everything I load gets added there and saved to the .dbs file. I'd prefer to see that not change.

---

So I don't use GZDB's testing configuration settings either. Never have, not even in my earliest of DB use days, which means my copy of GZDB does not know where a copy of any engine is. I do not autoload an IWAD, ever. Period. And that does not work in my workflow anyway, I must build pk3s and run those. Also, what about those of us with custom builds with engine pk3s that aren't named the same thing as the executable?

Although, I'm not sure if testing a map while loading resources with that map in it would be an issue or not; my first thought is yes.

Essentially an editor that takes a purist approach to Doom is going to become an editor that I can't use. I'm just fine with some sort of warning when not loading an engine pk3 and an expectation of that pk3 being added to the resource list.

[ZZYZX]

The main problem with detecting a missing master engine file is that it's not "always required". It's "required if you do X and Y". For instance, write "blue" instead of "0000FF" and expect a valid color.
The ZScript inheritance I'll try to fix, it seems that something broke in the code that should allow it to inherit from the game configuration.

[Tormentor667]

Still getting a lot of random crashes in various circumstances. Most notably when pasting textures I think.

The problem is: It crashes without a crash log.

[ZZYZX]

That's most likely not a problem with GZDB at all. Usually this means problems on the native side (bad plugins using native code, bad drivers, bad D3D, bad Windows, bad something else...)
GZDB from what I remember cannot generate such error since it's completely written in C# and thus should always provide a stack trace. Some esoteric multithreading errors can generate it, I'll check.
Does it happen when editing BoA maps?

[printz]

Does GZDBBF continue having the autoupdate newsflash from GZDB? It's a very good feature; it saves me the time of going to drdteam, downloading, unpacking and replacing the files. I only just started using GZDBBF now; I may see it soon I guess.

[ZZYZX]

It does. It's just that I haven't made many updates lately due to being occupied with other things (namely work and ZScript events/scopes).

[Tormentor667]

That's most likely not a problem with GZDB at all.

This at least helps me where to look. Though it worked perfect a few weeks ago without any crashes, that's what makes me suspicious. It happens when editing BoA, yes, and I know there huge maps to deal with, currently C2M5, maybe it's a memory problem or something else in Visual Mode.

[ZZYZX]

What's the memory usage for that map?

[Nash]

GZDB doesn't have the latest ACC definitions (looking to use StrArg and ScriptCall)