You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sure there are lots of q2 texture collections in subdirectories, but it's not a requirement and no other map editor ignores textures not in a subdirectory that I know of. It isn't a bug, but a restriction TrenchBoom places on quake 2 texture locations from the looks of it. Textures inside /baseq2/textures/ or /q2mod/textures/ are ignored if not in a subfolder (/textures/somename/) and will never be available under Texture Collections to be enabled.
It's been like this a while since before #1808 was made, but never noticed it outright ignored quake2 wal files in /textures until recently after suggesting TB to someone wanting to map for Quake 2.
I have no idea how it affects compilers today, but I have over 2,000 lose wal files in just the /baseq2/textures/ directory from custom map downloads collected from the year 2000 onwards. It's only an issue if someone wants to use those textures to map it forces them to makeup subdirectories for them to go into or if working on an older map that uses those textures as in the case with a few .map files I opened from circa 2001 recently. In that case they can open the map in a text editor and search & replace the texture location/names before working with them it in TB.
FYI Quake 2's very own pak0.pak did come with one texture, REGION.wal outside of subdirectories inside /textures.
You can leave it as it is in TB it wouldn't affect many I would guess, just wanted you to know it didn't seem like normal behaviour compared to netradiant, jack or even quark. Jack and Quark just ask you to specify your texture directories and pak files. Radiant/Netradiant has another spin on it out of the box it doesn't show wal files that are lose in /textures dir, but as soon as a map is loaded that uses them they appear in the texture browser, rendered in the 3d view port, and are available to use.
Thanks!!
The text was updated successfully, but these errors were encountered:
TrenchBroom V2.1.0-RC3 on Linux and Windows 10
Expected Behavior
Sure there are lots of q2 texture collections in subdirectories, but it's not a requirement and no other map editor ignores textures not in a subdirectory that I know of. It isn't a bug, but a restriction TrenchBoom places on quake 2 texture locations from the looks of it. Textures inside /baseq2/textures/ or /q2mod/textures/ are ignored if not in a subfolder (/textures/somename/) and will never be available under Texture Collections to be enabled.
It's been like this a while since before #1808 was made, but never noticed it outright ignored quake2 wal files in /textures until recently after suggesting TB to someone wanting to map for Quake 2.
I have no idea how it affects compilers today, but I have over 2,000 lose wal files in just the /baseq2/textures/ directory from custom map downloads collected from the year 2000 onwards. It's only an issue if someone wants to use those textures to map it forces them to makeup subdirectories for them to go into or if working on an older map that uses those textures as in the case with a few .map files I opened from circa 2001 recently. In that case they can open the map in a text editor and search & replace the texture location/names before working with them it in TB.
FYI Quake 2's very own pak0.pak did come with one texture, REGION.wal outside of subdirectories inside /textures.
You can leave it as it is in TB it wouldn't affect many I would guess, just wanted you to know it didn't seem like normal behaviour compared to netradiant, jack or even quark. Jack and Quark just ask you to specify your texture directories and pak files. Radiant/Netradiant has another spin on it out of the box it doesn't show wal files that are lose in /textures dir, but as soon as a map is loaded that uses them they appear in the texture browser, rendered in the 3d view port, and are available to use.
Thanks!!
The text was updated successfully, but these errors were encountered: