GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
Locked
User avatar
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

Post by Kappes Buur »

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
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

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
WARCHILD_89
Posts: 452
Joined: Sun Nov 17, 2013 12:27 pm
Graphics Processor: nVidia with Vulkan support
Location: MIA between doomed dimensions

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by WARCHILD_89 »

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
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

Post by Kappes Buur »

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
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

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 all

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?
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

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.
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

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
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

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
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

Post by Kappes Buur »

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
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

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
Darkcrafter
Posts: 562
Joined: Sat Sep 23, 2017 8:42 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Darkcrafter »

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
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

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
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

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).
User avatar
Tormentor667
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Tormentor667 »

Code: Select all

***********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
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Tormentor667 »

And another one:

Code: Select all

***********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)
Locked

Return to “Abandoned/Dead Projects”