Page 84 of 97

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Oct 06, 2019 1:41 pm
by Kappes Buur
Enjay wrote:(Perhaps not GZDB related) Why is it not possible to set the brightness of a sidedef top, middle and bottom separately? As far as I can see, it's all or nothing. Can the engine or UDMF not support this? Maybe I just missed something?

That's sort of possible in UDMF with a combination of sector glow colours and Transfer_WallBrightness.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Oct 06, 2019 2:25 pm
by boris
Enjay wrote:In other news, I just wanted to check whether this problem is known about (I think it is, but if not, I'll post on github).

Complicated slopes using things don't render properly in Visual mode.

Ah, more slope fun :) Having to press tab twice has been fixed in the repository for some time now. Besides that there were three issues, of which two were with the 9500/9501 slope things:

- Slopes were still not applied in the correct order (only one pass for lines and things each, instead of two for each)
- Slopes were overwriting each other and not taking existing slopes into account
- It made some wrong assumptions on how the 9500/9501 slope things work and can be used

It's fixed in the repository.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Tue Oct 08, 2019 5:06 am
by Kinsie
Kinsie wrote:When I replace an actor that's categorized in a configuration using the "replaces" DECORATE/ZScript command, it only shows the new actor's raw actor name regardless of whether they have a Tag or a //$Title property.

Reposting because I've been having this problem again with another mod.

Notice how the new weapon fits in like a glove while the replaced item looks ugly. Is there a better way to handle this, like taking the $Name key while maintaining the CFG file's categorization?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Wed Oct 09, 2019 11:04 am
by Enjay
Thanks Kappes and boris for the comments, help and recent fixes.

Having this kind of help and ongoing support for the editor really makes a difference. :thumb:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Thu Oct 10, 2019 12:04 pm
by skdursh
Recent update to Windows 10 Defender is ID'ing all GZDB-Bugfix downloads as malicious Trojans for some reason or another. I assume this is almost certainly a false-positive. I think it possibly has something to do with the updater as it also tagged the standalone updater zip as malicious as well as all current and previous builds of GZDB-Bugfix back to at least r3067, which was the earliest build I had a copy of still saved to my external.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Oct 11, 2019 5:07 pm
by Enjay
I'm sure that I am missing something obvious but you know how GZDoom can take a patch name, texture name, flat name etc on a wall/floor? I can't see how to enable patch names to the texture choice lists/browsers. Textures (of the various types) are there, as are patches, but I can't figure out how to see patch names in the lists too. If I do put a patch name o a sidedef, the F4 error checker flags it as unknown (and it shows as unknown in 3D view too) but it works just fine in game.

I've looked through the project texture options but I can't seem to find anything relevant.

How do I enable patches to also show in texture choices?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Oct 11, 2019 6:13 pm
by Kappes Buur
You can use either, texture or flat, by default.

Stick new textures/flats in your pwad between TX_ markers.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Oct 12, 2019 1:13 am
by boris
GZDB-BF doesn't support to use patches directly. I wasn't even aware that GZDoom supported that. Is that a bug or a feature? Is it documented anywhere?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Oct 12, 2019 2:52 am
by Enjay
It's a feature. It goes right back to the original "any graphic anywhere" implementation by Randi in ZDoom many, many years ago. I can't check right now but I'm pretty sure sprites are also considered valid. I remember Randi's demo WAD having a cyberdemon sprite on either the walls or the floor (Walls i think, and the icon of sin face texture (or maybe just the patch) on the floor.).

In fact, when I was requesting and arguing for textures that could just be placed between markers and work (i.e. what became TX_ style textures) several people argued against the idea because it was already possible to add graphics to the PNAMES lump and use them from there. (My counter was that doing so still required an extra step and editing of a special lump whereas just shoving the graphics between markers was easier. )

Of course, the above recollection leaves open the question, does the graphic need to be in the PNAMES lump (or patches folder) to be considered valid or is simply being in an archive enough (I suspect the former as it is neater and more manageable).

While playing around with Wads by other people and converting them to UDMF to get GZDB practise, I have come across several instances of people using patches directly on walls/floors.

From an editor POV, to me it makes sense to have patches specifically enabled/disabled by some easy toggle somewhere. DeepSea does this (just a check box for whether I want flats to be listed for walls, another for textures on floors, another for sprites (I think) and another for pnames). Most of the time I leave PNAMES disabled because they really clutter up the lists, and do so with graphics that are (mostly) identical to textures so loads of duplication of appearance in the lists). I don't think I have ever enabled sprites but I'm pretty sure that the toggle is there. However, having pnames etc showing in the lists for floor/sidedef editing is disabled separately to error checking, so if a valid patch is on a wall, DeepSea's error checker does not flag it as a problem (If I have that option enabled) even if they are not listed in the floor/siddef dialogues.

[edit] not peck-peck-pecking at the screen on my phone any more

Here is what the DeePsea sidedef editor looks like:

I'm not saying that's perfect, merely that it provides a quick, easy way to say "yes, I want to see these types" or "no, I don't" rather than the texture browser getting cluttered up. (Options set here persist across all side-defs, its a global preference, not just for the single instance of this side - which would also be annoying).

I've been trying to find Randi's original example but I can't track it down. It doesn't seem to be in the examples folder. I know that it goes back a long way though.


Just found this on the wiki on the textures page:

With ZDoom, these limitations have been remedied. All graphics (sprites, flats, patches, and miscellaneous graphics like TITLEPIC and CONBACK) can be used interchangeably.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Oct 12, 2019 3:54 am
by Enjay
This is the closest that I have found to official documentation so far:

rh-log.txt wrote:June 10, 2003
- After putting it off for far too long, I finally started working on a unified
texture system that will let me treat sprites, flats, and wall textures all
the same. Sprites are not done yet, but now Build maps can be viewed with
the correct floors and ceilings. One consequence of this change is that flats
are now stored in column-major format instead of row-major format, so I had
to changed the span drawers to account for this.

June 19, 2003
- Finished moving everything to the new texture system. There is still a
little work yet to do, but at least the only place where patches are used
any more is in the texture loaders.

There are a few other references to the new texture system around about that time. Nothing that I have found specifically says "patches can be used on walls/floors now" but I have a very clear memory of it being discussed and, obviously, the wiki (and tools such as DeePsea) back up that recollection.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Oct 12, 2019 5:54 am
by Rachael
I have actually abused this feature before, in order to demonstrate how the software renderer violates the rules of the Z-buffer (essentially following its own rules anyhow) by submerging a player "wall" underwater. The player was simply created with a linedef.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Oct 12, 2019 9:13 am
by axredneck
Yes, sprites and patches for walls would be useful in GZDB. Especially using of switches' patches on midtextures.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Oct 13, 2019 3:27 am
by Enjay
I'm not even putting this on github because I suspect it is not easy to do and reward versus effort wouldn't be high enough, but I thought I'd drop it here just in case.

Is there any way that GZDB could have map previews? By that, I mean when opening a WAD, you can see what the map looks like:
(In fact, DeeSea can preview any WAD contents in this dialogue and you can scroll through the lumps present to get a preview of the maps, textures, sprites, control lumps, whatever.)

Or when switching to another map in a multi-map set, you can get previews of the maps present:

DeePSea also has a texture-like browser (accessed via the button shown in the above pic):

I just find it useful.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Oct 13, 2019 4:45 am
by Gez
axredneck wrote:Especially using of switches' patches on midtextures.

No, it would actually be worse than useless, it'd be counterproductive.

Switches are defined (in SWITCHES or ANIMDEFS lumps), and just slapping willy nilly switch patches rather than the defined switch textures is just going to result in non-functional switches. It'll be just like putting a line effect on a regular, non-switch texture, except that it'll look like a switch so players would expect to have the familiar "shtunk" sound and the texture change, but won't have it. It'll encourage mappers who don't know how the engine works to make broken levels.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Oct 13, 2019 5:47 am
by Enjay
It is worth pointing out that the ability to do this has existed for a decade and a half, and it hasn't really be a problem. Although GZDB (and presumably DB before it) doesn't have the ability to list patches as valid wall/floor graphics, other editors clearly do and people have released maps with patches on walls, because I've found a few.

As an example of (perhaps) good use, I found one where the author had defined scaled textures that were half the size of the original patches. He had used the scaled versions where he wanted to put smaller versions of the graphic and used the patch directly where he wanted to use the full-sized version. Are there other ways to do that? Of course (especially in UDMF) but it struck me as quite a good use of this ability.

However, yes, simply putting a switch patch on a line would give it not particular special abilities. It would neither animate nor make a sound when used unless it was also defined as a switch in one of the control lumps that Gez listed. So, unless you were going to do something else with it too, simply putting a switch patch on a wall isn't very useful.

Personally, I don't think I have made much (if any) use of the ability to use patches directly, but other people have and patches appearing as unknown graphics in the sidedef or surfaces editor and 3D view, and flagging as errors in the F4 error checker isn't correct because such usage is in-spec.