GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Software projects like source ports (3DGE, Eternity, etc), launchers like ZDL, and other useful utilities belong in this forum.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby FoptionMapping » Sun Jan 15, 2017 7:45 pm

I mean the one I showed and then MaxED 'left'.
User avatar
FoptionMapping
Hi! I'm Ford Timelord! I'm a car, and I've made a record!
 
Joined: 28 Jun 2016
Location: Shapes.shpA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Jan 15, 2017 7:53 pm

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?
User avatar
ZZYZX
le chat du rabbin
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby FoptionMapping » Sun Jan 15, 2017 8:01 pm

The tree on the left as well, please.
User avatar
FoptionMapping
Hi! I'm Ford Timelord! I'm a car, and I've made a record!
 
Joined: 28 Jun 2016
Location: Shapes.shpA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Glaice » Sun Jan 15, 2017 9:53 pm

I'll be keeping an eye on this.
User avatar
Glaice
Maps of Chaos/RDND/DVV Overseer
 
Joined: 13 Mar 2009
Location: North Babylon, NY
Discord: Glaice#8512

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Mon Jan 16, 2017 6:23 am

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.
Last edited by ZZYZX on Mon Jan 16, 2017 7:10 am, edited 1 time in total.
User avatar
ZZYZX
le chat du rabbin
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Blue Shadow » Mon Jan 16, 2017 6:44 am

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
User avatar
Blue Shadow
 
 
 
Joined: 14 Nov 2010

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Mon Jan 16, 2017 7:16 am

Thanks, didn't know these identifiers were aggregated somewhere.
User avatar
ZZYZX
le chat du rabbin
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby printz » Mon Jan 16, 2017 7:16 am

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.
User avatar
printz
BOW BEFORE ME!
 
Joined: 26 Oct 2006
Location: Bucharest, Romania

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Mon Jan 16, 2017 7:30 am

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.
User avatar
ZZYZX
le chat du rabbin
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Mon Jan 16, 2017 11:18 am

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.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Glaice » Mon Jan 16, 2017 11:47 am

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 allExpand 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?
User avatar
Glaice
Maps of Chaos/RDND/DVV Overseer
 
Joined: 13 Mar 2009
Location: North Babylon, NY
Discord: Glaice#8512

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby printz » Mon Jan 16, 2017 2:13 pm

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.
User avatar
printz
BOW BEFORE ME!
 
Joined: 26 Oct 2006
Location: Bucharest, Romania

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Jaxxoon R » Mon Jan 16, 2017 2:46 pm

Ah, you're doing the lord's work, ZZYZX.
User avatar
Jaxxoon R
 
Joined: 04 May 2014

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Mon Jan 16, 2017 9:51 pm

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 allExpand 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.

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.
User avatar
ZZYZX
le chat du rabbin
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Hell Theatre » Tue Jan 17, 2017 3:59 am

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.
Hell Theatre
 
Joined: 30 Apr 2016

PreviousNext

Return to Software and Ports

Who is online

Users browsing this forum: No registered users and 1 guest