GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[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

[ZZYZX]

What's that feature and where should it load from?
I think it should load it as a lump name from resources.

[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!

[ibm5155]

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.

[ZZYZX]

What happens if you make something like AcsLib directory and add it to GZDB as excluded from testing resource?

[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.

[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.

[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]

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.

[Ozymandias81]

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.

[ZZYZX]

Probably not enough memory indeed.

[ZZYZX]

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

(edit: fixed)

[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]

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.

[Nash]

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.