[SOLVED]Brightmaps GLDEF help??

[phantombeta]

Looks like another case of the "top level folder eradicator" not accounting for something. It has the same cause as this bug, meaning an exception for the "brightmaps" folder needs to be added.

[Dan_The_Noob]

Hmm... GZDoom 4.7.x seems to fail to detect the brightmaps if they're placed in brightmaps/auto, which is something 4.6.1 had no trouble with, but it can detect them if they're placed in materials/brightmaps/auto (<--- this is a new auto path that was introduced at a later point).

thanks, this fixed it. wiki might need update i guess.

[Enjay]

So, is this still a bug in 4.7.1 (and more importantly 4.8 pre) or is using the materials folder the fix?

i.e. is GZDoom meant to read "brightmaps/auto" or not?

[phantombeta]

So, is this still a bug in 4.7.1 (and more importantly 4.8 pre) or is using the materials folder the fix?

i.e. is GZDoom meant to read "brightmaps/auto" or not?

It is a bug in 4.7.x:

Looks like another case of the "top level folder eradicator" not accounting for something. It has the same cause as this bug, meaning an exception for the "brightmaps" folder needs to be added.

If you add another folder or a file in the root of the PK3, it'll load with "brightmaps/auto".

[Enjay]

Is the bug officially known about for 4.7.x (i.e. has it been reported in the bugs forum) because the thread you linked to indicated that it was fixed when 4.6.0 was current?

[phantombeta]

That report is for the "filter" folder. GZDoom checks for specific folder names that should be considered as exceptions to the single-folder-in-root removal system. The "brightmaps" folder needs to be added to this array; As you can see, "materials" is already there, but not "brightmaps".

[Enjay]

OK, so that will be an easy enough fix - provided it has been reported. After a quick search, I can't find a bug report for it though. Is the dev team aware of the need to add the folder to the array? If not, it won't happen.