Perfect! Thanks!MaxED wrote:Added in r1696. The option is "Don't move selection if any part of it is outside of map boundary" and it's located in Preferences -> Editing.Nash wrote:Can there be an option that disallows any form of selection or editing for anything outside of the map boundaries?
When this option is enabled, you can still select anything outside of map boundaries, but you won't be able to drag it.
GZDoom Builder 2.3
Re: GZDoom Builder 1.14
-
Siberian Tiger
- Posts: 476
- Joined: Fri Jun 12, 2009 11:23 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): KUbuntu 22.04.1 LTS
- Graphics Processor: nVidia (Modern GZDoom)
- Location: United States
- Contact:
Re: GZDoom Builder 1.14
I think I have caught a bug, but I can't seem to confirm if it can be easily reproduced by others or if this issue only effects me. When creating a new map and then saving it (only a few sectors nothing special, a test with two sectors will give the same results) GZDoom Builder will then open a dialogue box, the information regarding the pop-up window will be provided underneath this message. Even though the Dialogue pop-up window appears, GZDoom Builder is still able to create the .wad file within the system's filesystem. Additionally, this issue does not occur when re-saving the same map or any map that already existed within the filesystem. Thus, this issue only happens when GZDoom Builder creates the new .wad file within the system.
Steps to Reproduce
Edited:
Added where this bug\issues was introduced.
Cleaned up
Steps to Reproduce
- Execute GZDoom Builder normally
- Create a new map
- Format: UDMF or Hexen
- Create a few sectors - nothing fancy. (A parent sector and a child sector should do just fine here.)
- Save the map
- A dialogue box should then appear
- r1697
- Occurs in this version
- r1696
- Does not occur in this version
Spoiler: Dialogue Window
Edited:
Added where this bug\issues was introduced.
Cleaned up
Re: GZDoom Builder 1.14
So. GZDoom Builder can't handle multiple TEXTUREx lumps in the correct fashion. I suspect this is also a problem with plain old ordinary Doom Builder.
G/ZDoom reads TEXTUREx in an accumulative fashion, and GZDoom Builder gets that right. What it doesn't get right, however, is looking up patches through the PNAMES lump. The behaviour I have is that it always looks at the last ever loaded PNAMES rather than what would be the last one loaded at the time the WAD is added. So, for example, load awesometextures.wad and fantastictextures.wad in alphabetical order will have the textures in awesometextures.wad resolve themselves with the PNAMES from fantastictextures.wad.
I was previously working around this by using TEXTURE2 for my own custom textures, but since I'm trying out multiple resource WADs to find the correct looking textures that method isn't good enough.
G/ZDoom reads TEXTUREx in an accumulative fashion, and GZDoom Builder gets that right. What it doesn't get right, however, is looking up patches through the PNAMES lump. The behaviour I have is that it always looks at the last ever loaded PNAMES rather than what would be the last one loaded at the time the WAD is added. So, for example, load awesometextures.wad and fantastictextures.wad in alphabetical order will have the textures in awesometextures.wad resolve themselves with the PNAMES from fantastictextures.wad.
I was previously working around this by using TEXTURE2 for my own custom textures, but since I'm trying out multiple resource WADs to find the correct looking textures that method isn't good enough.
-
Siberian Tiger
- Posts: 476
- Joined: Fri Jun 12, 2009 11:23 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): KUbuntu 22.04.1 LTS
- Graphics Processor: nVidia (Modern GZDoom)
- Location: United States
- Contact:
Re: GZDoom Builder 1.14
Great, thanks!MaxED wrote:Fixed in r1698
Re: GZDoom Builder 1.14
Another one that's really annoying me in UDMF mode:
Selecting multiple lines of differing textures/flags/specials/whatever and altering their properties clears out the arg0str parameter if it's set. Which breaks ACS_Execute specials.
Selecting multiple lines of differing textures/flags/specials/whatever and altering their properties clears out the arg0str parameter if it's set. Which breaks ACS_Execute specials.
-
Project_Hellbane
- Posts: 114
- Joined: Thu Oct 27, 2011 5:27 pm
- Location: The Inner Graves
Re: GZDoom Builder 1.14
I've tried GZDoom Builder and enjoy working with it a lot - but I'm having a problem ->
Spoiler: Editor
Spoiler: GameIf the cause of this problem is known could I please be informed of a fix?
Re: GZDoom Builder 1.14
So, your problem is that you don't see the dynamic lights or that the Player Start doesn't aknowledge the correct angle?
Re: GZDoom Builder 1.14
It's obviously the lights. And he obviously hasn't read a single thing about GLDEFS. If the lights don't appear in normal Doom play, what makes you think they'll magically appear in your WADs without your intervention?
Re: GZDoom Builder 1.14
Does this problem disappear after you save the map?Project_Hellbane wrote:I've tried GZDoom Builder and enjoy working with it a lot - but I'm having a problem ->Spoiler: EditorSpoiler: GameIf the cause of this problem is known could I please be informed of a fix?
Re: GZDoom Builder 1.14
Nothing really. I was just going to recommend checking if GZDoom is loading Lights.pk3 correctly, because that could actually be the problem, not GZDoom Builder.GooberMan wrote:what makes you think they'll magically appear in your WADs without your intervention?
-
Project_Hellbane
- Posts: 114
- Joined: Thu Oct 27, 2011 5:27 pm
- Location: The Inner Graves
Re: GZDoom Builder 1.14
I apologize at not giving more information, but the light's were working earlier; in the test room I had made, and they're working in the skybox.
Spoiler: Lava LightsI'm fairly confident that the Lights.pk3 is loading correctly, but without much knowledge of what else to do I'm at a loss here.
Re: GZDoom Builder 1.14
Can you provide some sort of example project (I've tried to reproduce your case using TEXTURES, and both GZDB and GZDoom seem to use the last patch encountered)?GooberMan wrote:So. GZDoom Builder can't handle multiple TEXTUREx lumps in the correct fashion. I suspect this is also a problem with plain old ordinary Doom Builder.
G/ZDoom reads TEXTUREx in an accumulative fashion, and GZDoom Builder gets that right. What it doesn't get right, however, is looking up patches through the PNAMES lump. The behaviour I have is that it always looks at the last ever loaded PNAMES rather than what would be the last one loaded at the time the WAD is added. So, for example, load awesometextures.wad and fantastictextures.wad in alphabetical order will have the textures in awesometextures.wad resolve themselves with the PNAMES from fantastictextures.wad.
I was previously working around this by using TEXTURE2 for my own custom textures, but since I'm trying out multiple resource WADs to find the correct looking textures that method isn't good enough.
Re: GZDoom Builder 1.14
TEXTURES isn't the same deal as TEXTURE1 and TEXTURE2. The old [wiki]TEXTUREx[/wiki] rely on a PNAMES lump, which map patch numbers to patch names.
When you use TEXTURES, you give patch names directly, so you don't go through a PNAMES step. Gooberman is talking quite specifically about how cumulative PNAMES are handled.ZDoom allows cumulative loading, though only one TEXTURE1 and one TEXTURE2 lump will be loaded for each archive; and in each archive TEXTURE1 is loaded before TEXTURE2. Each TEXTUREx lump uses the last previously-loaded PNAMES lump as a reference (so for example, the IWAD textures always use the IWAD patches).
Re: GZDoom Builder 1.14
Hopefully fixed in r1699...GooberMan wrote:Another one that's really annoying me in UDMF mode:
Selecting multiple lines of differing textures/flags/specials/whatever and altering their properties clears out the arg0str parameter if it's set. Which breaks ACS_Execute specials.