GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Another question, this time aligning textures:
In UDMF mode, when I hit A to align textures, it does the aligning by changing the UDMF-specific ability to offset upper, mid and lower separately. However, sometimes it can be useful to align using the old whole side-def alignment method. Is there a key/modifier/whatever to say to GZDB "do this alignment for the overall sidedef, not the individual components"?
An example where I would find this useful would be if I am aligning a lower tex that will later be hidden so that the sides of a 3D floor that will be on the same lines get aligned. In this case in UDMF "A" aligns the lower so when the 3D floor is drawn, it has not been affected because it takes its offset values from the mid ones.
I've looked in the reference but I can't see anything listed.
In UDMF mode, when I hit A to align textures, it does the aligning by changing the UDMF-specific ability to offset upper, mid and lower separately. However, sometimes it can be useful to align using the old whole side-def alignment method. Is there a key/modifier/whatever to say to GZDB "do this alignment for the overall sidedef, not the individual components"?
An example where I would find this useful would be if I am aligning a lower tex that will later be hidden so that the sides of a 3D floor that will be on the same lines get aligned. In this case in UDMF "A" aligns the lower so when the 3D floor is drawn, it has not been affected because it takes its offset values from the mid ones.
I've looked in the reference but I can't see anything listed.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Another question ( ) Hope you're not getting fed up of all this.
If there are some split sectors in a map and then you move the geometry, by default GZDB automatically divides up the split sectors into discrete sectors, creating new sectors where necessary. While this is pretty cool, and quite impressive, it can mess things up if a map has been set up to deliberately have split sectors for some effect or other.
I know that I can hold Ctrl to prevent the above happening when I move the geometry around but it's very easy to forget or to simply not realise that I am moving an area with a split sector. So, is it possible to reverse this preference? i.e. is it possible to set things up so that the default behaviour is not to divide the split sector up and if I want it to happen, that's when I would need to press a modifier key? I still want the splitting behaviour, but on demand rather than by default.
If there are some split sectors in a map and then you move the geometry, by default GZDB automatically divides up the split sectors into discrete sectors, creating new sectors where necessary. While this is pretty cool, and quite impressive, it can mess things up if a map has been set up to deliberately have split sectors for some effect or other.
I know that I can hold Ctrl to prevent the above happening when I move the geometry around but it's very easy to forget or to simply not realise that I am moving an area with a split sector. So, is it possible to reverse this preference? i.e. is it possible to set things up so that the default behaviour is not to divide the split sector up and if I want it to happen, that's when I would need to press a modifier key? I still want the splitting behaviour, but on demand rather than by default.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Edit -> Merge Dragged Vertices Only (or use the toolbar icons). Note that this option will not merge crossing lines (like the other two options), just lines that are exactly on top of each other.
[edit] Holding Ctrl is something different, actually. Holding it while releasing the RMB will not merge geometry at all, no matter what's the geometry merging setting it.
[edit] Holding Ctrl is something different, actually. Holding it while releasing the RMB will not merge geometry at all, no matter what's the geometry merging setting it.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Thanks once again for your help.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I have a doubt, I can not give a different lighting to the top of a wall and a different lighting to the bottom? I try to make a kind of realistic lighting across sectors and wanting to do this increases or decreases the lighting of all the wall. Is there any way I want to do what I want or just have to live the rest of my life without being able to do it?
- Kappes Buur
-
- Posts: 4114
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
You can do this in DiHF with the function SetSectorGlow,TheMafla wrote:... , I can not give a different lighting to the top of a wall and a different lighting to the bottom? ...
or more easily in UDMF from Edit Sector - Colors, setting appropriate colours
Spoiler:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I quite often get a crash when reallocating sidedefs to a new sector. Doesn't happen all of the time, but it happens a lot.
e.g. select 4 lines, edit their second sides to have the same sector reference as another existing sector and a crash dialogue pops up. I can usually press continue and save the map (and the side def changes are saved) but the display is messed up and I can't see anything until I quit and go back in to GZDB,
Anyone else experience this?
[edit] Also, something entirely different, I noticed that if I set a sector's properties to have some damage using these options:
There is nothing at all to indicate that this sector is different from a normal sector when looking at it in the 2D editor. There are no marks or indications in the main map window nor any on the status/information area. Should there be?
e.g. select 4 lines, edit their second sides to have the same sector reference as another existing sector and a crash dialogue pops up. I can usually press continue and save the map (and the side def changes are saved) but the display is messed up and I can't see anything until I quit and go back in to GZDB,
Code: Select all
***********SYSTEM INFO***********
OS: Microsoft Windows 10 Pro
GPU: NVIDIA GeForce GTX 1080
GZDB: R3074
Platform: x86
********EXCEPTION DETAILS********
Index was outside the bounds of the array.
at CodeImp.DoomBuilder.BuilderModes.LinedefsMode.OnRedrawDisplay() in X:\Source\Plugins\BuilderModes\ClassicModes\LinedefsMode.cs:line 650
at CodeImp.DoomBuilder.Windows.MainForm.RedrawDisplay() in X:\Source\Core\Windows\MainForm.cs:line 1013
at CodeImp.DoomBuilder.Windows.MainForm.EditForm_OnValuesChanged(Object sender, EventArgs e) in X:\Source\Core\Windows\MainForm.cs:line 4126
at CodeImp.DoomBuilder.Windows.LinedefEditFormUDMF.apply_Click(Object sender, EventArgs e) in X:\Source\Core\Windows\LinedefEditFormUDMF.cs:line 748
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
[edit] Also, something entirely different, I noticed that if I set a sector's properties to have some damage using these options:
There is nothing at all to indicate that this sector is different from a normal sector when looking at it in the 2D editor. There are no marks or indications in the main map window nor any on the status/information area. Should there be?
- Kappes Buur
-
- Posts: 4114
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
deleted
Last edited by Kappes Buur on Tue Sep 17, 2019 11:07 am, edited 1 time in total.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I can reliably reproduce it. It happens when the sector you're changing the sidedefs to has a tag.Enjay wrote:I quite often get a crash when reallocating sidedefs to a new sector. Doesn't happen all of the time, but it happens a lot.
e.g. select 4 lines, edit their second sides to have the same sector reference as another existing sector and a crash dialogue pops up. I can usually press continue and save the map (and the side def changes are saved) but the display is messed up and I can't see anything until I quit and go back in to GZDB,
Anyone else experience this?
As a side note, it's weird how anachronistic it feels to me to manually change the sector reference of a sidedef. It was perfectly normal in the DEU days, but nowadays I go the lazy way and just use the join sector function.
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Aha! That's why I was getting it a lot when genuinely editing a map (most of the time I needed to merge the sectors for tagged special effects) and finding it hard to reproduce when trying with a simple test map (where I hadn't tagged the sectors). Now that I know that's the difference, it does only seem to happen when the sectors are tagged.boris wrote:I can reliably reproduce it. It happens when the sector you're changing the sidedefs to has a tag.
And, of course, that would be much easier too. Just hit "J" right? Don't know why, but I never got into the habit of doing it an automated way (DeePsea also has something similar, and I didn't use it there much either - perhaps some deep seated DEU muscle memory or something ). However, the crash may well be what finally forces me to think of joining sectors automatically rather than manually editing lines (although, I can see that sometimes I would still want to be quite explicit about which particular sector reference I was putting on the sidedef).boris wrote:As a side note, it's weird how anachronistic it feels to me to manually change the sector reference of a sidedef. It was perfectly normal in the DEU days, but nowadays I go the lazy way and just use the join sector function.
As a matter of interest, what determines which sector gets picked as the one that will be used as the "master" for the merged sectors. i.e. if three sectors with different properties get merged, which sector's properties will the merged sector have? Is it the lowest numbered, highest numbered, first/last selected or something else?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
It always merges the selected sectors into the first sector of the selection. There are two different methods, "Join Sectors" (J) and "Merge Sectors" (Shift-J). The difference between the two is that the latter also removes lines that the sectors shared.Enjay wrote:Aha! That's why I was getting it a lot when genuinely editing a map (most of the time I needed to merge the sectors for tagged special effects) and finding it hard to reproduce when trying with a simple test map (where I hadn't tagged the sectors). Now that I know that's the difference, it does only seem to happen when the sectors are tagged.boris wrote:I can reliably reproduce it. It happens when the sector you're changing the sidedefs to has a tag.
And, of course, that would be much easier too. Just hit "J" right? Don't know why, but I never got into the habit of doing it an automated way (DeePsea also has something similar, and I didn't use it there much either - perhaps some deep seated DEU muscle memory or something ). However, the crash may well be what finally forces me to think of joining sectors automatically rather than manually editing lines (although, I can see that sometimes I would still want to be quite explicit about which particular sector reference I was putting on the sidedef).boris wrote:As a side note, it's weird how anachronistic it feels to me to manually change the sector reference of a sidedef. It was perfectly normal in the DEU days, but nowadays I go the lazy way and just use the join sector function.
As a matter of interest, what determines which sector gets picked as the one that will be used as the "master" for the merged sectors. i.e. if three sectors with different properties get merged, which sector's properties will the merged sector have? Is it the lowest numbered, highest numbered, first/last selected or something else?
Pretty much all map elements have properties that are not displayed in the info panel or the 2D view. Not sure what the logic was what got added where. I guess in the classic formats pretty much everything was shown in the info panel, but there's just too much for UDMF. Showing sector damage in the info panel sounds sensible. Maybe even in the 2D view, since the damaging sector effects are shown, and not showing custom damage the same way seems unintuitive. What do others think?Enjay wrote: [edit] Also, something entirely different, I noticed that if I set a sector's properties to have some damage using these options:
There is nothing at all to indicate that this sector is different from a normal sector when looking at it in the 2D editor. There are no marks or indications in the main map window nor any on the status/information area. Should there be?
- drbugbait
- Posts: 1
- Joined: Thu Oct 26, 2017 8:21 pm
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Nova-Scotia, Canada
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
It would be useful for there to be support for editing LANGUAGE lumps. I make my WADs in multiple languages and it gets annoying having switch to Slade every time I make a script with text in it.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Thanks once again for the help - and I see that GZDB has updated with a fix for the merge sectors crash too. Thank you.boris wrote:answers
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I have a question, can I play with Doom 64-like colors through ACS? I've been searching for something on the ZDoom wiki and I can't find anything.