It's a refactoring that came along some VFS work done for game features. It would have been possible to add more convolution to not factorize that code but that did not seem a good idea. Having a dedicated VFS code for notex only is as absurd as having some texwindow code only for WAD, and it looks like you're not happy yourself with that dedicated WAD texwindow code. So, you may be happy, VFS factorization is already done, no dedicated VFS for notex anymore!

Well, at least introduced notex mess has nothing to do with game features.

Thomas Debesse (acd4026b) at 25 May 10:06

q3map2 * fix: do not affect styled lightmaps by floodlight

Thomas Debesse (3d71aa7b) at 25 May 08:55

gamepacks: add Alien Arena (GPL)

• load .pak and .wad files, fix #139
• add .pakdir support for free (but that's not yet useful before map compilers handle it)
• fix loading PNG fallbacks (notex, etc.) when the game does not support PNG, fix #141
• do not load engine path twice when home path is engine path (happens when the game does not have home path)
• properly list wads as texture directories, with working tree, per wad texture listing and wad name in texture window title

Reported by jar-el and PeterInRealLife in xonotic's mapping channel.

Initial report was: if the mapper does not select a texture before creating a brush, netradiant would crash:

♦

This comes from the fact the game does not provide textures/radiant/notex and for some reason the one shipped by netradianbt is not loaded, despite the vfs is loaded.

vfs directory: /home/illwieckz/dev/netradiant/install/linux-amd64/base/
vfs directory: /home/illwieckz/Jeux/PC/alienarena/data1/
vfs directory: /home/illwieckz/Jeux/PC/alienarena/data1/
filesystem initialised
Texture load failed: "textures/radiant/notex"

It looks a bit like to #139.

Reported by Lava Croft on Quetoo channel.

It still doesn't read the wads from my quake/id1/ folder like before
Normally you set your engine path and radiant will read the wads you have stored in the id1 folder
speaking for q1 specifically, of course
yeah, it dont output anything useful in the console either
ah, it also dont seem to load the standard blue blocky notex placeholder
Texture load failed: "textures/radiant/notex"

vfs directory: E:/dev/netradiant_1.5.0-20200419-illwieckz-windows-amd64/base/
vfs directory: E:/Quake - FTEQW/id1/
vfs directory: E:/Quake - FTEQW/id1/
filesystem initialised

That may be an issue with the VFS.

Reported by Lava Croft on Quetoo channel.

It still doesn't read the wads from my quake/id1/ folder like before
Normally you set your engine path and radiant will read the wads you have stored in the id1 folder
speaking for q1 specifically, of course
yeah, it dont output anything useful in the console either
ah, it also dont seem to load the standard blue blocky notex placeholder
Texture load failed: "textures/radiant/notex"

vfs directory: E:/dev/netradiant_1.5.0-20200419-illwieckz-windows-amd64/base/
vfs directory: E:/Quake - FTEQW/id1/
vfs directory: E:/Quake - FTEQW/id1/
filesystem initialised

That may be an issue with the VFS.

Thomas Debesse (9c6a79a9) at 25 May 08:54

Merge branch 'vfs' into 'master'

... and 7 more commits

Better implementations of notex fix and wads loading are undoing commits, which introduced these problems.

Those commits were made to support more game features. The only way to go is to fixes potential regressions or rewrite it a better way. Remember what I said when I said I don't want people having to chose between features and support for their game.

Case sensitivity fix is ok, i'v been noticing this sort of problem in numerous spots besides this.

OK.

As for only show per-wad textures, while this behavior is wanted, implementation is maximally rusty. I prefer having none, than one, done this way, although wads handling in radiant is way different to q1/hl tools anyway.

To be honest I would prefer to not have those ugly “if wads” tests everywhere. But as you said, the behavior is wanted, so I'm not looking for contributions to delete it but I'm looking for contributions to make it better.

So there is no suggestion for a better implementation. Since the features are wanted and those implementations are good enough, they will make their way in to master.

Don't hesitate to come back if you have a better implementation for those features, or at least if you find an issue or a regression related to those implementations. Users will appreciate it.

Better implementations of notex fix and wads loading are undoing commits, which introduced these problems.
Case sensitivity fix is ok, i'v been noticing this sort of problem in numerous spots besides this.
As for only show per-wad textures, while this behavior is wanted, implementation is maximally rusty. I prefer having none, than one, done this way, although wads handling in radiant is way different to q1/hl tools anyway.

Well, seems I not tested these changes well. Closing for now, it's not ready for merge.

C++11 provides default copy assignment operators, so manual implementations of operator= now is deprecated and unnecessary (en.cppreference.com/w/cpp/language/copy_assignment).

@winterheart do you have any idea why those little changes completely break NetRadiant?

There was some commented-out broken code to only display the filename of the wad like usual texture directories. I deleted it and entirely re-implemented it properly. Also, it's better since the tree was still done on _ detection.

I also made sure clicking a wad only show textures for the given wad (like usual texture directories), and that wad name is displayed in texture window title:

♦

@Garux, this fixes notex loading when it's missing (like Quake1), and it fixes .WAD listing in texture browser on Linux (case sensitivity issue). See #139 (closed) and #141 (closed). If you have ideas for better implementations please share your thoughts, let's make NetRadiant great again. 🙂

Note that in the end I would like to see all editorImages to be loaded with all supported image plugins whatever the game supports them or not (they are meant to not be displayed by the game after all, and are usually alternatives for weird game-specific formats), same for the XYWindow background (see #142), but I haven't yet found an easy way to keep that information all the way down to QERApp_LoadImage. At least the current implementation prevents some crashes, which is good enough.

The texture browser now tests .wad file extension case-insensitively on all systems:

♦

Lava Croft linked me to QUAKE101.WAD. I'm currently facing case-sensitivity issue: the console saids the wad is loaded but in fact the texture browser displays nothing. But when I rename the wad as quake101.wad, the magic happens:

♦

NetRadiant now seems to load the .pak and .wad files:

vfs directory: /home/illwieckz/Jeux/PC/quake/id1/
pak file: /home/illwieckz/Jeux/PC/quake/id1/PAK1.PAK
pak file: /home/illwieckz/Jeux/PC/quake/id1/PAK0.PAK
pak file: /home/illwieckz/Jeux/PC/quake/id1/gfx.wad
filesystem initialised

I also fixed the bug that made the engine path being loaded twice, and the bug that made the fallback textures (notex, etc.) not being loaded. See !166 (merged).

By the way, I'm yet to see any Quake textures in texture browser. I know nothing about .pak and .wad files, so I don't know how to debug more.

At least, when show_wads is enabled in q1.game file (default behaviour), the texture browser list the wad. But I don't get more.

Note: the gfx.wad I used to test things is one I extracted from pak0.pak for quick testing purpose only, I'm not meaning it's the way to do it. I just needed a .wad file.

Note: NetRadiant can also load .pakdir (.pak can be extracted using tools like unpak from quake-cli-tools, or UnPAK), or pakextract from Yamagi Quake II (I only tested the first one). By the way, this feature is useless until map compilers support the feature. This is still useful to debug stuff.

• load .pak and .wad files, fix #139
• add .pakdir support for free (but that's not yet useful before map compilers handle it)
• fix loading PNG fallbacks (notex, etc.) when the game does not support PNG, fix #141
• do not load engine path twice when home path is engine path (happens when the game does not have home path)
• properly list wads as texture directories, with working tree, per wad texture listing and wad name in texture window title

The XYWindow background image is loaded using QERApp_LoadImage which loads file from the VFS, ignoring all the formats that are not explicitly listed in .game file.

Because of this:

1. a PNG XYWindow image can't be loaded if the game only supports TGA (similar to #141).
2. a PNG XYWindow image can't be loaded from arbitrary directories like the user home directory.

In both case, I don't think so much restrictions makes sense. There can be legit uses case where the XYWindow background image is part of the mapper's workflow but does not have to be included in to-be-released game assets.

When I merge, compile and run this I get weird bugs in absolutely unrelated place. For example at startup NetRadiant loses the engine path for the current selected game, then on next startup it starts with another game… etc.

Or worst, starts a game but prefill the engine path from another game. For example start Heretic2 with Smokin' Guns engine path.

And segfaults when quitting.

Default textures/radiant/notex is not loaded because the provided fallback is in PNG format while AlienArena game pack only enables TGA and JPG image plugins.

C++11 provides default copy assignment operators, so manual implementations of operator= now is deprecated and unnecessary (en.cppreference.com/w/cpp/language/copy_assignment).

Because textures/radiant/notex is not loaded, creating a brush before selecting a texture may crash netradiant, see similar issue with PAK archives: #141.

While GtkRadiant provides vfspak, vfswad and vfspk3 plugins, NetRadiant only provides vfspk3 but also provides archivezip, archivepak, and archivewad. Maybe the vfs code was modified to be unique whatever the package format, but there is some bugs when the VFS is not pk3-based, because it's less tested, and maybe wads are not loaded at all.

While GtkRadiant provides vfspak, vfswad and vfspk3 plugins, NetRadiant only provides vfspk3 but also provides archivezip, archivepak, and archivewad. Maybe the vfs code was modified to be unique whatever the package format, but there is some bugs when the VFS is not pk3-based, because it's less tested.

Unlike Quake1 (see #139) there is no issue to load Alien Arena textures because they are distributed unpacked.

Reported by jar-el and PeterInRealLife in xonotic's mapping channel.

Initial report was: if the mapper does not select a texture before creating a brush, netradiant would crash:

♦

This comes from the fact the game does not provide textures/radiant/notex and for some reason the one shipped by netradianbt is not loaded, despite the vfs is loaded.

vfs directory: /home/illwieckz/dev/netradiant/install/linux-amd64/base/
vfs directory: /home/illwieckz/Jeux/PC/alienarena/data1/
vfs directory: /home/illwieckz/Jeux/PC/alienarena/data1/
filesystem initialised
Texture load failed: "textures/radiant/notex"

It looks a bit like to #139.

Thank you for the patches. I applied the same fixes on daemonmap submodule.

For some reason GitLab did not detect the merge. So I'm closing it (it is merged).

Libraries under libs should be forced STATIC since there circular dependencies and implicit linking with external libraries. Otherwise compilation will fails with underlinking errors.

Thomas Debesse (ec255b56) at 21 May 09:26

Fixing compilation with -DBUILD_SHARED_LIBS=ON

... and 1 more commit

Libraries under libs should be forced STATIC since there circular dependencies and implicit linking with external libraries. Otherwise compilation will fails with underlinking errors.

Thomas Debesse (5980dc6b) at 17 May 15:53

Thomas Debesse (458a91b4) at 17 May 15:53

Merge branch 'illwieckz/gcc10' into 'master'

... and 9 more commits

I compiled NetRadiant as explained in the README:

cmake -G "Unix Makefiles" -S. -Bbuild -DCMAKE_BUILD_TYPE=Debug

cmake --build build -- -j$(nproc)

Here is the output (things start to get weird after 52% progress): paste.debian.net/hidden/77e43a05/

It is known to build on:

• Linux Ubuntu 20.04 with GCC 10.0.1
• Linux Ubuntu 20.04 with GCC 9.3.0
• Linux Ubuntu 18.04.1 with GCC 7.5.0
• FreeBSD 12 with Clang 6.0.1
• Windows 10.0.18362 with GCC 9.2.0 (MSYS2/Mingw64)

I haven't tested the build themselves.

@SpiKe can you build this and compile a map?

Don't forget to update submodules after having checked out the branch:

git fetch
git checkout 'illwieckz/gcc10'
git submodule update --init --recursive

I also built some Unvanquished maps without seeing any issue.

Thomas Debesse (5980dc6b) at 17 May 15:50

daemonmap: update submodule