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 »

ZDL_800 wrote: If the original version works then how can it be the OS?
Speaking of OS.
Darkcrafter is correct in his assessment.

Which version of Windows is installed on your computer?
User avatar
ZDL_800
Posts: 448
Joined: Wed May 15, 2019 3:06 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZDL_800 »

Hello and thankyou for the reply.

The laptop is Windows8.1 with NetFramework 4.7.2.

May I ask how can we contact the devs to the bugfix version and submit this bug?
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

You can open issues at https://github.com/jewalky/GZDoom-Builder-Bugfix/issues
at Microsoft.VisualStudio.HostingProcess.EntryPoint.Main() but unless anyone can reproduce the problem it's unlikely to be fixed, especially since it's quite likely that it's not on the application side.

Are you using a 64bit Windows? The path in the error says that you are using GZDB-BF 3050 x64. Did you auto-update to a higher version or are you really using 3050 (3060 is the latest). What happens if you try the 32bit version of GZDB-BF?
User avatar
neoworm
Posts: 1740
Joined: Fri Sep 23, 2005 9:17 am
Location: Czech Republic

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by neoworm »

I finally tried to do a custom testing map for my HeXen resources instead of summoning them ingame, but I can't find a way to force GZDB show my Zscript actors. I tried to searching this thread, but didn't find anything that would help me.
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

neoworm wrote:I finally tried to do a custom testing map for my HeXen resources instead of summoning them ingame, but I can't find a way to force GZDB show my Zscript actors. I tried to searching this thread, but didn't find anything that would help me.
There are two things you need to do:
  • Assign DoomEdNums through MAPINFO: https://zdoom.org/wiki/MAPINFO/Editor_number_definition. If you did not do so already you'll also want to add some special commands to the Default block in your class:

    Code: Select all

    //$Category "My category"
    //$Title "My thing"
    //$Sprite TROOI0
  • Add gzdoom.pk3 to the resources in GZDB-BF. Make sure to exclude if from testing
User avatar
neoworm
Posts: 1740
Joined: Fri Sep 23, 2005 9:17 am
Location: Czech Republic

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by neoworm »

Okay, thanks. Got it working finally.
Finding out that I need at least one frame as normal sprite for 3D models took a while though.
User avatar
leodoom85
Posts: 684
Joined: Sun Sep 14, 2014 6:40 pm
Location: Earth-shaking Chile

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by leodoom85 »

Ok. I have a serious problem which, I don't know how to solve.
I factory restored my laptop and then, after updating all stuff related to OS, I installed GZDB-BF r3060. And I can't open it, plain and simple, even with admin permission and no errors. I installed .Net Framework 4.7.2 and DirectX (you know...all necessary requirements for the editor to work.) and I'm using Win 7 Starter SP1, 32-bit.

I must clarify that, before doing the factory reset, r3060 worked fine after updating the editor. It's kinda the same thing that happened in r3015 or r3017 with the slimdx dll...


Edit: For some...weird reason...updating my GPU drivers, which it updates my OpenGL to 3.3, the builder now works....

So uh...Does it need a minimum version of OpenGL too for the builder to work? which can be OGL 3.3?
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 »

leodoom85 wrote: So uh...Does it need a minimum version of OpenGL too for the builder to work? which can be OGL 3.3?
If memory serves me right, the editor uses D3DX (Direct3D 9) not OpenGL.
User avatar
axredneck
Posts: 354
Joined: Mon Dec 11, 2017 2:09 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Arch
Graphics Processor: nVidia with Vulkan support
Location: Russia
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by axredneck »

leodoom85 wrote:... updating my GPU drivers...
It's recommended to always keep your GPU drivers up to date. Also by default Windows ships with very basic drivers. And Linux too if it's Nvidia.
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 »

This post is more to float an idea or two and to find out about the feasibility of these particular feature requests as anything. Until my thoughts crystalise, it's probably too much to explain on a Github comment asking about the features.


Request 1: be able to interact with the rest of GZDB (especially the mapping functions) when the find dialogue results are active.
The GZDB search feature is pretty neat. It can search for (and replace) many different types of objects and presents the search result in a nice, easy to read pop-up dialogue.

Image

When I click on the various found items in the list, the map screen jumps to that item and centres it on the screen.

So far, so good.

Then I come to try and edit the found item. That's where problems/limitations can manifest.

In DeePsea (sorry to keep harping on about it, but it's what I am familiar with) there is a very similar find functionality that up to this point behaves in much the same way as GZDB, producing a similar looking (if simpler) results dialogue that performs in a very similar way (i.e. click on a found item and the map jumps to that position and highlights the found item).

Image
(The result dialogue is simpler partly because the search type and parameters are picked from menus rather than the dialogue - many of the options in GZDB are also present in the DeePsea menus.)

However, in DeePsea I can move my mouse away from the found items list and interact with the map screen in the normal way. The found items dialogue stays on top, but I have full access to the normal 2D mapping features, the other menus, dialogues, everything. So, I can edit whatever I want on the map and then move back to the found items to click on another item.

GZDB does not let me do this.

In GZDB, the focus stays on the found items dialogue and (correct me if I'm wrong) I can't interact with the map at all.

"But Enjay, GZDB has the "Edit selection" button". True, and that does much of what I want, but the problem is, all it allows me to do is edit the selection. So, I can't - for example, move my mouse across to the map, delete the item in question, move back to the found items, pick another one and continue. I have to quit the found items dialogue, delete the item and search again.*

Or, as another example, it also means that I can't work on other items nearby that were not in the "found" list. The following is what I was doing when I generated the above pictures: I wanted to find the control sectors for 3D floors and edit the sector properties. There isn't anything to particularly identify these sectors because there is nothing unusual about them versus other sectors. So what's the best way to find 3D control sectors? Search for line type 160. The results of this search (in both GZDB and DeePsea are shown above.)

In DeePsea, I can find all of the line type 160s, click through the found items list, move my mouse across to the map area of the screen, hit "S" to enter sectors mode and hover over the control sector to see its properties to find out if it is one that I want to edit. If it is I can then hit enter to edit the sector, finish what I want to do with it, go back to the found items list and click on the next entry (which would then jump the map to centre on the next found line 160) and I can rinse and repeat until I have found all of the sectors that I want to change.

With GZDB, the above, basically, can't be done. I can't change to sector mode in the map without closing the found items dialogue (so I can't quickly check if the found line is attached to a sector that I want to edit) and I certainly can't edit, delete or otherwise change anything other than the found line. So, doing the above task is a much longer process because every time I jump to a new line 160, I have to exit the found items dialogue, go to sector mode, check the sector's properties (and edit if necessary) then start a new search, remember where I was on the found items last time, scroll to that entry, pick the next one, rinse and repeat. It's actually quite a pain, especially if the found items list is long (as in the above example) and it's a pretty major limitation IMO.


So, as I said, I'm pretty sure that the functionality that I am looking for is not (currently) in GZDB. I guess my concern is that such an addition feels like it might be quite a fundamental change to the way this particular aspect of GZDB works (programming and window priority-wise) and, therefore, may not be that feasible. What do people think? Is there any merit in being able to do this (obviously I think so and I use it all the time in DeePSea - and not having it really hampers my mapping in GZDB). How feasible would it be for a GZDB dev to implement?

*I know that when I delete items with this method, sooner or later the map goes out of synch with the found items list and a new search is needed anyway. However, scrolling to the end of the list and working upwards, deleting the highest numbered items first, minimises the need to re-search too often.


Request 2: be able to output the results of the find and error dialogues to a text file.
As a second, associated, feature request, it's also worth pointing out another very useful button on the DeePsea version of the find results dialogue: the ability to "Save as Text". What this actually does is open a copy of your text editor (notepad by default, but configurable (mine opens Textpad)) and the readout from the found items list is sent to the text editor. Very, very useful. I use it a lot.

Similar "Save as Text" functionality exists for other dialogues like the error checker (I've posted the results of the DeePsea error checker on these forums for people dozens of times). Being given a text readout of things such as missing textures names in a map (or whatever) allows me to use the search features of my text editor and do things like have a text file open in one window and an explorer folder in another while I search for missing textures in the list and matching texture file names (to add them to a resource file) in explorer. Or I can use the output from the dialogues and macros in my text editor to generate batch files that I then use to manipulate lumps with external tools etc etc. The possibilities are endless.

Again, I don't *think* that this can currently be done in GZDB but being able to get save readouts from these dialogues would be a very welcome thing to be able to do.

To illustrate:
A quick error check on MAP01
Image

and text file output:

Code: Select all

Error Checker       

-- 00000 ** Change Error Check Options to ignore some errors  **        
-- 00000 *  !!  TEXTURES checked are per current SETTINGs  !!  *        
-- 00000 ** Remove Error Dialog option to manually see errors **        
-- 00000         
L  00334 Linedef 334: sideDef2 478 has no lower texture        
L  00335 Linedef 335: sideDef2 480 has no lower texture        
L  00369 Linedef 369: sideDef2 528 has no lower texture  

So, thoughts on any of this? :)
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Enjay wrote:Request 1: be able to interact with the rest of GZDB (especially the mapping functions) when the find dialogue results are active.
Not possible the way the Find and Replace functionality is implemented. It's actually its own mode, just like sectors mode or things mode for example (except that it's "volatile", i.e. when being done with whatever you're doing it returns you to the mode you activated it from. Fun fact: nearly everything that interacts with a map is a mode, even dragging things or geometry switches to special dragging modes).
Enjay wrote:Request 2: be able to output the results of the find and error dialogues to a text file.
I guess the easiest way to implement something like that is to allow the user to press Ctrl+C to copy the selected results to the clipboard.
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 »

boris wrote:Not possible the way the Find and Replace functionality is implemented. It's actually its own mode, just like sectors mode or things mode for example (except that it's "volatile", i.e. when being done with whatever you're doing it returns you to the mode you activated it from. Fun fact: nearly everything that interacts with a map is a mode, even dragging things or geometry switches to special dragging modes).
I didn't know the technicalities of what was going on, but I suspected something like that might be a block to what I asked about being implemented. Thanks for the answer. At least I know.
boris wrote:I guess the easiest way to implement something like that is to allow the user to press Ctrl+C to copy the selected results to the clipboard.
That would do it.
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Enjay wrote:
boris wrote:Not possible the way the Find and Replace functionality is implemented. It's actually its own mode, just like sectors mode or things mode for example (except that it's "volatile", i.e. when being done with whatever you're doing it returns you to the mode you activated it from. Fun fact: nearly everything that interacts with a map is a mode, even dragging things or geometry switches to special dragging modes).
I didn't know the technicalities of what was going on, but I suspected something like that might be a block to what I asked about being implemented. Thanks for the answer. At least I know.
I'm not saying that it's impossible to change. The mode is pretty trivial, most of the logic is handeled by the dialog and a bunch of classes that are not directly related to the mode, but there must be a reason why CodeImp implemented it that way. Out of the top of my head I can think of two things: a) the list of found objects and what's in the map could go horribly out of sync, b) functionality outside the current mode has no influence whatsoever on how things are drawn. I.e. when you're in sectors mode things are rendered translucent, and an independed Find and Replace functionality couldn't draw found things opaque (but it could select them).
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 »

Been getting this tonight:

Code: Select all

Update check failed: failed to retrieve remote revision info.
Check your Internet connection and try again.
Clearly my Internet connection is fine because I'm posting here. Anyone know what's going on?
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Enjay wrote:Been getting this tonight:

Code: Select all

Update check failed: failed to retrieve remote revision info.
Check your Internet connection and try again.
Clearly my Internet connection is fine because I'm posting here. Anyone know what's going on?
It's down temporarily: viewtopic.php?p=1107915#p1107915
Locked

Return to “Abandoned/Dead Projects”