GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[FoptionMapping]

I mean the one I showed and then MaxED 'left'.

[ZZYZX]

Are you referring to this blurry screenshot?
Texture viewing area was changed already. To enable it, click "Classic view" on the bottom of the texture selection window.
Or do you want the tree view on the left too?

[FoptionMapping]

The tree on the left as well, please.

[Armaetus]

I'll be keeping an eye on this.

[ZZYZX]

Updated the build.
Current version should have some basic support for ZScript, that is, at least loading the default actors and non-tricky custom actors.
$-comments aren't yet supported.
GLDEFS aren't yet supported (but almost).
The parser is quite grammar nazi compared to the DECORATE one and will report any weird code found (except expressions and function blocks).
I'm currently testing it against gzdoom.pk3 and Doom4Doom beta.

Feel free to report all kinds of dumb behavior here. If it's completely broken, use the previous build (can be found in the topic, first link), and report.
Also, DECORATE code was moved around but not changed. If DECORATE parsing broke, it's a reason to report it too.

Also, the parser does a lot of redundant parsing right now, that's to be removed/kept depending on what Graf answers in ZScript discussion thread on the user variables question.
If it's UNBEARABLY slow for anyone, especially compared to the old DECORATE parser, report.

P.S. Had a lot of fun with obscure ZScript keywords. Anyone knows what "meta" or "slow" is? I mean, I know what "fast" is, but "slow"?
Had a lot of fun with States block as well, more specifically with the fact that it allows [\]#- in a sprite/frame name. Ew.

[Blue Shadow]

Anyone knows what "meta" or "slow" is? I mean, I know what "fast" is, but "slow"?

I don't know what meta means, but for slow:
https://zdoom.org/wiki/Actor_states#State_keywords

[ZZYZX]

Thanks, didn't know these identifiers were aggregated somewhere.

[printz]

Just a bit of warning: if MaxED revisits the ZDoom forums and sees you're maintaining GZDB, he may feel even less motivated to retake the helm, since someone else (ZZYZX) just took the responsibility, letting him be free to do anything else. Isn't GZDB pretty much feature-complete by now? His presence was good because he would update the game configurations and fix bugs, but what else was needed? Changing the texture browser layout (something which myself I haven't noticed, but I'm not a big mapper) surely sounds like "jumping the shark", so it was probably over anyway.

[ZZYZX]

Isn't GZDB pretty much feature-complete by now?

ZScript, actually.
I personally already have this in my WADs, plus Doom4Doom has a mapping subproject that also uses ZScript actively, plus devbuild gzdoom.pk3 uses ZScript as well, so actors inheriting from this won't load in an entirely correct way.
In fact this is the first fundamental change to the actor loading system, since the old DECORATE subsystem was written ages ago by CodeImp and worked ever since.

There is also this new script editor, which sounded like a step towards being able to edit non-BEHAVIOR scripts from GZDB, say, if I have map-specific ZScript lumps, or custom scripting lumps (lua, python, whatever).
There are also various small optimizations (see the first post, under todo).
And even if we forget about all that, there's still a possibility of GZDoom receiving some fancy new features, so pretty much if MaxED wanted to do something useful, there are still options ;P

As for the texture selection window, they say it's actually better for people who use long texture names.
I'd say yes, since the new texture selection supports variable texture rectangle width and always shows the full name.
The only problem with that was that MaxED didn't bother with adjusting the style to match the original one.

P.S. In case someone saw the earlier version of this post, I'm a bit sleepy and don't read posts properly. Edited.

[boris]

Isn't GZDB pretty much feature-complete by now?

I don't see how an editor for an engine that's constantly enhanced can ever be feature complete. IIRC CodeImp regarded DB2 as feature complete, after all you can do pretty much everything in DB2 you can do in GZDB. Thanks to MaxED's great work it is just much much easier. In fact the leap between DB2 and GZDB feels like the leap from DB1 to DB2.

[Armaetus]

I get this while loading up my in-development map Hellbrary V2: MAPINFO error in "hellbra2.wad\MAPINFO:3", line 6. Failed to parse outsidefog value from string "gray".

Here is what the MAPINFO looks like:

Code: Select all • Expand view

// Hellbrary V2.0 by Glaice/Mr. Chris

map MAP18 "Hellbrary V2.0"
{
    lightning
   OutsideFog = "Gray"
   OutsideFogDensity = "180"
   titlepatch = "CWILV17"
   next = "MAP19"
   secretnext = "MAP19"
   sky1 = "SKY2"
   cluster = 7
   par = 150
   music = "$MUSIC_ROMERO"
}


Why is GZDBBF triggering this when the information appears correct?

[printz]

Isn't GZDB pretty much feature-complete by now?

I don't see how an editor for an engine that's constantly enhanced can ever be feature complete. IIRC CodeImp regarded DB2 as feature complete, after all you can do pretty much everything in DB2 you can do in GZDB. Thanks to MaxED's great work it is just much much easier. In fact the leap between DB2 and GZDB feels like the leap from DB1 to DB2.

Two words: plug-ins. You are one who writes them. Stuff like ZSCRIPT sound like something which can be added via plug-ins.

[Jaxxoon R]

Ah, you're doing the lord's work, ZZYZX.

[ZZYZX]

I get this while loading up my in-development map Hellbrary V2: MAPINFO error in "hellbra2.wad\MAPINFO:3", line 6. Failed to parse outsidefog value from string "gray".

When I copy this code I get a different error:

Code: Select all • Expand view

   MAPINFO error in "...\mapinfo.txt", line 81. Expected outsidefogdensity value, but got ""180"".

And this is because GZDB's text lump parser doesn't conform to ZDoom's one, in that it won't take a string where int is expected. Fixed in this particular place though.
As for the original error, it might be because it's case sensitive when it shouldn't be (since that particular color is declared as "gray", and not "Gray"). The new build is supposed to fix that too, idk.
If it doesn't, then you should load gzdoom.pk3 with your resources, since that's where color names come from.

Two words: plug-ins. You are one who writes them. Stuff like ZSCRIPT sound like something which can be added via plug-ins.

Actor loading code is (was, now a bit less) very deeply rooted into the DECORATE parser, up to having parser code inside the constructor of ActorStructure (it's an object used for storing ZDoom data for an actor) and that being a sealed class.
I honestly don't think it's possible to write another actor loading system that'd fire BEFORE the DECORATE parser and give actors to it, using plugins. On the other side maybe it is now, as I split the actor storage from actor parsing.

[Hell Theatre]

Two words: plug-ins. You are one who writes them. Stuff like ZSCRIPT sound like something which can be added via plug-ins.

Actor loading code is (was, now a bit less) very deeply rooted into the DECORATE parser, up to having parser code inside the constructor of ActorStructure (it's an object used for storing ZDoom data for an actor) and that being a sealed class.
I honestly don't think it's possible to write another actor loading system that'd fire BEFORE the DECORATE parser and give actors to it, using plugins. On the other side maybe it is now, as I split the actor storage from actor parsing.

From what I gathered this seems to be the biggest issue with GZDB - parts of it were done with very little foresight or compatibility concerns. Good to see that you are trying to address them.

With all due respect to MaxEd, from what he himself repeatedly said, I had the feeling he was coding himself into a corner with increasing difficulty to get out.