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.
User avatar
ibm5155
Posts: 1268
Joined: Wed Jul 20, 2011 4:24 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ibm5155 »

Hey ZZYZX , can you bring this feature back?

Code: Select all

#include "D:\Desenvolvimento\mods\MT2D\MT2D_Display.acs"
to 
#include "MT2D_Display.acs"// loads from the map folder // worked before
or
#inclde "./MT2D_Display.acs" // loads from the map folder
Gzdoom builder just wants the full path, and it's kinda bad when I move it from directory and even when other people play with the code :S
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

What's that feature and where should it load from?
I think it should load it as a lump name from resources.
User avatar
Ozymandias81
Posts: 2063
Joined: Thu Jul 04, 2013 8:01 am
Graphics Processor: nVidia with Vulkan support
Location: Mount Olympus, Mars

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Ozymandias81 »

So now I need to follow this for GZDB related things, ok :)

Sad thing that MaxED has been departed, hopefully he'll be back in the future... who knows. Thanks ZZYZX!
User avatar
ibm5155
Posts: 1268
Joined: Wed Jul 20, 2011 4:24 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ibm5155 »

ZZYZX wrote:What's that feature and where should it load from?
I think it should load it as a lump name from resources.
That's the script editor from gzdoom builder, under the file "SCRIPTS" you could load acs files form the system folder, but in some new update from MaxEd, I was forced to type the full path from the external acs file and not just the name of it, if it was under the map folder...

Example:
Here're my map folder:
C:\Zdoom\MyMap\
inside of it we have these files/ folders:
[MyAcs]
MAP01.wad

inside of MyAcs folder there are these files:
Rain.acs
Monster.acs

Before the change, I could just do this to load those external acs files:

Code: Select all

#include "MyAcs/Rain.acs"
#include "MyAcs/Monster.acs"
But now, I need to type the full path to load those acs files

Code: Select all

#include "C:\Zdoom\MyMap\MyAcs\Rain.acs"
#include "C:\Zdoom\MyMap\MyAcs\Monster.acs"
What does that code do? it gets all the code inside rain.acs and monster.acs and paste it inside the scripts file, and then it compile it with a compiler and save the compiled file in the behavior lump from the map.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

What happens if you make something like AcsLib directory and add it to GZDB as excluded from testing resource?
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Nevander »

Any idea what could cause a message like this:

Unable to make file image. AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Came up randomly while I was in visual mode. Had Firefox open playing music on YouTube, which uses a lot of RAM. Did GZDB try to save the temporary map copy in memory being used by Firefox? Wild guess but it's the first time I've seen this and I don't usually listen to music in my browser while mapping, usually I use WMP.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Not sure what causes that as GZDB doesn't log any details about what exactly it was trying to do or on which line it happened.
But your guess can be right, since it probably happened during fixed(byte* bptr = bytes) if GZDB failed to allocate the memory for reading the image.
Did it specify which image failed?

EDIT: Poll was removed. The random lump editing in the script editor stays. Not sure when I'm going to fix it though, so be ready for various bullshit with it.
Although I've fixed the main problem that it was unable to detect if the same file is being edited in another application.
Last edited by ZZYZX on Fri Jan 27, 2017 12:22 pm, edited 2 times in total.
User avatar
Da Spadger
Posts: 438
Joined: Thu Jan 05, 2006 10:12 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Da Spadger »

R2847 | f4947a2:
Added: more magic to the autoalign/select neighbours logic; These functions should not anymore wrap around to the opposite side of two-sided linedefs, allowing you to select back and front sides separately using shift+click, and reducing infinite broken autoalign loops.
I love this change.
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Nevander »

ZZYZX wrote:Did it specify which image failed?
Nope. All it told me in the error log is what I posted in bold. Does GZDB do any kind of temporary file saving when entering visual mode? It seems to have came up a couple seconds after entering visual mode and I hadn't saved manually before entering it. Hasn't happened again yet.

I feel like GZDB might have went stupid for a moment and threw some BS message. It did it one time before and claimed a single sprite in my resource WAD wasn't even a correct graphic file. Like, wtf? Haven't seen that one since either.
User avatar
Ozymandias81
Posts: 2063
Joined: Thu Jul 04, 2013 8:01 am
Graphics Processor: nVidia with Vulkan support
Location: Mount Olympus, Mars

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Ozymandias81 »

Nevander wrote:Any idea what could cause a message like this:

Unable to make file image. AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Came up randomly while I was in visual mode. Had Firefox open playing music on YouTube, which uses a lot of RAM. Did GZDB try to save the temporary map copy in memory being used by Firefox? Wild guess but it's the first time I've seen this and I don't usually listen to music in my browser while mapping, usually I use WMP.
Happens to me as well when I try to load 2 or 3 maps per session...
For example:
  • Checking stuff for Blade of Agony, then load a map... so save it and close the map.
  • Then I load another map, wait until resources are loaded and... that kind of message pop up.
I have these specs in case you wanna know.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Probably not enough memory indeed.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Apparently my autoalign fix broke autoaligning selected textures. That's known and marked for fixing.
/self-regression testing rules/

(edit: fixed)
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Partially implemented Doom64 lighting.
Relevant issue here https://github.com/jewalky/GZDoom-Build ... /issues/24

Feedback is welcome, also help with color_absolute pls.
Because I'm setting color_absolute to true, setting sector's light level to 0, and final color is still calculated using sector's light level contrarily to what this commit says.

Also, just realized that GZDB doesn't even try to display different light levels on a sprite visually.
Also, what's this? It doesn't seem to work for me at all, neither in GZDB or GZDoom. Should it?
Nevander
Posts: 2254
Joined: Mon Jan 06, 2014 11:32 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Nevander »

ZZYZX wrote:Partially implemented Doom64 lighting.

Feedback is welcome
Omg. I can't wait to see this fully fleshed out into a foolproof system. It will benefit the maps in my project like you would not believe. Keep up the good work ZZYZX.
User avatar
Nash
 
 
Posts: 17450
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Nash »

ZZYZX wrote:Partially implemented Doom64 lighting.
Relevant issue here https://github.com/jewalky/GZDoom-Build ... /issues/24

Feedback is welcome, also help with color_absolute pls.
Because I'm setting color_absolute to true, setting sector's light level to 0, and final color is still calculated using sector's light level contrarily to what this commit says.

Also, just realized that GZDB doesn't even try to display different light levels on a sprite visually.
Also, what's this? It doesn't seem to work for me at all, neither in GZDB or GZDoom. Should it?
Thank you! unfortunately I don't have any answers to this (I didn't even know what D64 lighting was supposed to be, initially)... I hope Graf Zahl will come along and answer these.

Return to “Abandoned/Dead Projects”