For high-res texture/sprite projects, sprite-fix patches, music add-ons, music randomizers, and other graphic/sound-only projects.
Forum rules
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
I've created an issue on your github, but I'll post here just in case.
I've been using may version of your brightmaps on many mods without an issue. I today updated to latest version and in my first play I see this weird effect on a slime waterfall on map23 of Back to Saturn X E1.
Perhaps it also happens on other mods, I haven't tested yet.
Please hold back with error reports until GZD 4.2.5. It will address an issue with custom texture replacements which shouldn't use these brightmaps at all (when using the "iwad" keyword). It's not a problem with the mod itself.
As an explanation: I defined all texture brightmaps so that they wouldn't be used as soon as a mod replaces the original lump, avoiding situations where a replacement texture would be different from the original while the old brightmap would still be used. However, due to a GZD bug, the definitions don't work as intended. It was reported and fixed after the 4.2.4 release.
Also check my post from Nov 5 in this thread for comparison.
If you don't like to wait, you can try running the mod with a recent development snapshot.
Does that mean that brightmaps will finally be able to be autoloaded without fear of having them show up on textures they weren't supposed to? That always stopped me from doing so, even though I wanted to. Sorry if that question is a bit offtopic.
In theory it has always been possible to do so if affected brightmaps had the "iwad" keyword in their definitions. I don't know when this GZD feature stopped working, but it should be possible to use it again in any GZD dev build after Nov 5.
I haven't applied the iwad feature for sprites in my mod though since otherwise brightmaps for spritefixes wouldn't be possible.
NightFright wrote:In theory it has always been possible to do so if affected brightmaps had the "iwad" keyword in their definitions. I don't know when this GZD feature stopped working, but it should be possible to use it again in any GZD dev build after Nov 5.
I haven't applied the iwad feature for sprites in my mod though since otherwise brightmaps for spritefixes wouldn't be possible.
Removing all instances of "iwad" fixes everything.
Actually it doesn't, and removing iwad lines from the defs would remove one of the most prominent features of the mod. You need to use more recent GZDoom builds, it will work. Already tested and confirmed.
What do you think about splitting brightmaps in two, for sprites and textures? So that texture brightmaps can be safely autoloaded.
Or can sprite brightmaps be somehow made toggleable through options?
There are two goals remaining for this pack, but unsure if technically possible:
1) Toggle to switch between spritefixes and vanilla
2) Toggle for texture brightmaps
Right now it is not possible to dynamically reload a GLDEFS file without restarting GZDoom, at least AFAIK. If it can be changed, it'd be a nice last thing to polish this.
If it's not going to happen, I guess three packs need to be made:
1) Sprites only, vanilla
2) Sprites only, spritefix
3) Textures only
NightFright wrote:Actually it doesn't, and removing iwad lines from the defs would remove one of the most prominent features of the mod. You need to use more recent GZDoom builds, it will work. Already tested and confirmed.
It is as I thought, then. Well, in that case nothing holds me back from releasing the split versions, I guess! I took the opportunity to fix some issues with texture brightmaps while I was at it. This release should also put an end to illuminated floors and/or ceilings in dark areas (such as Kazudra posted above, even though it had nothing to do with using iwad definitions).
Changelog v1.7 (Feb 6, 2020)
[GENERAL] Split pack into three parts: bmplus_vanilla.pk3, bmplus_spritefix.pk3, bmplus_textures.pk3
[DOOM/DOOM2] Deactivated certain flat brightmaps to improve dark level areas (CEIL1_2, CEIL1_3, CEIL3_4, CEIL3_6, FLAT2, FLAT17, FLOOR1_7, TLITE6_1, TLITE6_5 and GRNLITE1)
[DOOM] Fix for texture brightmaps STEP4 and STEP9
[DOOM] Improved flat brightmap GATE4
If you want to continue with the full experience from previous single-file releases, the following setup is recommended:
- Doom/Doom2/Final Doom: bmplus_vanilla.pk3 (for spritefixes: bmplus_spritefix.pk3), bmplus_textures.pk3
- Heretic: bmplus_vanilla.pk3 (for spritefixes: bmplus_spritefix.pk3), bmplus_textures.pk3
- Hexen: bmplus_vanilla.pk3, bmplus_textures.pk3
- Strife: bmplus_vanilla.pk3
I'm confused now. bmplus_vanilla and bmplus_spritefix contain brightmaps for all sprites only, but one is for vanilla and the other one is for spritefix, right? And bmplus_textures is, well, brightmaps for textures. Is that correct?
I wonder though. If before you couldn't use iwad definitions for sprite brightmaps because they wouldn't work with spritefix, why not use it now for vanilla and just bundle sprite and texture brightmaps into one?
To summarize again:
- bm_vanilla: Sprites only, for vanilla users
- bm_spritefix: Sprites only, for spritefixed Doom or Heretic, but also vanilla Hexen+Strife
- bm_textures: Textures only, for Doom, Heretic and Hexen
If you want the exact same thing as before, choose one of the two sprite packs and load it with the textures pack. You can also use them individually, i.e. just sprites or textures only. It all works.
You can combine vanilla sprites+textures and spritefixes+textures into two new compilations, but then there would be people again who don't want texture brightmaps. Anyway, I am also using iwad parameters for vanilla, it's only missing the brightmap deviations required for spritefixes. The reason I split this was done so that people can combine the packs the way they want without having to mess with the internal definitions manually. From what I understood this was the request in general, unless I got it wrong.
Maybe I need to make three more packs, a combined one with everything like before plus the two other combinations mentioned above. Good lord. I knew this would be confusing, that's why I went for a single file solution until now. And something tells me that in the end it will be like that again. Sigh...
Last edited by NightFright on Thu Feb 06, 2020 12:32 pm, edited 1 time in total.
NightFright wrote:You can combine vanilla sprites+textures and spritefixes+textures into two new compilations, but then there would be people again who don't want texture brightmaps. Anyway, I am also using iwad parameters for vanilla, it's only missing the brightmap deviations required for spritefixes. The reason I split this was done so that people can combine the packs the way they want without having to mess with the internal definitions manually. From what I understood this was the request in general, unless I got it wrong.
I see. So sprites+textures are now 100% autoload safe? And spritefixes should be kept to be used when nothing overrides sprites?
NightFright wrote:Maybe I need to make three more packs, a combined one with everything like before plus the two other combinations mentioned above. Good lord. I knew this would be confusing, that's why I went for a single file solution until now. And something tells me that in the end it will be like that again. Sigh...
Nah, I get why it was split like that now. But maybe better names for files or some short description in the OP could help with possible future confusion.
Something like bmplus_sprites and bmplus_textures for vanilla sprites and textures, and bmplus_sprites_spfx for SPFX?
I am opposing the entire autoload idea and prefer a modular approach via launcher where you can conveniently turn mods on and off as needed. That being said, since I am using iwad parameter everywhere, which I had already done before but it didn't work due to a GZD bug, any mod loaded on top of this won't cause problems since any modified sprites simply won't use these brightmaps. If that's what you want, it's autoload ready. And you don't have to add the textures pack if you don't like it.
Anyway, I edited my post above and changed download description in OP, hopefully it's clearer now.
