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
StrikerMan780
Posts: 485
Joined: Tue Nov 29, 2005 2:15 pm
Graphics Processor: nVidia with Vulkan support
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by StrikerMan780 »

If anyone is dependent on any third-party plugins, and wishes to see them supported in 64-bit, please PM me a link to their thread or github.
User avatar
ramon.dexter
Posts: 1519
Joined: Tue Oct 20, 2015 12:50 pm
Graphics Processor: nVidia with Vulkan support
Location: Kozolupy, Bohemia

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ramon.dexter »

Yep, the 64b version crashes upon startup. Maybe the 3D floor plugin?
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 »

For me the x64 version crashes upon closing an editing session.
Reported as issue #199.
Spoiler:
StrikerMan780 wrote:If anyone is dependent on any third-party plugins, and wishes to see them supported in 64-bit, please PM me a link to their thread or github.
https://github.com/biwa

Looking at the crash log, are any of the default plugins compatible?
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

The 64-bit version seems to have automated building issues. Going to fix soon

edit:
One of the issues (stack trace with OnMapCloseEnd, issue #199) was resolved by making plugins build in non-optimized mode (Builder.exe, where the renderer and ZScript parser is, is still optimized).
It might have also fixed the other crash-on-startup issues, but needs testing by other people.
User avatar
Batandy
Posts: 1277
Joined: Tue Jul 19, 2011 2:56 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Batandy »

Other than what Kinsie mentioned, even if i update manually with a clean installation, i get a black screen in the render window and can't do anything, i'm forced to roll back to r3012
Image
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Apparently the root of the issue is the updated DevIL.dll, as it also seems to cause issues with PNG loading (IL_INVALID_HEADER) and crash the 3D mode (https://pastebin.com/vkYFjMuq).
Currently experimenting with downgrading the version while retaining the 64-bit one, or even switching to some other image library which doesn't have as much building issues (I can't seem to find any old DevIL binary builds for x86, let alone x64..)
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Crashes on startup should be fixed now (as of R3018). Thanks to various people (notably StrikerMan780 and leodoom85) for research and most importantly testing.
Apparently this was caused by improper SlimDX update during the project upgrade from .NET 3.5 to 4.6. Please report if it still crashes on startup :roll:
The random DevIL-related crash was not fixed yet, but I'll probably remove DevIL some time later.
User avatar
Mysterious Haruko
Posts: 12
Joined: Fri Nov 25, 2016 5:36 pm
Location: Purple Sky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mysterious Haruko »

Hello, so I've got new bug for you for in newest gzdoom builder bugfix version. This time, I have crash log, which looks like this :

Code: Select all

***********SYSTEM INFO***********
OS: Microsoft Windows 10 Home
GPU: Intel(R) HD Graphics Family
GZDB: R3018

********EXCEPTION DETAILS********
Object reference not set to an instance of an object.
   at CodeImp.DoomBuilder.Map.Vertex.Move(Vector2D newpos) in w:\dev\GZDoom-Builder\Source\Core\Map\Vertex.cs:line 278
   at CodeImp.DoomBuilder.BuilderModes.DragGeometryMode.MoveGeometryRelative(Vector2D offset, Boolean snapgrid, Boolean snapgridincrement, Boolean snapnearest, Boolean snapcardinal) in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\ClassicModes\DragGeometryMode.cs:line 315
   at CodeImp.DoomBuilder.BuilderModes.DragGeometryMode.Update() in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\ClassicModes\DragGeometryMode.cs:line 559
   at CodeImp.DoomBuilder.BuilderModes.DragGeometryMode.OnMouseMove(MouseEventArgs e) in w:\dev\GZDoom-Builder\Source\Plugins\BuilderModes\ClassicModes\DragGeometryMode.cs:line 597
   at CodeImp.DoomBuilder.Windows.MainForm.display_MouseMove(Object sender, MouseEventArgs e) in w:\dev\GZDoom-Builder\Source\Core\Windows\MainForm.cs:line 1191
   at System.Windows.Forms.Control.OnMouseMove(MouseEventArgs e)
   at System.Windows.Forms.Control.WmMouseMove(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
What I did before to get this crash? I just drew round sector with "draw ellipse mode"(it was somewhere 3120 in all sides) in gzdoom udmf, moved it and seek for comfortable position and sector started act weird-instead of moving sector, it started to move round linedefs, leaving what's inside and builder got crazy and crashed like this. Linedefs were closed. I'll leave image in spoilers to save space. I don't know if this error is easy to replicate, I use 64-bit version of gzdoom builder.
Spoiler:
Last edited by Blue Shadow on Mon Apr 16, 2018 7:00 pm, edited 1 time in total.
Reason: Used [imgur] tag on screenshot(s).
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mav3r1ck »

I've more or less found a method for applying D64-like colored lighting to 3D sectors. Create two overlapping 3D sectors in the parent sector. Lower one of the 3D sectors to floor level and raise the other one into the air to which ever height is preferred. Apply D64 colored lighting to the dummy sector (used for 3D sectors) so that the colors show below it and the parent sector so that it will show the colors above the 3D sector. Also be sure to check the "Restrict Lights Inside" flag for the 3D sector. As this is essential for this trick. And that should do it.

If there are future plans to make D64 colored lighting compatible for 3D sectors (and ACS scripting, which would be awesome). I'd suggest going ahead and doing so.

EDIT: Uploaded it anyway to get a gist of what I mean. It looks really cool ingame. Do not check the "Restrict Lights Inside" flag. This was a test from an earlier attempt. If this flag is check then you won't be able to apply light shading to the 3D sectors. :)
Attachments
Example.wad
(8.07 KiB) Downloaded 62 times
Last edited by Mav3r1ck on Sat Apr 21, 2018 1:06 am, edited 1 time in total.
XxMiltenXx
Posts: 219
Joined: Wed Jan 08, 2014 8:40 am
Graphics Processor: nVidia with Vulkan support
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by XxMiltenXx »

I have 2 requests for this project:

1. If you select 2 different actors which both share the exact same DECORATE Argument Keys, the arguments name will not be shown and treated as if they the keys are different. Could just be adjusted if they are completely the same?

2. Would it be possible to implement "Inheritance" for the Thing Type search? Could be made as an option that could be ticked when searching. (e.g. if I look for Thing Type 1 with the Inheritance box checked, it will also look for 2 and 3 if they inheritated from 1).
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 »

@Xabis
Spoiler:
Would you be able to make the Drawtext plugin compatible with x64, please.
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mav3r1ck »

Does this support a feature that allows you to transfer colored lighting from a dummy sector to a parent sector?
User avatar
Empyre
Posts: 68
Joined: Thu Apr 05, 2007 10:39 pm
Location: Garland, TX, USA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Empyre »

Mav3r1ck wrote:Does this support a feature that allows you to transfer colored lighting from a dummy sector to a parent sector?
Yes. I know you can do that in UDMF format, and I think you can in Doom-in-Hexen, too.
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mav3r1ck »

Empyre wrote:
Mav3r1ck wrote:Does this support a feature that allows you to transfer colored lighting from a dummy sector to a parent sector?
Yes. I know you can do that in UDMF format, and I think you can in Doom-in-Hexen, too.
I looked at the zdoom Wikia but I couldn't find what I was looking for. Would you be able to tell me?
Kotti
Posts: 86
Joined: Tue Dec 27, 2016 4:08 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Kotti »

Such a feature does not exist. You can set a color directly but there is no transfer function. Why do you need one?
Locked

Return to “Abandoned/Dead Projects”