EDGE 2.1.0 Discussion [RC-1 Released on 10.3.2018]
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine are perfectly acceptable here too.
Please read the full rules for more details.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Just a quick note: That distinction between "patches" and "graphics" is not how ZDoom implements it. When this was originally written, "patches" is what gets referenced by PNAMES and "graphics" is all loose graphics lumps, including "M_*" The only place where the file format has an effect on placement is for flats because they are unmarked and unidentifiable binary data. Doom-format patches are run through an analyzer function just like all other graphics formats.
There are some priority rules but those only kick in if a single resource file defines multiple instances of a texture name.
There are some priority rules but those only kick in if a single resource file defines multiple instances of a texture name.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Hmm, now that you mention it, I might be incorrect. edge.EPK (PK3) is setup how Graf described it....so maybe I need to look at [CJs] setup..
@Ceejay, just send me your PK3 and I'll debug it.
@Ceejay, just send me your PK3 and I'll debug it.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
I don't know how to make this any more clearer...
In sprites/ I have new sprites REPLACING existing sprites, such as PISG##. It is NOT a PNG, it is a Doom graphic/sprite lump exported as is from a WAD using Slade. It is ignored and 3DGE reverts to using the stock sprite from DOOM/DOOM2.WAD instead.
The screenshot I posted used PNG images for all the menu gfx, they were placed in graphics/. Yet, most of which was ignored, and again the originals were used.
In sprites/ I have new sprites REPLACING existing sprites, such as PISG##. It is NOT a PNG, it is a Doom graphic/sprite lump exported as is from a WAD using Slade. It is ignored and 3DGE reverts to using the stock sprite from DOOM/DOOM2.WAD instead.
The screenshot I posted used PNG images for all the menu gfx, they were placed in graphics/. Yet, most of which was ignored, and again the originals were used.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
You have discovered an oversight in our PK/EPK code. If the image entry is the same as the image_data name in DDF or elsewhere, it will not reference the image with the intended format.
You actually didn't do anything wrong, but rather you were the first to discover such a thing. A workaround would be something like:
[gfx:M_DOOM]
IMAGE_DATA=LUMP:PNG:"nameofchoice";
The bug will not take effect if the image reference name stays the same, but the image data itself is renamed.
However, like stated, it is not intentional and a bug. Thank you CeeJay for your patience!!!
At first I thought it was a problem with the newer versions of libPNG, I was debugging like crazy and just happened to, out of frustration, rename the image_data itself. And like you said, it isnt just the PNG code.
You actually didn't do anything wrong, but rather you were the first to discover such a thing. A workaround would be something like:
[gfx:M_DOOM]
IMAGE_DATA=LUMP:PNG:"nameofchoice";
The bug will not take effect if the image reference name stays the same, but the image data itself is renamed.
However, like stated, it is not intentional and a bug. Thank you CeeJay for your patience!!!
At first I thought it was a problem with the newer versions of libPNG, I was debugging like crazy and just happened to, out of frustration, rename the image_data itself. And like you said, it isnt just the PNG code.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
I know, that's what I said.Coraline wrote:You have discovered an oversight in our PK/EPK code. If the image entry is the same as the image_data name in DDF or elsewhere, it will not reference the image with the intended format.
That is how I got around the issue, but that means all graphics/sprites have to be PNG images until you get this issue sorted out.Coraline wrote:You actually didn't do anything wrong, but rather you were the first to discover such a thing. A workaround would be something like:
[gfx:M_DOOM]
IMAGE_DATA=LUMP:PNG:"nameofchoice";
The bug will not take effect if the image reference name stays the same, but the image data itself is renamed.
Glad to be of help, and thank you for YOUR patience.Coraline wrote:However, like stated, it is not intentional and a bug. Thank you CeeJay for your patience!!!
At first I thought it was a problem with the newer versions of libPNG, I was debugging like crazy and just happened to, out of frustration, rename the image_data itself. And like you said, it isnt just the PNG code.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Another question related to PK3 structure...
If I have levels, they go in maps/, right.
And each and every map has to be seperated into their own individual WAD files, right.
What if I have, say over a hundred levels, already stored inside a WAD that I would like to convert to PK3 and don't feel much like spending tedious amounts of time seperating each and every map into their own unique WAD.
Is there is another way?
If I have levels, they go in maps/, right.
And each and every map has to be seperated into their own individual WAD files, right.
What if I have, say over a hundred levels, already stored inside a WAD that I would like to convert to PK3 and don't feel much like spending tedious amounts of time seperating each and every map into their own unique WAD.
Is there is another way?
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
That's a good question. I'm assuming you can just copy/paste into a new PK3, ignore directory structure, and it should work out just fine. Don't keep them in any namespace. I don't have the ability to test that, so try it out and let me know
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
I am in the process of converting my mods to a structured archive format, so far it's been far more challenging getting it to work than I'd expected.
My old Wolfenstein 3DGE mod as it turns out took me two whole days to get re-structured and working.
Now, I have this problem
EDIT: Nevermind, found the issue.
My old Wolfenstein 3DGE mod as it turns out took me two whole days to get re-structured and working.
Now, I have this problem
I've checked and re-checked, remade/copied the images in question and can't find a single thing wrong. 3DGE justs insists on having issue scanning them.WARNING: Error occurred scanning image: DOOR2_1
GETINFO [NZED12] : size 128x128
GETINFO [NZED2] : size 128x128
WARNING: Error occurred scanning image: DOOR2_4
GETINFO [NZLD1] : size 128x128
GETINFO [NZLD12] : size 128x128
GETINFO [NZLD2] : size 128x128
WARNING: Error occurred scanning image: DOOR3_4
EDIT: Nevermind, found the issue.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Is there any particular reason as to why 3DGE can't read multiple maps in a single WAD, wether in maps/, root, or elsewhere?
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Just for continuities' sake, what did it turn out to be?CeeJay wrote:.
EDIT: Nevermind, found the issue.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Well, I've tried placing the WAD (that contains a multitude of maps) in the root directory, that did not work. Tried placing it in maps/, again did not work. And while screwing around with other stuff I noticed 3DGE don't seem to read archives-within-archives. At least for what I was testing. I suppose, at this point, my only option is to painstakingly seperate each of the 111 levels into their own individual WADs.
EDIT: That is, unless there is some utility that can do the job automatically.
EDIT: That is, unless there is some utility that can do the job automatically.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
SLADE supports lua scripting. I have never used it but if you want, send me the wad and I will figure out a way to split the map lumps into individual wads with lua.
But it seems weird that 3DGE wouldn't support multiple maps in 1 wad.
But it seems weird that 3DGE wouldn't support multiple maps in 1 wad.
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Done...
Check your PM
Check your PM
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Ah, shit, I can't figure out how to automate the splitting. There's not enough documentation on SLADE's lua scripting at the moment to help me, either
- StroggVorbis
- Posts: 866
- Joined: Wed Nov 08, 2017 4:23 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Germany
Re: 3DGE 2.1.0 Test3 Released (12.13.2017)
Well, there's Graf Zahl's WadExt commandline-utility. While actually meant for ZDoom, it will extract a WAD's contents into a folder with a (mostly) .pk3 compatible directory structure. That should make things easier, even if only a little bit.CeeJay wrote:Well, I've tried placing the WAD (that contains a multitude of maps) in the root directory, that did not work. Tried placing it in maps/, again did not work. And while screwing around with other stuff I noticed 3DGE don't seem to read archives-within-archives. At least for what I was testing. I suppose, at this point, my only option is to painstakingly seperate each of the 111 levels into their own individual WADs.
EDIT: That is, unless there is some utility that can do the job automatically.