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
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mav3r1ck »

Since GZDoom now has a feature that allows D64 colored lighting. I was going to attempt a script that changes a sectors color using this method. And for that I'd need an option that can transfer the colored lighting from one sector to another. This type of feature is key to the script. However, since it doesn't exist then it cannot be done.

In Doom 64, when you pick up certain items like a keycard or armor. The sector is colored to make it appear that these items are giving a sort of colored glow to the lower part of the sector. The items themselves are attached to a script that is connected to a colored dummy sector. When the player picks up the item the sector color will change to match the colors of the surrounding sectors.

EDIT: Earlier, I had made a feature request that would add D64's multi-layered colored lighting feature to ACS so that it can be used in scripts. This would be an alternate method. IMO it would be the more preferred method.
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 »

I misunderstood your question, but it can be done anyway, but you have to use a trick. Make a 3D floor that is the full height of the sector, and the colored lighting of the 3D floor's control sector will be transferred to the inside of the 3D floor. Make the 3D floor not solid with opacity 0, so you get nothing but the colored lighting. The same thing will work with transfer heights, which render more quickly, but is trickier to use..
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:I misunderstood your question, but it can be done anyway, but you have to use a trick. Make a 3D floor that is the full height of the sector, and the colored lighting of the 3D floor's control sector will be transferred to the inside of the 3D floor. Make the 3D floor not solid with opacity 0, so you get nothing but the colored lighting. The same thing will work with transfer heights, which render more quickly, but is trickier to use..
That trick I do know. Though it only works for normal colored lighting. Though for some reason it doesn't work for Doom 64 colored lighting though because I had attempted many times before. Considering that this is one of the more recent features for GZDoom Bugfix. I had come to the assumption that this feature isn't fully compatible with 3D sectors.
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 »

In UDMF, you can set a sectors's lighting directly, with no need to transfer it from another sector.
What you are wanting would be a new feature for GZDoom, not GZDoom Builder.
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mav3r1ck »

Duh (to myself), for GZDoom to use a feature from GZDB it has to support it. This is going to be so much fun once this feature is fully implemented. :D
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Gez »

Mav3r1ck wrote:I looked at the zdoom Wikia
If there is a ZDoom Wikia, do not look at it. Only use the actual, official ZDoom wiki on zdoom.org. Wikia is a plague.
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mav3r1ck »

Yeah, that was the one I was looking at but it did not have what I was looking for. But yes, I know what you mean.
Bridgeburner56
Posts: 12
Joined: Tue Apr 24, 2018 11:51 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Bridgeburner56 »

Been getting this crash with 3018 constantly if anyone can help

Problem signature:
Problem Event Name: APPCRASH
Application Name: Builder.exe
Application Version: 2.3.0.3018
Application Timestamp: 5ad3d7d4
Fault Module Name: StackHash_74b2
Fault Module Version: 6.1.7601.24094
Fault Module Timestamp: 5abedfcd
Exception Code: c0000374
Exception Offset: 000ce9fb
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 5129
Additional Information 1: 74b2
Additional Information 2: 74b26b94f93fbe5e1f3da23862919ad2
Additional Information 3: c03a
Additional Information 4: c03a844882803dc4d79069d1d82d57b5
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 »

Is this at startup?
Bridgeburner56
Posts: 12
Joined: Tue Apr 24, 2018 11:51 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Bridgeburner56 »

It happens mid use. Its happened 3 times since I moved to 3018 (yesterday) and I can't remember anything consistent linking each time.
Bridgeburner56
Posts: 12
Joined: Tue Apr 24, 2018 11:51 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Bridgeburner56 »

So it happened again while trying to do something in visual mode

Problem signature:
Problem Event Name: APPCRASH
Application Name: Builder.exe
Application Version: 2.3.0.3018
Application Timestamp: 5ad3d7d4
Fault Module Name: StackHash_32ce
Fault Module Version: 6.1.7601.24094
Fault Module Timestamp: 5abedfcd
Exception Code: c0000374
Exception Offset: 000ce9fb
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 5129
Additional Information 1: 32ce
Additional Information 2: 32ceebb034b291fe4b60656f0da47e34
Additional Information 3: a49a
Additional Information 4: a49aad2d48f90737419c7eadb0376c9d

And then it said "the instruction at 0x77292ad2 referenced memory at 0x00000004. The memory could not be read"
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 »

c0000374 is "heap corruption" which is probably caused by faulty libraries/plugins (not on your side)

Are you using 32-bit? Does switching to the other version (32 if you are on 64, or 64 if you are using 32) help?

edit: it seems you are using x86. Can you use x64?
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 »

Would it be possible to make the logfile identify which version of the editor was used?
At the moment the message is the same for both, 32bit or 64bit
GZDoom Builder R3018 (e9c83d0) startup
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 »

Yes, of course. I forgot to fix it there, only changed in title and in exception dialog.
Bridgeburner56
Posts: 12
Joined: Tue Apr 24, 2018 11:51 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Bridgeburner56 »

Are you using 32-bit? Does switching to the other version (32 if you are on 64, or 64 if you are using 32) help?

edit: it seems you are using x86. Can you use x64?
Unfortunately when I open my wad I get a completely black screen where the map should be. It doesn't show a specific error message suggesting that anything is wrong so I'm not sure what's going on there.

Ok, so this happens if install x86 version 3018 as well. I've installed x64 in a new folder and tired starting a new map and running it with no resources loaded but no luck. But if I install x86 3012 and then use the auto updater, Builder opens fine. Weird. Is there a x64 version of 3012?
Locked

Return to “Abandoned/Dead Projects”