GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Any utility that assists in the creation of mods, assets, etc, go here.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Mav3r1ck » Mon Aug 27, 2018 5:14 pm

Kappes Buur wrote:
Mav3r1ck wrote:I just got my first gaming computer and attempted to start up GZDB-BF but when I do it will show the cursor as if it was opening up the program and then nothing happens. I'm not sure of what to do here.

Check the bottom of this webpage for requirements.


I tried an earlier revision and it started up but crashed when I loaded a map. It was something about the Slim and it said "ERROR_MOD_NOT_FOUND".

My new computer came with DirectX 12. Do I need DirectX 9 to run this?
User avatar
Mav3r1ck
 
Joined: 17 Jul 2015

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Tue Aug 28, 2018 12:48 am

Mav3r1ck wrote:I tried an earlier revision and it started up but crashed when I loaded a map. It was something about the Slim and it said "ERROR_MOD_NOT_FOUND".

Since r3030, GZDB-BF is compiled with .NET 4.
Go to the SlimDX website and download
the End User Runtime for ".NET 4.0", either "x86 Download" or "x64 Download", depending on which version of GZDB-BF you use.


Mav3r1ck wrote:My new computer came with DirectX 12. Do I need DirectX 9 to run this?

Since GZDB-BF is derived from GZDB, yes you need to install DirectX 9.
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Mav3r1ck » Tue Aug 28, 2018 7:25 am

Can I run DirectX 9 alongside DirectX 12? It won't replace DirectX 12 will it?
User avatar
Mav3r1ck
 
Joined: 17 Jul 2015

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby PlayerLin » Tue Aug 28, 2018 8:57 am

Mav3r1ck wrote:Can I run DirectX 9 alongside DirectX 12? It won't replace DirectX 12 will it?


Each version of Direct X is independent, never replace the other versions, so yes, you can run, you just needed to install it if your system never installed any of Direct X 9 runtimes(same goes with 10 and 11).
User avatar
PlayerLin
 
Joined: 11 Nov 2007
Location: XinZhuang, XinBei/New Taipei City(Former Taipei County), Taiwan.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby MartinHowe » Mon Sep 17, 2018 6:05 pm

Interesting issue here: Application crash on startup from 64 bit build but not on 32 bit build:

Code: Select allExpand view
Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   Builder.exe
  Application Version:   2.3.0.3039
  Application Timestamp:   5b5875c0
  Fault Module Name:   KERNELBASE.dll
  Fault Module Version:   6.1.7601.24231
  Fault Module Timestamp:   5b6db5dd
  Exception Code:   e0434352
  Exception Offset:   000000000001a06d
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:   2057
  Additional Information 1:   367e
  Additional Information 2:   367e805d0e7c1ec3f63b05bb5ce5c416
  Additional Information 3:   3838
  Additional Information 4:   3838c9f6226fa1f240e24ad80883af36


This is the build of GZDB from DRDTeam date July 25
The machine is a Windows 7 Pro x 64 VM hosted in VirtualBox on 64 bit Xubuntu. The graphics driver is the experimental WDDM VBox driver so I thought that might be the problem; however, the 32 bit build of GZDB runs fine.

If you would need more information, is there a debug build of the 64 bit version of GZDB that I can try?
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Thu Sep 27, 2018 10:37 am

This is probably caused by DevIL. There isn't a special debug build available, I can make one but you seem to have a crash in native code so making a debug GZDB probably wouldn't help...
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby MartinHowe » Thu Sep 27, 2018 3:47 pm

ZZYZX wrote:This is probably caused by DevIL. There isn't a special debug build available, I can make one but you seem to have a crash in native code so making a debug GZDB probably wouldn't help...

OK; I guess I can live with it as the 32-bit build works OK. I'm just puzzled that the bit size makes a difference. Or is DevIL a 32-bit only library and the WoW64 doesn't interact with it correctly?
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Siberian Tiger » Fri Sep 28, 2018 10:40 am

Hallo,

If I may ask for a small feature request (or maybe it is a bug?), is it possible that the UI for the Script Editor be changed (or scaled) to be viewed better with screen resolutions that have a high-DPI? Presently, the icons and the taps are kinda small for me to read or see.

For example, I am using my Surface Pro 4 using a screen resolution of 2736x1824 with the DPI scaling set to 200%

Spoiler: "Images"



Thank you for your time,
User avatar
Siberian Tiger
 
Joined: 13 Jun 2009
Location: United States

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Empyre » Mon Oct 01, 2018 12:26 pm

I have an idea that might have been brought up before in this long thread: When opening or saving a map, let the user open a PK3 file as if it were a folder, so he can browse within it for wads containing maps, which could then be edited in situ. The only thing left after that would be to add the ability to make a new PK3 like you would a new folder. Oh, and the ability to save-as a copy of the PK3 like you can now with wads.

Another issue that I have mentioned before is that the Zandronum UDMF config file is doing something wrong that the ZDoom UDMF config file is doing right, causing textures and flats from a PK3 to be missing in the 3D view. Somebody who knows how to edit those config files, which I don't, could probably fix that relatively easily.

These are suggestions, not demands. I understand that you are doing this as a hobby, not as a job, and I appreciate what you are doing.
User avatar
Empyre
The Ultimate Shining Example of Humility
 
Joined: 05 Apr 2007
Location: Garland, TX, USA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Tue Oct 02, 2018 5:53 am

PK3 editing is complex.
I'll look at the Zan config though.

Also: I don't have a high DPI screen to test >_>
The script editor basically uses ScintillaNET from what I know.

Also (x2): Empyre do I look like maxed? lol. (about the last line :Р)

Also (x3):
MartinHowe wrote:OK; I guess I can live with it as the 32-bit build works OK. I'm just puzzled that the bit size makes a difference. Or is DevIL a 32-bit only library and the WoW64 doesn't interact with it correctly?

I have no idea how/why DevIL breaks, I just know that it's actually the only native library used by GZDB and most crashes in native code are caused by that one. It also started to happen after DevIL update (because the old one, used in R3012 and earlier, doesn't have a 64-bit version). Also in some crash logs it states DevIL.dll as the cause, but not always.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Empyre » Tue Oct 02, 2018 7:52 pm

I am not suggesting that you open a PK3 like a WAD. If you open a PK3 like a folder (it is just a ZIP file, after all), any map inside will have to be in a WAD file, which you already know how to edit. If it is not as simple as I think it is, I will take your word for it and drop it.

i wasn't even thinking about MaxEd. I just thought I might be coming across as some jerk making demands, and I also thought that maybe you could use some encouragement, but I do remember what happened with maxEd, and I don't want that to happen again.
User avatar
Empyre
The Ultimate Shining Example of Humility
 
Joined: 05 Apr 2007
Location: Garland, TX, USA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Devianteist » Thu Oct 04, 2018 3:46 pm

So, I'm not sure what's going on, but GZDoom Builder Bugfix will not launch, nor does it even seem to try. I've read the OP, downloaded everything, but it still doesnt work.

What did I do wrong?


Update your DirectX Runtimes my friends. It will save you exposing how silly you are, like I just did.
Last edited by Devianteist on Fri Oct 05, 2018 8:08 pm, edited 1 time in total.
User avatar
Devianteist
Daddy Dev, resident lurking user.
 
Joined: 24 Sep 2014
Location: Creating a SPACE HULK total conversion!
Discord: #0561

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Xabis » Fri Oct 05, 2018 9:39 am

Hello,

Trying to build from a fresh clone and there seems to be a missing file. Was it not checked in?
Error CS2001 Source file 'C:\dev\GZDB\Source\Core\Controls\FolderSelectDialog.cs' could not be found.

This change was made in commmit 1933b0b6de32bd1ba422971442998658796de898. back in July.
Xabis
 
Joined: 06 Mar 2013

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Oct 07, 2018 5:24 pm

Empyre wrote:I am not suggesting that you open a PK3 like a WAD. If you open a PK3 like a folder (it is just a ZIP file, after all), any map inside will have to be in a WAD file, which you already know how to edit. If it is not as simple as I think it is, I will take your word for it and drop it.

This is not complex as in very complex algorithms involved, but more complex as in it requires some non-monkey coding to accomplish and might take some days to implement.
The difference between loading a WAD from a folder and loading a WAD from a PK3 is that I load it from folder by using one API (filesystem one), while with filesystem->PK3->WAD there's one layer added.

I also have no idea how I'll implement saving into a PK3 because I haven't looked into the current load/save mechanism much and I think saving into PK3 would require severe refactoring (because there's 2 levels of abstraction and I'll have to save the current PK3 and the location of WAD and mapname inside that PK3 instead of just mapname, also "unpack wad -> save map -> pack wad", plus I'm not sure if the ZIP library used supports writing, not just reading...)

Also: there are at least two ways to add maps in a PK3, they look similar but one is intended while another works by accident. First, you can put your map to /maps/ and then it'll be loaded as wad's name (IIRC). Second, you can put your map to a .wad file that sits anywhere in your PK3, and then it'll load by "wad in zip" mechanism. So yea this will need some actual nested file selection dialog to work.

So to sum it up: not interested right now, might do in few days/weeks :roll:


Xabis: yes. One moment, will fix. Sorry for that.
edit - pushed
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Empyre » Mon Oct 08, 2018 11:55 pm

ZZYZX wrote:not interested right now, might do in few days/weeks :roll:

There is no hurry. If you do it at any time in the future, that would be awesome. If you decide not to, I am pleased that you at least considered it.
User avatar
Empyre
The Ultimate Shining Example of Humility
 
Joined: 05 Apr 2007
Location: Garland, TX, USA

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: Ultimate Freedoomer and 1 guest