Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Dec 10, 2018 4:49 pm
by Kappes Buur
How this works for me.
Creating an initial sector, either with Draw Rectangle Mode or Draw Line Mode, sets the default floor/ceiling textures. Opening the Draw Settings Panel and changing the f/c textures to something undefined then displays all subsequent sectors with the unknown texture
Saving the map in that state will show the same when opened again later.
However, when creating a new map after that, these settings are reset to the default textures, and one has to again go through the process of setting the texture to an unknown texture.
This happens in every version, DB2_r2787 to latest GZDB-BF.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Tue Dec 11, 2018 4:15 am
by Gez
Nash wrote:EDIT: to make things worse, it is doing this retroactively to opened maps that previously have the empty textures. I'm opening some other maps which I haven't touched in a while and suddenly and magically all textures that were intentionally set to "-" now have a texture applied, without my control!
So, the problem is likely not in the copy-pasting override code, but in some other "missing texture fix" code running in parallel.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sun Dec 16, 2018 8:22 pm
by Kappes Buur
Something is wrong with dynamic lights in a specific case:
It appears that copy/pasting dyn lights from inside a sector to atop the left or bottom linedef,
or simply inserting new, throws off the calculation of the radius.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Wed Dec 26, 2018 2:18 pm
by Darkcrafter
A feature request.
I'd like to get such a feature that would allow a map creator to stick many things together into groups and so be edited as one thing. That would be super useful when faking 3d models with sprites such things like trees, rocks and stones. You might say that Doom Builder already has a feature of saving selection, but it only saves a selection. What I would like to get is an ability to preserve the inital thing's Z-height properties so the things don't get higher or lower according to geometry below them. So it would work like adding a NOGRAVITY flag that would also allow for the sprites to bleed into void. That would allow easier creation of pseudo-3d objects made up from models and sprites. I really like how it is easy to make those stones models bleed into nothing here: https://youtu.be/2AW3c24hFJA?t=74 Is this possible in GZDoom?
Cheers,
Darkie
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Works just like paint selection in classic modes. No default key bound. Works on floors/ceilings, any parts of lines, and things. Only the type you started to paint select on will be selected, i.e. if you start paint selecting on a floor you can't accidentally select walls.
With the default picking interval of 80 ms it is too unreliable (no selection will happen if the mouse movement is too fast), so while paint selecting the picking interval gets reduced to 10 ms. I assume it is at 80 ms by default because of performance reasons, but I didn't notice any additional slowdown even in massive maps (like Vela Pax), but I have no means of profiling.
Video of paint selection in action:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Works just like paint selection in classic modes. No default key bound. Works on floors/ceilings, any parts of lines, and things. Only the type you started to paint select on will be selected, i.e. if you start paint selecting on a floor you can't accidentally select walls.
With the default picking interval of 80 ms it is too unreliable (no selection will happen if the mouse movement is too fast), so while paint selecting the picking interval gets reduced to 10 ms. I assume it is at 80 ms by default because of performance reasons, but I didn't notice any additional slowdown even in massive maps (like Vela Pax), but I have no means of profiling.
Video of paint selection in action:
Holy crap this is a massive productivity booster; how did we survive all these years without paint selection in 3D?! :D Awesome work!
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sat Jan 05, 2019 1:04 am
by Kappes Buur
Is there now a Visplane Explorer plugin which will
work in the x64 version of GZDBBF?
The version which comes with any of the x64 downloads
for example with GZDoom_Builder_Bugfix-r3041-x64.7z
***********SYSTEM INFO***********
OS: Microsoft Windows 10 Pro
GPU: NVIDIA GeForce GTX 660
GZDB: R3041
Platform: x64
********EXCEPTION DETAILS********
Error 193 while loading vpo.dll: %1 is not a valid Win32 application
at CodeImp.DoomBuilder.Plugins.VisplaneExplorer.VPOManager..ctor()
at CodeImp.DoomBuilder.Plugins.VisplaneExplorer.BuilderPlug.InitVPO()
at CodeImp.DoomBuilder.Plugins.VisplaneExplorer.VisplaneExplorerMode.OnEngage()
at CodeImp.DoomBuilder.Editing.EditingManager.ChangeMode(EditMode nextmode)
at CodeImp.DoomBuilder.Actions.Action.Begin()
at CodeImp.DoomBuilder.Actions.ActionManager.InvokeAction(String actionname)
at CodeImp.DoomBuilder.Windows.MainForm.EditModeButtonHandler(Object sender, EventArgs e)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStrip.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.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sat Jan 05, 2019 3:54 am
by boris
Kappes Buur wrote:Is there now a Visplane Explorer plugin which will
work in the x64 version of GZDBBF?
The version which comes with any of the x64 downloads
for example with GZDoom_Builder_Bugfix-r3041-x64.7z
It crashes because the embedded vpo.dll in VisplaneExplorer.dll is the 32 bit version - for some reason the vpo_dll project isn't in the solution (although the source code is included), so vpo.dll doesn't get rebuild when GZDB-BF is compiled for x64.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sat Jan 05, 2019 6:36 am
by Kappes Buur
boris wrote:It crashes because the embedded vpo.dll in VisplaneExplorer.dll is the 32 bit version
Hopefully this can be resolved.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sat Jan 05, 2019 7:05 am
by boris
It's a trivial fix:
Add the vpo_dll project to the solution (needs an automated conversion of the project file, since it's too old for VS 2015)
Make vpo_dll a dependency for VisplaneExplorer, so that it's guaranteed that a new vpo.dll will be compiled before the VisplaneExplorer.dll is built
Add the x64 configuration to vpo_dll. Make sure to change the output path for the x64 configuration to the same as the Win32 one (i.e. the resources directory of VisplaneExplorer), otherwise it will keep using the old DLL without you noticing. Make also sure that it's actually compiling the x64 version when you build the x64 version of the solution.
vpo_dll needs the C++ compiler, so that has to be installed.
I attached a compiled version of VisplaneExplorer that works for the x64 build of GZDB-BF.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Sat Jan 05, 2019 7:12 am
by Kappes Buur
boris wrote:I attached a compiled version of VisplaneExplorer that works for the x64 build of GZDB-BF.
Just replace your original BuilderModes.dll with it, but make a backup first. Only works with the x64 version of GZDB-BF. Make also sure to assign a hotkey (under Tools -> Preferences -> Controls -> filter for "paint".
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Posted: Mon Jan 07, 2019 10:10 pm
by Kappes Buur
boris wrote:If anyone wants to try out the paint selection in visual mode, ...
Uh, Oh. This is fantastic.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
