GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I've made an update to the updater. It can now update GZDB-BF while the editor is running. But the updater doesn't update itself, so you'll have to download it (or the whole package) manually: https://devbuilds.drdteam.org/gzdbbf/GZ ... 086-x64.7z
---
If GZDoom supports patches and sprites on walls and floors that should obviously be supported by GZDB-BF. The problem is always time.
---
If GZDoom supports patches and sprites on walls and floors that should obviously be supported by GZDB-BF. The problem is always time.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Thanks for the update.
I've just posted on GitHub to say that, although I haven't had a chance to do much with it today, it looks as if your workaround for the DevIL problem has probably worked for me too.
I've just posted on GitHub to say that, although I haven't had a chance to do much with it today, it looks as if your workaround for the DevIL problem has probably worked for me too.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Should a line with a special that has been given an argument to tag it to a sector, when the sector tag does not exist be flagged as an error?
e.g. Say, there is a line type 209 (transfer heights) tucked away in a little control sector somewhere tagged to sector 101, but no sectors have been given the tag 101. Obviously the line would do nothing but should the F4 error checker pick it up as a problem? Currently it doesn't but I feel that it probably should.
I can understand a sector that has been given a tag where there are no line arguments referencing it not being an error (the sector could be referenced via a script, for example) but I'm not aware of a situation when a line action referencing a missing sector tag is a legitimate setup.
e.g. Say, there is a line type 209 (transfer heights) tucked away in a little control sector somewhere tagged to sector 101, but no sectors have been given the tag 101. Obviously the line would do nothing but should the F4 error checker pick it up as a problem? Currently it doesn't but I feel that it probably should.
I can understand a sector that has been given a tag where there are no line arguments referencing it not being an error (the sector could be referenced via a script, for example) but I'm not aware of a situation when a line action referencing a missing sector tag is a legitimate setup.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Yeah, I guess that makes sense. As you said it's a big no-no for sector (and thing) tags, though.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
If you have the time and the inclination to add it, I'd certainly find it useful.
[edit]
While I'm on, is there a reason that the reflectiveness of a sector is not sown on the info panel? (Lack of space?)
Sector floor set to be reflective:
No clues on the info bar:
Pretty much everything else that can be changed gets displayed:
[/edit]
[edit]
While I'm on, is there a reason that the reflectiveness of a sector is not sown on the info panel? (Lack of space?)
Sector floor set to be reflective:
No clues on the info bar:
Pretty much everything else that can be changed gets displayed:
[/edit]
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
In visual mode, is it possible somehow to select all lines/sides between two points?
What I mean is imagine there is a room with many, many lines making up the walls (I dunno, a curved cave wall or something). I know that I can shift-click to auto select all connected lines with the same texture but is there a way to just select a section of the wall. Maybe by selecting the first line that I want to change and the last one and then hitting a button that will autoselect everything between those points if I click one of the lines in the middle?
What I mean is imagine there is a room with many, many lines making up the walls (I dunno, a curved cave wall or something). I know that I can shift-click to auto select all connected lines with the same texture but is there a way to just select a section of the wall. Maybe by selecting the first line that I want to change and the last one and then hitting a button that will autoselect everything between those points if I click one of the lines in the middle?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Enjay wrote:In visual mode, is it possible somehow to select all lines/sides between two points?
What I mean is imagine there is a room with many, many lines making up the walls (I dunno, a curved cave wall or something). I know that I can shift-click to auto select all connected lines with the same texture but is there a way to just select a section of the wall. Maybe by selecting the first line that I want to change and the last one and then hitting a button that will autoselect everything between those points if I click one of the lines in the middle?
A ton of properties are not shown in the info panel. For sectors alone that's:Enjay wrote:While I'm on, is there a reason that the reflectiveness of a sector is not sown on the info panel? (Lack of space?)
- 4 sector damage properties
- gravity
- fog density
- sound sequence
- desaturation
- 4 ceiling/floor glow properties
- 5 Doom 64 sector color properties
- render style for ceiling/floor
- terrain for ceiling/floor
- reflectivity for ceiling/floor
- x slope properties for ceiling/ floor
- several ceiling/floor portal properties
- custom UDMF fields
I'm not saying that it shouldn't be added, I'm genuinely wondering if it'd improve GZDB-BF.
Something like that is not in, the closes you get is using the paint selection. It's one of the things that look trivial at first glance but get very complex very quickly. Like the "direction" the selection should take. What happens at "forks"? etc.Enjay wrote:In visual mode, is it possible somehow to select all lines/sides between two points?
What I mean is imagine there is a room with many, many lines making up the walls (I dunno, a curved cave wall or something). I know that I can shift-click to auto select all connected lines with the same texture but is there a way to just select a section of the wall. Maybe by selecting the first line that I want to change and the last one and then hitting a button that will autoselect everything between those points if I click one of the lines in the middle?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
A possible way to go around that would be to make a priority list for properties, and set a limit to how many parameters are shown. Stuff that's set to default is hidden, and the X non-default properties with the highest priority scores would be shown.boris wrote: Should everything be displayed (if they differ from the default, defaults are not shown right now for properties that can be displayed in the info panel anyway)? Only the most important stuff? Does that increase or decrease usability? What about people with potato laptops that have a gameboy style resulution?
I'm not saying that it shouldn't be added, I'm genuinely wondering if it'd improve GZDB-BF.
That would require quite a lot of judgment calls, and besides many properties require several values to work (e.g. slope equation parameters), so a number of them should probably be "collapsed" into a single reading, which means a lot of ad-hoc work.
Is any of this really worth the trouble?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Understood on the info panel thing. It would have been nice to see the altered reflectivity at a glance, but I totally understand why it (and all the other things that I hadn't realised) are not shown.
Visual mode paint select looks like it will meet my needs very nicely. Now, all I have to do is find a key that isn't already bound to something.
Thanks for the help.
[edit]
Yup, Paint select will work just fine for me.
However, can someone tell me how to bind a key combination to actions? I was trying to bind Ctrl+another key but the input only accepted whatever that last key pressed was. e.g. I'd press Ctrl and (while still holding Ctrl) press another key, say Z and the binding changed to the second key (Z) instead of Ctrl+Z. Lots of actions are bound to Ctrl, Shift etc + another key, so I guess I'm just doing it wrong.
Visual mode paint select looks like it will meet my needs very nicely. Now, all I have to do is find a key that isn't already bound to something.
Thanks for the help.
[edit]
Yup, Paint select will work just fine for me.
However, can someone tell me how to bind a key combination to actions? I was trying to bind Ctrl+another key but the input only accepted whatever that last key pressed was. e.g. I'd press Ctrl and (while still holding Ctrl) press another key, say Z and the binding changed to the second key (Z) instead of Ctrl+Z. Lots of actions are bound to Ctrl, Shift etc + another key, so I guess I'm just doing it wrong.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Something that I can't figure out: how does GZDB "decide" where to start/finish when aligning walls?
What I mean by that is, imagine I have a circular pillar with many lines making its shape. The total length of the lines is not a multiple of the texture width so when the textures are aligned, at some point two adjacent lines will have a tiling mismatch. What I want to know is where will that mismatch appear? In DeePsea I knew whichever line was selected was the "zero point": everything to the right of it was correctly aligned and the mismatch would appear between the "zero line" and the one to the left of it. In GZDB the system seems slightly different. I point my cursor at a line, hit A to align them and it works (of course) but I'm not sure exactly what the rules for where the mismatch will appear is. It seems to typically end up being a couple of lines to the right.
I'm not complaining, I just want to know the rules so that I can predict how it's going to work.
What I mean by that is, imagine I have a circular pillar with many lines making its shape. The total length of the lines is not a multiple of the texture width so when the textures are aligned, at some point two adjacent lines will have a tiling mismatch. What I want to know is where will that mismatch appear? In DeePsea I knew whichever line was selected was the "zero point": everything to the right of it was correctly aligned and the mismatch would appear between the "zero line" and the one to the left of it. In GZDB the system seems slightly different. I point my cursor at a line, hit A to align them and it works (of course) but I'm not sure exactly what the rules for where the mismatch will appear is. It seems to typically end up being a couple of lines to the right.
I'm not complaining, I just want to know the rules so that I can predict how it's going to work.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Regarding all those properties, what I'd do is a list that contains all known properties plus all manually added ones. This way the modder can easily see what options are there without cluttering the main properties page.
About patches as textures, yes, internally they are one and the same and everything can generally be used everywhere. This even goes as far that you can build a composite texture of flats with a sprite overlay on top - or anything else., like some smallfont characters The only reason the texture types still exist is to prioritize which one to pick if there's more with the same name.
About patches as textures, yes, internally they are one and the same and everything can generally be used everywhere. This even goes as far that you can build a composite texture of flats with a sprite overlay on top - or anything else., like some smallfont characters The only reason the texture types still exist is to prioritize which one to pick if there's more with the same name.
- axredneck
- Posts: 357
- Joined: Mon Dec 11, 2017 2:09 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Russia
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Mismatch will be on the left of mouse pointer.Enjay wrote:but I'm not sure exactly what the rules for where the mismatch will appear is.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
OK, that's what I expected (thanks), but sometimes it didn't seem to be happening.
I wonder if it might be because the map I was working with was originally in ZDoomHexen format and so some of the lines already had whole-sidedef offsets?
Related to that, is there a way, when aligning textures to auto-zero existing offsets and starts afresh? I keep forgetting that existing offsets are used (which, of course can be useful) and are built upon. That means with sides that already have whole-side offsets, the new offsets are a cumulative effect of the original side offset and any new top/middle/bottom ones that are added by GZDB.
Maybe I just need more self-discipline when aligning textures in old maps to ensure that I remember to manually zero existing offsets first.
I wonder if it might be because the map I was working with was originally in ZDoomHexen format and so some of the lines already had whole-sidedef offsets?
Related to that, is there a way, when aligning textures to auto-zero existing offsets and starts afresh? I keep forgetting that existing offsets are used (which, of course can be useful) and are built upon. That means with sides that already have whole-side offsets, the new offsets are a cumulative effect of the original side offset and any new top/middle/bottom ones that are added by GZDB.
Maybe I just need more self-discipline when aligning textures in old maps to ensure that I remember to manually zero existing offsets first.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
The auto alignment is a bit weird - in fact it's a bit buggy. It also works differently between UDMF and non-UDMF. It UDMF it goes right first, in non-UDMF it goes left first. It will also align the first linedef in the opposite direction twice. So that means in UDMF the linedef left of your starting linedef will be aligned to the start, in non-UDMF the linedef right of your starting linedef will be aligned to the start. Which is probably what's so confusing, as it's not really expected (IMO). It's only a problem when alignment goes in a circle (like aligning a pillar), otherwise you'll not notice it.
I guess for ceiling/floor it's flats -> textures -> patches -> sprites, and for walls it's textures -> patches -> flats -> sprites?
Is there any documentation about the precedence?Graf Zahl wrote:About patches as textures, yes, internally they are one and the same and everything can generally be used everywhere. This even goes as far that you can build a composite texture of flats with a sprite overlay on top - or anything else., like some smallfont characters The only reason the texture types still exist is to prioritize which one to pick if there's more with the same name.
I guess for ceiling/floor it's flats -> textures -> patches -> sprites, and for walls it's textures -> patches -> flats -> sprites?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Thanks for explaining what's going on with aligning. That would account for what I'm seeing and why I was getting confused - especially when I have been going between Hexen and UDMF.
I have actually been aligning a lot of things that "go in a circle" (even a small square room the tie same texture on every wall comes back on itself and therefore can start to show the problems). It can make picking where to start aligning a bit tricky. A quick work around is to select all of the sides, then deselect one to break the circle, align the textures and then sort out the one that didn't get aligned.
I have actually been aligning a lot of things that "go in a circle" (even a small square room the tie same texture on every wall comes back on itself and therefore can start to show the problems). It can make picking where to start aligning a bit tricky. A quick work around is to select all of the sides, then deselect one to break the circle, align the textures and then sort out the one that didn't get aligned.