GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Any utility that assists in the creation of mods, assets, etc, go here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Mon Jul 08, 2019 11:04 am

Just a suggestion, until such functionality is part of GZDBBF:
how about converting the map to DiH until all edits are done and then converting back to UDMF.
At least then you can use Deepsea for the editing sessions.

If it is not possible to add the linedef action special to the sector dialog, like this for example (my preference)

Spoiler:

then boris's suggestion seems 'simple' and straight forward, if it can be disabled as to not clutter the editing area.
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Mon Jul 08, 2019 1:30 pm

I like boris' suggestion and yours. Both work for a quick glance and that's all they would be needed for. The actions on the event lines (boris' suggestion) would be nice and clear about which line was pointing to what.



The problem with editing in DiH and then converting to UDMF is that as a map becomes increasingly complex, the conversion does too.

For example, I currently have a map with many reverb/sound environment zones and those need to be bound by line type 121 with flags set to 1 in DiH mode. There are also a bunch of other line type 121s used elsewhere for a whole variety of things. Of course, line type 121 isn't in UDMF so all of those lines would need to be found manually and edited to work as intended.

Similarly, some activation types do not transfer across (though the GZDB checker can now look for lines without activation types) and monster activations work differently in UDMF to DiH mode. And yet further, there are some things that can be done in UDMF that can't be done in DiH but there are other things that can be done in DiH (or an approximation thereof) but they need to be done in a different way. So there is then a choice of "do I hold off doing that little bit of the map until I convert, or do I do it now in DiH mode before I forget about it".

I mean, it is a solution and I have used it in the past but it does have limitations and can create work too.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby WARCHILD_89 » Tue Jul 09, 2019 12:58 pm

Hey Guys, a minor issue and I hope I am posting on the right thread for that.

Am I the only one being annoyed of this window not being scalable?



It´s a pain scrolling through the whole list instead of seeing it all at one with full paths.

I need to see the resource list very often because it changes very often and the list is often very long. And sometimes it helps finding resources again where I cannot remember the path.


on a 27" HD screen it would be easier to have this window scalable instead of scrolling around all the time and waiting to get the full path lengh shown..... for the sake of user friendlyness and flexibility.
Attachments
Unbenannt_.JPG
User avatar
WARCHILD_89
DOOM NEMESIS / 3D MODELS / RESOURCE BACKUPS
 
Joined: 17 Nov 2013
Location: MIA between doomed dimensions

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Tue Jul 09, 2019 4:30 pm

WARCHILD_89 wrote:Am I the only one being annoyed of this window not being scalable?

Probably.
I've never seen anyone else mention that in the last twelve years.

WARCHILD_89 wrote:I need to see the resource list very often because it changes very often and the list is often very long. And sometimes it helps finding resources again where I cannot remember the path.

You could edit the list of add-ons much easier in File Explorer.
Stick everything into one folder and then add that folder to the resource list:

Spoiler:
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Sat Jul 20, 2019 5:41 am

Not sure if this is a bug or just the way it is, so here goes...

My LOCKDEFS lump seems to be confusing GZDB. When I try to make a line into a locked door, instead of showing the names of the keys, I just get Lock1, Lock2...

Normal:
Image

With my lockdefs loaded
Image

My LOCKDEFS redefines all of the locks, but they are basically very similar to the default Doom ones. The differences are that wherever RedCard, BlueCard, YellowCard, RedSkull, BlueSkull, YellowSkull is normally used NJRedCard, NJBlueCard, NJYellowCard, NJPinkCard, NJGreenCard, NJIOrangeCard are used as well. In addition, the Heretic Keys can also be picked up and these are functionally the same as the Doom key cards (with the green key acting in the same way as a RedCard).

So, all my LOCKDEFS does is redefine each lock type so that any key of the appropriate type (original, my version, Heretic version) should operate the lock. However, I think it might be the fact that every lock has multiple keys allocated to it that causes GZDB to not be able to cope.

Code snippet...
Code: Select allExpand view
CLEARLOCKS

Lock 1 Doom
{
   Any { NJRedCard RedCard KeyGreen }
   Message "This needs a Red key."
   RemoteMessage "This needs a Red key."
   Mapcolor 255 0 0
}


Lock 2 Doom
{
   Any { NJBlueCard BlueCard KeyBlue }
   Message "This needs a Blue key."
   RemoteMessage "This needs a Blue key."
   Mapcolor 0 0 255
}


Lock 3 Doom
{
   Any { NJYellowCard YellowCard KeyYellow }
   Message "This needs a Yellow key."
   RemoteMessage "This needs a Yellow key."
   Mapcolor 255 255 0
}


It all works in game but, as I said, it confuses GZDB. I note from the GZDB documentation that LOCKDEFS is used to get the information about locks/keys:

LOCKDEFS:
Lock definitions are loaded. The values are used to populate "keys" Game Configuration enum.
You can specify a lock title by adding "//$Title" special comment inside a lock's definition body.


I can use that last part (//$Title) to fix the issue. It works, so I no longer have a problem. However, I also note that the game cfg files also have entries for the key enums and these do not work to fix the issue.


So, I guess the short version is, is a LOCKDEF of the type I am talking about supposed to be parsed in a more friendly manner, or are things working as they should be?
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Sat Jul 20, 2019 6:41 am

GZDB-BF can't pull the lock names out of thin air. If there's no LOCKDEFS it uses whatever is defined in the config file. If there's a LOCKDEF it uses that, but in that case you need to specify a title. If you look at the LOCKDEFS in gzdoom.pl3 you'll notice that all the keys have the //$Title special comment.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Sat Jul 20, 2019 6:48 am

Fair enough. Good to know. I just thought that it was worth checking. I thought, maybe, GZDB would read the names of the actors (key types) allocated to the locks and use them and somehow I'd confused things with my definitions. I can see how that could be easily broken though.

The //$Title special comment does exactly what it is supposed to. Thanks.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Sat Jul 20, 2019 7:28 am

To chip in to the crash-related posts with something that may, or may not, be related to the ongoing discussions, I have been getting occasional unceremonious dumps to the desktop (i.e. GZDB just quits with no message).

I *think* it might be related to lots of sprites being loaded in a resource-heavy mod.

Even when I don't get a crash, if I am zooming around the world in visual mode, I get quite a lot of momentary slow-downs in performance if I change direction suddenly or enter a new area. Toggling things off fixes this. It does not seem to be dynamic lights related: it happens whether the world is being rendered full-bright or not and even when I have disable dynamic light rendering, but toggling things off cures the problem.

Anyway, where I can get the crash more reliably (but not always) is if I try to jump into visual mode before all of the resources are loaded and swing the mouse around to try to see in lots of directions quickly. (Resource loading typically takes 23 seconds-ish with this mod.) If I am going to get the crash, GZDB feels like it is going to stutter as described in the above paragraph. However, rather than being a momentary stutter, the freeze lasts for two or three seconds and then I'm dumped out of the editor with no message.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Sat Jul 20, 2019 2:28 pm

Converning issue#279:

The tower is visible if you move above the ceiling

Spoiler:


I guess it would have something to do with rendering across two planes that the tower is not visible when looked at from below the ceiling.
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Sat Jul 20, 2019 7:29 pm

Kappes Buur wrote:The tower is visible if you move above the ceiling

Yeah, I know that if you move around you can see it and so editing it is possible. It's just a shame that you can't easily get an impression of what the area will look like in game from seeing it in the editor.

It's not a big deal, but if it was something that could be addressed easily (I suspect that it can't), it would be nice to have.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Darkcrafter » Sun Jul 21, 2019 3:41 am

Hello there, is there any way to expand map boundaries in the editor? I would like to get that feature to place my huge 3d models in the far so it doesn't get looking cheap as it does if used inside of a skybox; even dynamic skybox script doesn't look as good as if it was placed right in the map, plus it gets distorted if a player rapidly moves from one sector to another (portals).
User avatar
Darkcrafter
 
Joined: 23 Sep 2017
Location: South Russia
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Fri Jul 26, 2019 3:12 am

Sound Propagation Mode! Oh my goodness! I've just got through using this properly for the first time. What a godsend!

I'd been working on a map where enemies kept waking up when I didn't want them to, and I couldn't figure out why. I'd fired up Sound Propagation Mode a few times in the past but was never that impressed because "it just showed the whole map in green" (doh!). Image

However, when I realised that clicking on lines in this mode wasn't selecting them, but toggling the "blocks sound" flag and that, eventually I could see the results - in real time - when I finally started to isolate areas, I was blown away. Eventually I was able to chop the map up into nice little "sound-zones": something I don't think I would ever have managed without this mode as there were so many little lines and unnoticeable features that let sound "leak" through.

Amazing! Image
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Fri Jul 26, 2019 1:32 pm

Glad you like it. It's also fun to look through the stock maps and see where the original mappers failed in using the sound block lines properly (although some errors, like in Doom 2 map01, can be attributed to their level compiler).
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Tormentor667 » Sun Jul 28, 2019 2:09 pm

Code: Select allExpand view
***********SYSTEM INFO***********
OS: Microsoft Windows 10 Enterprise
qRadeon RX 580 Series
GZDB: R3072qq
Platform: x64

********EXCEPTION DETAILS********
Data reader is suspended
   bei CodeImp.DoomBuilder.Data.WADReader.GetSpriteData(String pname, String& spritelocation)
   bei CodeImp.DoomBuilder.Data.DataManager.GetSpriteData(String pname, String& spritelocation)
   bei CodeImp.DoomBuilder.Data.SpriteImage.LocalLoadImage()
   bei CodeImp.DoomBuilder.Data.SpriteImage.LoadImage()
   bei CodeImp.DoomBuilder.BuilderModes.BaseVisualThing.Setup()
   bei CodeImp.DoomBuilder.BuilderModes.BaseVisualMode.CreateVisualThing(Thing t)
   bei CodeImp.DoomBuilder.VisualModes.VisualMode.DoCulling()
   bei CodeImp.DoomBuilder.VisualModes.VisualMode.OnProcess(Int64 deltatime)
   bei CodeImp.DoomBuilder.BuilderModes.BaseVisualMode.OnProcess(Int64 deltatime)
   bei CodeImp.DoomBuilder.Windows.MainForm.processor_Tick(Object sender, EventArgs e)
   bei System.Windows.Forms.Timer.OnTick(EventArgs e)
   bei System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Tormentor667 » Mon Jul 29, 2019 4:44 pm

And another one:
Code: Select allExpand view
***********SYSTEM INFO***********
OS: Microsoft Windows 10 Enterprise
GPU: Radeon RX 580 Series
GZDB: R3072
Platform: x64

********EXCEPTION DETAILS********
Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei CodeImp.DoomBuilder.Data.WADReader.Suspend()
   bei CodeImp.DoomBuilder.Data.DataManager.Suspend()
   bei CodeImp.DoomBuilder.MapManager.SaveMap(String newfilepathname, SavePurpose purpose)
   bei CodeImp.DoomBuilder.General.SaveMap()
   bei CodeImp.DoomBuilder.Actions.Action.Begin()
   bei CodeImp.DoomBuilder.Actions.ActionManager.InvokeAction(String actionname)
   bei CodeImp.DoomBuilder.Windows.MainForm.InvokeTaggedAction(Object sender, EventArgs e)
   bei System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   bei System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   bei System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   bei System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   bei System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   bei System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   bei System.Windows.Forms.Control.WndProc(Message& m)
   bei System.Windows.Forms.ToolStrip.WndProc(Message& m)
   bei System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: boris and 1 guest