_decal is not saved properly

[SomaZ]

Using GtkRadiant 1.6.5 - Aug 20 2017, if you want to make use of the "_decal" entity, you will always get some kind of message like "Decal entity without any patch meshes, ignoring.", in the process of compiling. This is true because this GtkRadiant version simply trimms all the faces added to the _decal entity while saving the map file. If I start comiling with a batch file and my manually added patch faces, it compiles fine. Any chance of getting this fixed?

[TTimo]

Hello, can you provide a test map?

[SomaZ]

Top is compiled with GtkRadiant, the other one using batch files. Game is Jedi Knight: Jedi Academy Singleplayer (with another renderer, but I checked vanilla too).

decal_test_01.zip

[Pan7]

Do you compile with -patchmeta?

[Aciz]

Does q3map2 do something different with _decal entities with JK? Because this test map works fine with the q3map2 shipped with that version of radiant (both 32-bit and 64-bit) when compiling for W:ET. Also, -patchmeta wasn't required.

[SomaZ]

Both were compiled with -patchmeta. Only difference is that the version at the bottom is compiled via batch files instead out of GtkRadiant. GtkRadiant saves the map before compiling afaik. Problem is that it deletes patch and brush definitions from the _decal entity in the map file. The _decal entity works kind of like a func_group with the adddition of a target key.

My current workflow is that I place my decals in GtkRadiant as func_groups, add the target and another key that is simply ignored. Something like "thisisadecalent" "0". When I'm done working on the map I manually search the map file for the "thisisadecalent" words and replace the entity name "func_group" with "_decal". Then you can compile this fine with q3map2, but it's super annoying to make this extra round of fixing this.

[Pan7]

I got this -patchmeta bug too https://github.com/TTimo/GtkRadiant/issues/113 It seems to filter nonvisible/trans patches.

[SomaZ]

The _decal problem is not related to q3map2. So it can't be "the -patchmeta bug". It's a problem with GtkRadiant and it's .map saving. You can try it yourself with the map file I provided. Simply open it in GtkRadiant and save it. Open the map file with a texteditor and look for the patch or brush definitions in the "_decal" entity. They are simply gone.

Edit: Oh maybe I misinterpreted what you tried to say. Nvm, then.

[Pan7]

No problems when using the q3a game with the decal_test_01 map.

[SomaZ]

Hm, maybe something jka specific then? Game is set to "Jedi Academy", mapping mode to "Single Player mapping mode". Anything else I can provide to track this down?

[Pan7]

The sp_entities.def and mp_entities.def file of JA don't have a _decal entity definition.

[SomaZ]

Adding it to the sp_entities.def works. Ty, this was driving me nuts. This can be closed then. I guess the gamepack stuff is handled elsewhere?

[Mateos81]

@mrwonko and Obsidian are the persons in charge according to GtkRadiant website: http://icculus.org/gtkradiant/developers.html#gamepacks

[0bsidian]

Updated. We can close this now.

[SomaZ]

Thanks!

[Garux]

allowing, but then deleting undefined entities is quite frustrating itself tho

[ensiform]

Presumably because the only way it knows if an entity is brush based is if it has a definition though. So it can't know if it doesn't exist.

[Garux]

works well in 1.5; must be sorcery >_<

[ensiform]

Again, 1.5 is "special" and can't be compared against lol.

[Garux]

special in which way? can create maps there efficiently, can inherit its code logic aswell

[0bsidian]

As an end user, most people will just use whatever entities are defined in the entities.def, or be technical enough to edit it themselves.

[ensiform]

It's special as in it was rewritten and not well liked by the maintainers. The behavior I described is how radiant has functioned since q3R at least. <= 1.4, >= 1.6

[Garux]

I bet it's still q3R code there, and it wasn't evaluated since then I know quite a few users, who simply change classname to get undefined entities instead of messing with definig them canonically, since editor is not bitching about those Other scenario: someMod/GameUser: fix my .map please 1.4: fix, save = halve the group entities are empty 1.5: job done One more scenario: porting someGameName map to yourGameName

As for maintainers, there are >10 of game specific forks of 1.5 and none of 1.4; That's what maintainers normally choose Presumably GTKRadiant users just got to suffer

[ensiform]

GTKRadiant 1.6 is based on 1.4 and 1.4 (and older)'s behavior is that of brush entities will not function properly if renamed to an unknown entity due to the structures saved internally in code for how it determines brush vs point. Unknown point entities work just fine.

If this miraculously works in 1.5 great, but the code doesn't translate backwards to 1.6 at all so it'll be a nightmare to fix. Bit-rot is very strong in this code-base 🤣