Generating entity definitions (fgd)

[gildedhipbone]

Sorry for the messy title but the issues are connected. Following #3 :

Yes, currently every mesh instance is set to static. Brush entities could have a property to override this inside of TrenchBroom to set this to none or dynamic.

Similarly, I suppose there could be an override per entity/layer/group for UV2 unwrapping.

Feel free to make a separate issue for that so I don't forget!

Would it be possible to create and populate the configuration files using the wonderful custom entity feature? Example: I've set up a custom door entity: entities/kinematic/doors/door_default.tscn. It has the following scene structure:

Would it be possible to:

1. Automatically add to the Trenchbroom .cfg files based on the .tscn. I.e. add entries for a SolidClass with the name "door_default"

2. Assuming there's a door_default.gd present, try to fetch the properties for the entity from what's exposed in, say, a dictionary:

3. From inside Trenchbroom, allow the user to set child node properties nodes not pre-exposed in Properties by adding them using a special key and the property path(value):

I hope this wasn't too messy. I kind of feel that every entity should be created using the custom entity system, including the default ones, to ensure a Godot-centric process. Or is this system limited in some way?

[codecat]

Automatically generating an fgd file could be an interesting feature, for sure! I think it makes sense too, considering TrenchBroom has a shortcut to reload the currently active fgd file (F6). I'll need to look a bit into what kind of info is available from Godot and what can actually be generated though. I don't like having to manually define a list of properties, I'd rather have it be done automatically (like via exported class properties).

Currently the default entities light and area aren't loaded from scenes but are created directly as nodes from code. I still have to look into the best way to handle custom brush entities though.

[gildedhipbone]

Yeah, I think fetching exported class properties makes sense! Certainly less ugly than what I was proposing.

I'm curious about how you'd fetch the exported class properties/members. By using get_property_list()? Apparently exported vars have an undocumented usage ID of 8199. I've yet to test this though.

[HeadClot]

Hey just thought I would chime in on this. I know that Qodot can generate an .FGD with entity definitions. Might be worth looking at the code for that and see how it is done. :)

[gildedhipbone]

I've been playing around with generating an fgd file using get_property_list():

1. Generate a list of entities in /entities and their properties.
2. Filter properties by usage (e.g. 7 and 8199) and a universal ignore list (not pretty).
3. Feed the list of entities and filtered properties to a fgd generator. It doesn't do anything fancy at the moment except make sure Color becomes a smart entity picker in Trenchbroom. I'd like to extend it to translate properties like bake_mode to (choices).

Obviously I'm not a programmer but in case I've stumbled upon anything useful you can check it out at: https://github.com/gildedhipbone/TBLoader_Test/tree/main/addons/tbloader/nodes

[codecat]

The link is a 404, but that looks really promising! get_property_list is a good hint to get started. Thanks for the tips 😄

[gildedhipbone]

I forgot to set it to public, natch. 😬 Fixed now.

[fire]

I'm new to tbloader, how can I help?

[codecat]

As said in the referenced issue, ultimately I would want this to tie in to some kind of "game config sync" feature.

This would be a little wizard window with some settings (if we even need additional settings? we might not!) that generates the game config and entity definitions and automatically installs them to your TrenchBroom folder.

This would also require a new global setting where the user can specify where TrenchBroom is installed on their system. Is this possible with GDExtensions? If not, I suppose we can also store this in the project settings, if GDExtensions allows that.

[fire]

Do we have a way to convert https://github.com/codecat/godot-tbloader/blob/master/tb-gameconfig/Godot.fgd from godot to a file and back?

https://github.com/codecat/godot-tbloader/blob/master/tb-gameconfig/GameConfig.cfg is json

[codecat]

I'm not sure we need to be able to parse fgd's to be honest, outputting them should be enough, unless we also want to support importing existing fgd's or basing the generated fgd on some other one. 🤔

[fire]

For now we can store it as a string. Sure.

[Frontrider]

Output is enough as Godot should be the "master" towards Trenchbroom. If you create an entity in the FGD then it will mean nothing in godot, but if you make one in godot it will work in Trenchbroom.

Please don't copy what Qodot does.

[codecat]

I think I agree. I'm not sure what Qodot does there, but if it parses an fgd I guess a big part of Qodot is to be able to load existing Quake engine maps into Godot, which has never been my goal whenever I used Qodot or when I made TBLoader.

Do you have strong feelings against how Qodot works there?

[Frontrider]

I think it's difficult to link your entity with the fgd, and the way the ui is put together is difficult to manage. It does not parse existing FGDs. Don't take it as me shitting on them, they are rewriting the whole thing from scratch, because they clearly know how bad it got.

[Frontrider]

I had an intention to experiment by reusing parts of it, but it's so undocumented and cluttered (scripts spanning hundreds of lines) that it was a dead idea.

[krazyjakee]

Before I head off to write a fgd parser, can I confirm that we want dictionary -> fgd and fgd -> dictionary (for testing purposes) capabilities?

Also, is it just a case of looping through the entities folder, yanking out the properties of each and putting them into a dictionary format ready for processing into fgd?

I feel like that would quite simply accomplish what we're trying to do.

[codecat]

Like discussed earlier, I don't think we necessarily need the ability to parse fgd's, nor do we need a super complex way to write fgd files from a dictionary object. The code for writing an fgd could be fairly straightforward, writing the entities and properties line-by-line as it iterates through all the entity scene files in the entities folder (and subfolders).

[krazyjakee]

The reason I would like a parser is purely for testing purposes so that it would be possible to test the output. Maybe overkill but might save a bug or 2.

[codecat]

Ah I see. Well for testing, we could also just compare the fgd output to a constant string and see if it matches, which would be more reliable than having a serializer and deserializer, which in themselves should then also have tests. Maybe something like this could be its own separate project though.

It might be interesting to look into CI and testing, but right now we don't have that. I'm not against tests, but that should probably be discussed in a different issue 😅

[krazyjakee]

https://github.com/krazyjakee/godot-fgd

This is working but the limitations are;

• only supports creating scripts (.gd files) entities
• limited number of data types
• no tests

[codecat]

That's really cool!

[krazyjakee]

Thanks! I'm going to finish up the remaining issues then fork tbloader and add the "Build FGD" button. Then we have our proof of concept.

Short term: Any ideas and critique are welcome.

Long term: I'm going to start building a game with it anyway so I'm sure I'll be able to keep adding to/maintaining it.

[codecat]

For what it's worth, I was considering having this implemented in C++ itself instead of GDScript (except for the UI part I guess) which would be more consistent for the TBLoader code base.

Additionally, we would also need some setting so that the user can specify the path to their TrenchBroom installation directory so that the fgd can be written directly to the correct path.

[krazyjakee]

C++ scares me and I've never touched it. No time like the present I guess.

For the latter, Trenchbroom has context of the game root and can load an additional FGD from a relative path to the game root. Also, the game dev will likely want the FGD local to their other code and in source control. While I agree the custom path option should be there for edge cases, it may not usually be in the best interest of the dev. I'm ready to be wrong but in the case of feature branches, this would be super useful.

[codecat]

Oh interesting, I didn't realize Trenchbroom had that option. In that case that would indeed be the better thing to just keep the file with the game.