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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Uh... visual mode (default hotkey Q).
User avatar
TheMafla
Posts: 18
Joined: Wed Jun 20, 2018 8:28 am
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by TheMafla »

boris wrote:Uh... visual mode (default hotkey Q).
mmmm ... no, I would like to have in a separate window a static view of a part of the map, in it you can not move or edit from this window, but it would be updated every time you make a change in 2D mode. I think it is understood, or not?
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 »

As a matter of interest, when creating your own game cfg files and creating new lists/categories of things, is it possible to create sub categories. e.g. would it be possible to have a structure like:

enemies/
enemies/Doom
enemies/Doom2
enemies/Heretic
enemies/Hexen
enemies/Strife

i.e. something that would look a bit like...

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

Is there any chance Builder will get faster? It gets almost eternity to drag a single vertice here: https://imgur.com/a/mmyKmI7 I usually copy my stuff and edit it in a separate map, I'm just wondering if the same can be done but inside of one map, e.g builder would have "layers" that will be merged later if nothing else can be done to speed it up.
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 »

Darkcrafter wrote:Is there any chance Builder will get faster? .......
It seems that you have a lot of trouble doing anything in GZDBBF.
Luckily I do not suffer the same on my computer.
Spoiler:
Not knowing what your computer is like, all I can offer is to have a look at your map, if you want to send it to me. Either upload here or send via PM.
User avatar
Remmirath
Posts: 2561
Joined: Sun Dec 23, 2007 3:53 am
Graphics Processor: nVidia with Vulkan support
Location: My house
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Remmirath »

boris wrote:Well, if it's suddenly crashing in a completely different part it might not be the program, but maybe something is wrong with your computer? Damaged RAM or something like that. Or it's simply not strong enough the handle the map.
I've been getting the same crashes in random parts of the editor as well with the latest revision. More specifically, it happens on maps that make use of 3D models (haven't seen crashes happen on a map that doesn't make use of them).

My rig is brand new, with perfectly stable RAM XMP profiles, fully tested with synthetic benchmarks without freezes or crashes. Full specs:

CPU: Intel Core i7-9700k 3.6GHz
Motherboard: Asus ROG Maximus XI Formula
RAM: 32GB Corsair Vengeance LPX 3000MHz
Videocard: Asus ROG Strix GTX 1070 8GB GDDR5
OS: Windows 10 Pro x64

Reverting to older revisions gets rid of the crashing.
Last edited by Remmirath on Tue Jul 02, 2019 8:06 am, edited 1 time in total.
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 »

Remmirath wrote:My rig is brand new, with perfectly stable RAM XMP profiles, .... etc.
Interesting.
Have you tried Enjay's Gene-Tech? It is full of models.
I can play and edit it without problems, and my rig is almost an ancient albatross.
Spoiler:
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 »

Kappes Buur wrote:
Darkcrafter wrote:Is there any chance Builder will get faster? .......
It seems that you have a lot of trouble doing anything in GZDBBF.
Luckily I do not suffer the same on my computer.
Spoiler:
Not knowing what your computer is like, all I can offer is to have a look at your map, if you want to send it to me. Either upload here or send via PM.
Thanks a lot for your reply, I'll send you this map if you really want to see what I'm trying to do there. I figured out the root of the problem: it only occurs really slow if I edit everything that relates to a really huge sector. Please don't throw poos at me but what you have demonstrated to me also works ridiculuosly slow in relation to other 3d editing software, but doom isn't real 3d :cry:
User avatar
Remmirath
Posts: 2561
Joined: Sun Dec 23, 2007 3:53 am
Graphics Processor: nVidia with Vulkan support
Location: My house
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Remmirath »

Kappes Buur wrote:
Remmirath wrote:My rig is brand new, with perfectly stable RAM XMP profiles, .... etc.
Interesting.
Have you tried Enjay's Gene-Tech? It is full of models.
I can play and edit it without problems, and my rig is almost an ancient albatross.
Spoiler:
I tried GeneTech, and GZDB doesn't crash. I think the problem is related to OBJ models, whose support was recently implemented in the editor. As soon as I try to edit things, the editor crashes with the same errors Ozymandias was experiencing.

EDIT: r3064 doesn't seem to be crashing so far, but the editor console spits this message out:

Image
User avatar
Ozymandias81
Posts: 2062
Joined: Thu Jul 04, 2013 8:01 am
Graphics Processor: nVidia with Vulkan support
Location: Mount Olympus, Mars
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Ozymandias81 »

Remmirath even if these doesn't make much sense, did you try to delete your gzdbuilder.cfg from your %appdata folder (backup it) and let gzdb make a new one? It turns that the editor became more stable on my end, I got the system.drawing error only one time since my last post about the issue... I mean problem should be there yet, but it seems that pops up rarely at least. There should be also a couple of tests to do: a map where models uses only png skins, another one with jpeg skins, then again one with mixed md3 (png/jpeg) and then mixed obj/md3 and exclude maybe something.
Last edited by Ozymandias81 on Tue Jul 02, 2019 6:11 pm, edited 1 time in total.
User avatar
Remmirath
Posts: 2561
Joined: Sun Dec 23, 2007 3:53 am
Graphics Processor: nVidia with Vulkan support
Location: My house
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Remmirath »

Ozymandias81 wrote:Remmirath even if these doesn't make much sense, did you try to delete your gzdbuilder.cfg from your %appdata folder (backup it) and let gzdb make a new one? It turns that the editor became more stable on my end, I got the system.drawer error only one time since my last postabout the issue... I mean problem should be there yet, but it seems that pops up rarely at least. There should be also a couple of tests to do: a map where models uses only png skins, another one with jpeg skins, then again one with mixed md3 (png/jpeg) and then mixed obj/md3 and exclude maybe something.
I've already tried to delete the config, still happens, and as frequently as before.

A person on Discord indicated that this issue might depend on loading resources from a folder. One added detail is that the folder I'm loading resources from is a synced Dropbox folder. I'll try to load from a PK3 and report abnormal behavior, if there's any.
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 »

Is there a "quick glance" way to see some details of the line type that is tagged to a sector (and vice versa)?

What I mean by that, is something like this:

Image

This is a ZDoomHexen format version of Doom2 MAP01 in DeePsea. The platform in the penultimate room is highlighted and there is a small description of what the line tagged to the sector does and which line it is.

I know that GZDB can draw "Event lines" and these are very cool and very useful. However, on a big, complicated map backtracing to the other end of the event line just to see what type of line action is on the associated line can be difficult. Sometimes I just want a quick check to see what line is tied to a sector and what it does, rather than having to scroll around the map.

I realise that, these days, multiple lines can be tagged to sectors and scripts are also an issue but if the feature is there, I'd certainly use it. It's been quite frustrating not being able to find something like that today with the map I'm working on.



And, just to bring the idea back to the fore. The thing that I asked about before (being able to interact with the map while search results are on screen) would have come in useful today as well. I'd changed the colour of some of the textures in the map (edited them in a graphics program). The textures look like lights and were being used extensively throughout the map. The map uses a lot of dynamic lights and everywhere there is a light texture, there is a light object. Not all of the dynamic lights are in sectors using the edited texture (there are many other light textures). So, I needed to search through the many dynamic lights to find the ones that needed their colour parameters changing to suit the new texture a bit better. The easiest way to do this, of course, is to search for the texture and then switch to things mode, edit the light object and then select the next found texture in the search results list - rinse and repeat to the end of the list. That can't be done in GZDB so I went back to DeePsea to do it. It's probably the main thing that is stopping me switching across from DeePsea entirely and consequently switching across to UDMF as my default editing format too. I've "had" to go back to DeePsea several times today alone just to use the search function for stuff like this.

Please note, this is not a nag or anything like that. I fully appreciate that changing the way the search results work in GZDB would not be an easy task. I'm more just reiterating that it is a genuinely useful thing that I, and I'm certain others, would make use of if anyone had the time, inclination and skill to have a go at implementing it.
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 »

No, nothing like that is in GZDB/GZDBBF.
That might be something which could be done in a future plugin.

What you could do now, however, is set linedefs with action specials to a different colour:
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 »

Thanks for the reply. The customisability of the interface in GZDB is definitely one of the things that I really like. I've already messed around with changing a few colours. e.g. the default of the selected line being the same red as the colour used on the ends of lines for sectors with 3D floors was making finding a selected line very difficult when zoomed out. My ugly magenta choice for selected items works much better for me (can't miss that :lol: ).

I haven't really messed around with changing individual line type colours, but I keep meaning to get around to it because it will be very useful. However, in this case, it's not going to be particularly helpful. The map that I have been working on (not originally my map, just something I'm fixing up for someone else) is very large and has lots of very small control sectors and lines. So, I might highlight a sector somewhere up in the top left corner of the map and an event line traces the associated line type all the way off the screen down to the bottom right of the map. So, I have to scroll all the way across there to find the activation type. Doing so usually means that the sector becomes un-highlighted, so I loose the event lines and have to guess which of the many control lines might have been the one that I was looking for from a whole collection of small control sectors grouped together. Colouring the line type wouldn't be that helpful in this case, because I've already lost which line I'm trying to find and, what's more, I've now scrolled away from the sector and have to go back to find it too.

The best thing I have, ATM, is to search for the sector tag and use the search results instead. However, that can be time consuming (even picking the search type can take a while because there are so many (which is a good thing most of the time)) and the limited interactivity with the map kicks in at that point too.

Something like this would be the dream:
Image

And, of course, the "belt and braces" approach would be the converse; where highlighting a line (in lines mode) gives the sector number that the event line(s) is tracing to.
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

I think a better solution might be to have the actions on the event lines instead of the panel at the bottom. For a sector that gets targeted by multiple lines you'd immediately see which line does what.
Locked

Return to “Abandoned/Dead Projects”