ZDoom

by **Major Cooke** » Mon Oct 24, 2016 3:41 pm

Huge thanks!

by **Graf Zahl** » Mon Oct 24, 2016 3:38 pm

Just fixed for another bug report.

by **Major Cooke** » Sun Mar 13, 2016 10:37 am

Graf Zahl wrote:No, that won't help. It only adds the patches if they are either graphics or patches, depending on the keyword. I cannot remember why sprites have been excluded here so I got to do a bit of research in the changelog before adding a "Sprite" special case. Not that this breaks more important things...

I'll just wait for Graf, AFADoomer. It's for the best. According to what he said, it appears this is actually slightly broken functionality from the sounds of it, until proven otherwise if there was a reason not to add a case for sprites. Also I wouldn't want to rename all the sprites to begin with. Too many of them.

by **AFADoomer** » Sun Mar 13, 2016 10:34 am

Major Cooke wrote:Aaah. So that's what AFADoomer was referring to when he suggested replacing the Patch word with Graphic?

The definition type can remain as 'Sprite', correct?

And, this just applies to the replacing file (in this case spr2.pk3) right? Or should I be replacing Patch with Graphic in both versions?

I know that you can leave the definition in TEXTURES as a Sprite, but you'll have to replace Patch with Graphic in both spots as it stands, unless Graf changes something...

You may not actually have to rename the folders; I just re-checked my Wolf3D TC, and all of the sprites are assembled from Graphic TEXTURES entries, but are in the Sprites folders.

An example of sprites from the Wolf3D TC:

Code: Select all

Sprite POL1A0, 64, 64 {Offset 32, 64 Graphic WSPR0002, 0, 0}

Where WSPR0002.png is in the Sprites folder...

In the (optional) hi-res add-on, the overriding sprite is defined as:

Code: Select all

Sprite POL1A0, 128, 128 {XScale 2.0 YScale 2.0 Offset 64, 128 Graphic MSPR037, 0, 0}

Again with MSPR037.png in the Sprites folder.

Granted, I'm not using the same file name for the component graphics, so that might make a difference there, too (and be a possible workaround)...

by **Graf Zahl** » Sun Mar 13, 2016 10:05 am

No, that won't help. It only adds the patches if they are either graphics or patches, depending on the keyword. I cannot remember why sprites have been excluded here so I got to do a bit of research in the changelog before adding a "Sprite" special case. Not that this breaks more important things...

by **Major Cooke** » Sun Mar 13, 2016 9:55 am

Aaah. So that's what AFADoomer was referring to when he suggested replacing the Patch word with Graphic?

The definition type can remain as 'Sprite', correct?

And, this just applies to the replacing file (in this case spr2.pk3) right? Or should I be replacing Patch with Graphic in both versions?

by **Graf Zahl** » Sun Mar 13, 2016 4:34 am

Ok, here's what happens:

The texture manager goes through the loaded resource files one by one.
For each file all textures found in the common namespaces are added.
But there's one exception: It won't add a texture if it gets overridden by a later mod.
So when your first TEXTURES lump tries to parse the patch name it's simply not present.
There is a catch to deal with this case, but it won't get triggered if the patch is a sprite, only for actual patches, or if you specify 'graphic' for global graphics.

by **Major Cooke** » Sun Mar 13, 2016 12:57 am

Actually I didn't get the error after deleting the textures lump. You must've had a different one from me.

Anyway... Is there a 'proper' way for replacing the sprites that should be known for, say, better quality packs?

by **AFADoomer** » Sat Mar 12, 2016 10:44 pm

You get the same error even if you completely delete the TEXTURES lump from spr2.pk3...

It's probably some kind of namespace related conflict because of the resource loading order...

If you rename your Sprites folders to Graphics, and change your 'Patch' TEXTURES entries to 'Graphic', everything seems to work as expected, with no errors/warnings.

by **randi** » Sat Mar 12, 2016 10:02 pm

That changes nothing. I already did that when I saw it didn't match your description. Note that TEXTURES uses the same parser as everywhere else, so if C-style comments didn't work in TEXTURES, they wouldn't work in other places either.

by **Major Cooke** » Sat Mar 12, 2016 9:05 pm

Oh shit. I forgot to restore it back to the buggy behavior on TEXTURES before uploading. Fixed now, redownload spr2.pk3.

---OR---

In spr2.pk3, replace in TEXTURES:

Code: Select all

//Sprite M008B0, 129, 50
//{
//	Offset 0, 0
//	Patch M008Z0, 0, 0
//}

//Sprite M008C0, 129, 50
//{
//	Offset 0, 0
//	Patch M008Z0, 0, 0
//}

with

Code: Select all

/*
Sprite M008B0, 129, 50
{
	Offset 0, 0
	Patch M008Z0, 0, 0
}

Sprite M008C0, 129, 50
{
	Offset 0, 0
	Patch M008Z0, 0, 0
}
*/

by **randi** » Sat Mar 12, 2016 7:26 pm

Whatever the problem is, it has nothing to do with comments in TEXTURES. The warnings come from spr1.pk3, not spr2.pk3.

by **Major Cooke** » Sat Mar 12, 2016 2:24 pm

As seen here, the /* */ style comments don't work.

Load up spr1.pk3 followed by spr2.pk3. The second file has a completely commented out textures file that shouldn't even process, but it does. Just empty out the TEXTURES file inside of it and the warnings disappear.

ZDoom

TEXTURES /* */ comments not working

Post a reply

Expand view Topic review: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

Re: TEXTURES /* */ comments not working

TEXTURES /* */ comments not working