GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
User avatar
FoptionMapping
Posts: 32
Joined: Tue Jun 28, 2016 4:27 am
Location: Shapes.shpA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by FoptionMapping »

I mean the one I showed and then MaxED 'left'.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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?
User avatar
FoptionMapping
Posts: 32
Joined: Tue Jun 28, 2016 4:27 am
Location: Shapes.shpA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by FoptionMapping »

The tree on the left as well, please.
User avatar
Armaetus
Posts: 1255
Joined: Fri Mar 13, 2009 3:55 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 10 Home
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: New York State

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Armaetus »

I'll be keeping an eye on this.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
Last edited by ZZYZX on Mon Jan 16, 2017 6:10 am, edited 1 time in total.
Blue Shadow
Posts: 4955
Joined: Sun Nov 14, 2010 12:59 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Thanks, didn't know these identifiers were aggregated somewhere.
User avatar
printz
Posts: 2648
Joined: Thu Oct 26, 2006 12:08 pm
Location: Bucharest, Romania

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
boris
Posts: 745
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
User avatar
Armaetus
Posts: 1255
Joined: Fri Mar 13, 2009 3:55 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 10 Home
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: New York State

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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?
User avatar
printz
Posts: 2648
Joined: Thu Oct 26, 2006 12:08 pm
Location: Bucharest, Romania

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
User avatar
Jaxxoon R
Posts: 772
Joined: Sun May 04, 2014 7:22 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Jaxxoon R »

Ah, you're doing the lord's work, ZZYZX.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
Hell Theatre
Posts: 23
Joined: Sat Apr 30, 2016 10:33 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

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

Return to “Abandoned/Dead Projects”