This content may be freely modified and/or maintained by anyone.
Try that in the software renderer. Every OGL implementation we've seen - SRB2, GZDoom Builder, etc - has drawn that wall incorrect to Software, which is what we consider as the baseline. Lower unpegged should peg the bottom of the lower texture to the floor, which it does in Software, so...

EDIT: Ninja'd by new page.
 
ok, but I should note, the SRB2 screen shots were all done in software mode. I stopped using opengl mode when we upgraded to 2.0 and software mode stopped having the windows pallet glitch.

Zdoom Software
Screenshot_Doom_20160608_183547.png

Zdoom Opengl
DOOM0155.png


Doom Legacy Software
doomlegacy.png
 
Last edited:
Setting a Special in the sectors menu to something other than the pre-defined defaults incorrectly reports it as multiple effects, and reports the effect number that you changed incorrectly as something it isn't. Interestingly, despite it reporting multiple effects, all the other effect numbers are fine. This ordinarily wouldn't be a huge issue, but since Lua can read sector specials, it's entirely possible for a mapper to wish to use a custom sector special in their mod.
Image:
tRKIRW0.png
 
Special types are additive across the 4 sections in SRB2, that's just how it works. You're going to have to use something like the bustable block parameters as your custom sector type, since they have no default in-map effect.
 
The thing is, each of the 4 types have 16 possible values. Not all of them are used on every type. When these unused ones are used, zone builder erroneously reports it as something else and as multiple effects, even if it's just one, and displays as one in the actual menu.
 
Last edited:
they both have lower unpegged, but if this is correct, why do Even Doom source ports have better Z alignment than 2.1.15?
Taken from GZDOOM:


It has something to do with SRB2 Itself i suppose if editor and other Sourceports are able to display it fine .
 
Last edited:
It turns out that 2.1.15 Software changed the way Lower Unpegged works. In Doom and previous versions of SRB2, the lower texture is aligned with the ceiling above the lower floor. In 2.1.15, it's aligned with the lower floor itself. The problem is that until recently (March 19th), the description of Lower Unpegged on the Doom Wiki was incorrect. As you can see, this describes the behavior as you see it in 2.1.15, instead of what actually happens in Doom. The description of Lower Unpegged on the SRB2 Wiki is based on this description and therefore also incorrect. This is why I thought the behavior in 2.1.15 is "correct", because it matches with the description on the Wiki. The commit that changed the behavior in SRB2 was made by RedEnchilada, so I'll have to check back with him and clear up whether this was an intentional change or whether he made the same assumption as me that the description on the Doom Wiki is correct, and was just trying to "fix" an error that wasn't one.

Either way, you can easily correct the misalignment of your example in 2.1.15 by removing the Lower Unpegged flag and instead adding the Peg Midtexture flag.

EDIT: Oops, didn't see Red's post in the bug report thread. Anyway, I already changed the pegging behavior in ZB's Visual Mode, so from the next release onwards it will look like it does in 2.1.15. If the devs decide to change it back or make any other change, I'll adjust ZB to match.
 
Last edited:
Setting a Special in the sectors menu to something other than the pre-defined defaults incorrectly reports it as multiple effects, and reports the effect number that you changed incorrectly as something it isn't. Interestingly, despite it reporting multiple effects, all the other effect numbers are fine. This ordinarily wouldn't be a huge issue, but since Lua can read sector specials, it's entirely possible for a mapper to wish to use a custom sector special in their mod.
Image:
tRKIRW0.png

These '2nd, 3rd and 4th' effects, dont seem to work since i tried to use this for that space countdown thing i had trouble with unless it works in another way that i am not understanding.
 
It turns out that 2.1.15 Software changed the way Lower Unpegged works. In Doom and previous versions of SRB2, the lower texture is aligned with the ceiling above the lower floor. In 2.1.15, it's aligned with the lower floor itself. The problem is that until recently (March 19th), the description of Lower Unpegged on the Doom Wiki was incorrect. As you can see, this describes the behavior as you see it in 2.1.15, instead of what actually happens in Doom. The description of Lower Unpegged on the SRB2 Wiki is based on this description and therefore also incorrect. This is why I thought the behavior in 2.1.15 is "correct", because it matches with the description on the Wiki. The commit that changed the behavior in SRB2 was made by RedEnchilada, so I'll have to check back with him and clear up whether this was an intentional change or whether he made the same assumption as me that the description on the Doom Wiki is correct, and was just trying to "fix" an error that wasn't one.

Either way, you can easily correct the misalignment of your example in 2.1.15 by removing the Lower Unpegged flag and instead adding the Peg Midtexture flag.

EDIT: Oops, didn't see Red's post in the bug report thread. Anyway, I already changed the pegging behavior in ZB's Visual Mode, so from the next release onwards it will look like it does in 2.1.15. If the devs decide to change it back or make any other change, I'll adjust ZB to match.

I got a lot of lower unpegged to change now. I don't like that the change was made, but at least the old behavior seems to still be present in some form. And Lower unpegged is still at least useful somewhere.

Edit, the old behavior is gone.
 
Last edited:
Does anyone else experience this? If I use Zone Builder after prolong amount of time, it starts becoming sluggish and just switching modes takes longer then it should.
 
Does anyone else experience this? If I use Zone Builder after prolong amount of time, it starts becoming sluggish and just switching modes takes longer then it should.

Yeah i do get that sometimes but i always thought it was my toaster being annoying as usual.
 
So, this computer is an old Mac I've installed Windows onto, which caused me to find a weird bug:

The delete key can delete anything.
The backspace key (this keyboard's delete key) cannot delete things. It can delete vertices, linedefs, and sectors, but not things.
 
This was caused by trying to set up a custom FOF before building the back sector for the control linedef and before the flag values could be set.
Code:
***********SYSTEM INFO***********
OS: Microsoft Windows 7 Professional 
GPU: NVIDIA GeForce GTX 960
Zone Builder: v2.4

********EXCEPTION DETAILS********
String cannot contain a minus sign if the base is not 10.
   at System.ParseNumbers.StringToInt(String s, Int32 radix, Int32 flags, Int32* currPos)
   at System.Convert.ToInt32(String value, Int32 fromBase)
   at CodeImp.DoomBuilder.Map.Linedef.Set3DFloorArgs()
   at CodeImp.DoomBuilder.Rendering.Renderer2D.UpdateExtraFloorFlag()
   at CodeImp.DoomBuilder.BuilderModes.BuilderPlug.OnMapOpenEnd()
   at CodeImp.DoomBuilder.Plugins.PluginManager.OnMapOpenEnd()
   at CodeImp.DoomBuilder.General.OpenMapFileWithOptions(String filename, MapOptions options)
   at CodeImp.DoomBuilder.General.OpenMapFile(String filename, MapOptions options)
   at CodeImp.DoomBuilder.General.OpenMap()
   at CodeImp.DoomBuilder.Actions.Action.Begin()
   at CodeImp.DoomBuilder.Actions.ActionManager.InvokeAction(String actionname)
   at CodeImp.DoomBuilder.Windows.MainForm.InvokeTaggedAction(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.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)

SRB2 Doom builder 1 did not have this issue and allowed for the affected map to be fixed to allow Zone Builder to continue editing it.
 
Last edited:
The only thing that i really feel ZB Lacks is the ability to detect Custom objects via OBJCTCFG Like the Original GZDB Decorate .

Also i seem to have found a bug, MAINCFG File isn't copied to the new .tmp Test .wad if you try running your map before saving it, This means any Weather, Music .. etc map settings require saving the map to test them with the New "Map" changes .
 
The only thing that i really feel ZB Lacks is the ability to detect Custom objects via OBJCTCFG Like the Original GZDB Decorate .
Time to update your copy of Zone Builder, then, because that was actually added one version before the current version, and I can confirm it works. (It definitely works with Lua objects, at least, and it's said to work with SOC objects too.)
 
Wow i thought i already did, Ugh okay then, Does it require a line to be added to OBJCTCFG Just like GZDB ? .
 
There's some kind of bug, I'm not sure if it's via ZB or SRB2, but sometimes, when you place things on the map... they won't respond. My map is a witness to this. Rings, badniks, monitors.etc. Basically, the things won't interact with Sonic, like they should.
 

Who is viewing this thread (Total: 2, Members: 0, Guests: 2)

Back
Top