GZDoomBuilder-Bugfix, a maintenance fork of GZDB
-
- Posts: 32
- Joined: Tue Jun 28, 2016 4:27 am
- Location: Shapes.shpA
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I mean the one I showed and then MaxED 'left'.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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?
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?
-
- Posts: 32
- Joined: Tue Jun 28, 2016 4:27 am
- Location: Shapes.shpA
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
The tree on the left as well, please.
-
- Posts: 1256
- 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
I'll be keeping an eye on this.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
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.
-
- Posts: 5018
- Joined: Sun Nov 14, 2010 12:59 am
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I don't know what meta means, but for slow:ZZYZX wrote:Anyone knows what "meta" or "slow" is? I mean, I know what "fast" is, but "slow"?
https://zdoom.org/wiki/Actor_states#State_keywords
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Thanks, didn't know these identifiers were aggregated somewhere.
-
- Posts: 2648
- Joined: Thu Oct 26, 2006 12:08 pm
- Location: Bucharest, Romania
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
ZScript, actually.printz wrote:Isn't GZDB pretty much feature-complete by now?
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.
-
- Posts: 751
- Joined: Tue Jul 15, 2003 3:37 pm
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.printz wrote:Isn't GZDB pretty much feature-complete by now?
-
- Posts: 1256
- 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
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:
Why is GZDBBF triggering this when the information appears correct?
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"
}
-
- Posts: 2648
- Joined: Thu Oct 26, 2006 12:08 pm
- Location: Bucharest, Romania
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Two words: plug-ins. You are one who writes them. Stuff like ZSCRIPT sound like something which can be added via plug-ins.boris wrote: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.printz wrote:Isn't GZDB pretty much feature-complete by now?
-
- Posts: 772
- Joined: Sun May 04, 2014 7:22 pm
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Ah, you're doing the lord's work, ZZYZX.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
When I copy this code I get a different error: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".
Code: Select all
MAPINFO error in "...\mapinfo.txt", line 81. Expected outsidefogdensity value, but got ""180"".
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.
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.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.
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.
-
- Posts: 23
- Joined: Sat Apr 30, 2016 10:33 am
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
ZZYZX wrote: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.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.
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.