Page 61 of 88

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Mon Aug 27, 2018 5:14 pm
by Mav3r1ck
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?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Tue Aug 28, 2018 12:48 am
by Kappes Buur
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Tue Aug 28, 2018 7:25 am
by Mav3r1ck
Can I run DirectX 9 alongside DirectX 12? It won't replace DirectX 12 will it?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Tue Aug 28, 2018 8:57 am
by PlayerLin
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).

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Mon Sep 17, 2018 6:05 pm
by MartinHowe
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?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Thu Sep 27, 2018 10:37 am
by ZZYZX
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...

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Thu Sep 27, 2018 3:47 pm
by MartinHowe
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?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Sep 28, 2018 10:40 am
by Siberian Tiger
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,

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Mon Oct 01, 2018 12:26 pm
by Empyre
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Tue Oct 02, 2018 5:53 am
by ZZYZX
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Tue Oct 02, 2018 7:52 pm
by Empyre
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Thu Oct 04, 2018 3:46 pm
by Devianteist
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Oct 05, 2018 9:39 am
by Xabis
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Oct 07, 2018 5:24 pm
by ZZYZX
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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Mon Oct 08, 2018 11:55 pm
by Empyre
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.