Page 2 of 97
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sun Jan 15, 2017 6:45 pm
by FoptionMapping
I mean the one I showed and then MaxED 'left'.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sun Jan 15, 2017 6:53 pm
by 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?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sun Jan 15, 2017 7:01 pm
by FoptionMapping
The tree on the left as well, please.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sun Jan 15, 2017 8:53 pm
by Armaetus
I'll be keeping an eye on this.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 5:23 am
by 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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 5:44 am
by Blue Shadow
ZZYZX wrote: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
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 6:16 am
by ZZYZX
Thanks, didn't know these identifiers were aggregated somewhere.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 6:16 am
by 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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 6:30 am
by ZZYZX
printz wrote: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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 10:18 am
by boris
printz wrote: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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 10:47 am
by 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
// 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?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 1:13 pm
by printz
boris wrote:printz wrote: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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 1:46 pm
by Jaxxoon R
Ah, you're doing the lord's work, ZZYZX.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 16, 2017 8:51 pm
by ZZYZX
Glaice wrote: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
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.
printz wrote: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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Tue Jan 17, 2017 2:59 am
by Hell Theatre
ZZYZX wrote:
printz wrote: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.
