func_group doesn't generate collision anymore?

[Hipshot-zz]

I have moved the map from old Qo4 to this new one. Works well, except that for some reason, some places in the level doesn't generate collision shapes.

It seems that all my old func_groups don't generate collision, is there a reason for this to happen? Before I used func_illusionary to get this behaviour.

[RhapsodyInGeek]

func_group is a complicated thing, because Trenchbroom uses func_group for a number of purposes, all of which have structural brushes merge with worldspawn. Another thing to note is that using Ctrl+G in Trenchbroom does not create the FGD SolidClass entity func_group, but rather creates a special Trenchbroom version of func_group, which does not apply the same key values as the FGD SolidClass entity func_group.

If you're using Ctrl+G to create your func_group entities, the brushes not tied to an FGD SolidClass will be merged with your worldspawn. If your worldspawn does not have collision enabled, that could be a cause for it.

If you're adding your brushes to the FGD SolidClass func_group by using the right click drop down menu or Ctrl+F, then you should check your func_group's FuncGodotFGDSolidClass resource and see if it has collision enabled.

[Hipshot-zz]

All that func_group wording in your text got me a bit confused. But let me paste a map for you and explain my results here, see if that's what you meant, this is the map:
https://pastebin.com/YbrPRfRv

So, I have a regular func_group there, made with "right click -> create brush entity -> func -> group", that one is called "// entity 1", that's the one that don't get any collision generated, so I fall through it.

Then I have the one where I just did ctrl-g as you said, and sure, it made another func_group, but with the added _tb tags in the file, then I named this apple. That one has collision and I walk walk over it.

Now, my issue here is that if the ctrl-g one that TB creates works... how would all this work if I use another editor, like radiant or jack or hammer for example? They don't create func_groups like TB does ofc... should I just skip the func_groups all together?

I should say that I'm doing this editing pure, I don't want to add anything to TB or whatever other editor I use, I want to have a as clean map format as possible. Also, this worked well in Qodot before.

[RhapsodyInGeek]

So the Ctrl+G func_group is being merged into worldspawn, and your worldspawn is set to collide, while your "entity 1" func_group is not set to collide.

It likely worked in Qodot because we renamed the example FGD entities to have the func_ prefixes, and func_group was included with them.

If you're using the default FGD resources that come with func_godot while using TrenchBroom's Generic Game, then that's likely your issue as func_group is not defined in the default FGD resources. Using the default FGD resources does require you to create a game configuration for your chosen map editor.

If you want to use the map editor "pure" (there's really no such thing), then you'll need to define your own FGD resources in Godot to match with TrenchBroom's Generic Game FGD.

Honestly though, I'd just recommend following the setup guide in the manual and create a game configuration for TrenchBroom, especially if you're not sure how everything works.

[Hipshot-zz]

I see, well, that explains it. I will just avoid the regular func_groups then, I really don't need it if I can use the tb ones just for TB. I'm trying to avoid to do any sort of special settings inside TB (or any .map editor really) if possible and just make the layout and such in it, to really keep this agnostic, because I will have people who uses various editors in the end.

Thanks for your replies, In the next thread I will nag about Net Radiant Custom =)

[RhapsodyInGeek]

For smaller maps or making map modules that get placed within Godot, that's probably fine. If you're planning to make your map as one large worldspawn (this is what TB groups do btw, they merge into worldspawn not separately, and this won't work in other map editors because func_godot keys in on the "_tb_group" and "_tb_id" key value pairs) then you should reconsider, as splitting up your map geometry is extremely important for optimization.

In any case, good luck!

[Hipshot-zz]

Yea, I know, I need it for the culling and whatnot, it's a large level that will be much larger probably, I will find a solution that works, in the end I might have to adapt hehe =)

Edit: For anyone else that are just looking for the ent names, these are the ones you require, this is straight from the fgd:

@solidClass color(204 204 204) = worldspawn : "Default static world geometry. Builds a StaticBody3D with a single MeshInstance3D and a single convex CollisionShape3D shape. Also builds Occluder3D to aid in render culling of other VisualInstance3D nodes." []

@solidClass color(204 204 204) base(Phong) = func_geo : "Static collidable geometry. Builds a StaticBody3D with a MeshInstance3D, a single concave CollisionShape3D, and an OccluderInstance3D." []

@solidClass color(204 204 204) base(Phong) = func_detail : "Static collidable geometry. Builds a StaticBody3D with a MeshInstance3D and a single concave CollisionShape3D. Does not occlude other VisualInstance3D nodes." []

@solidClass color(204 204 204) base(Phong) = func_detail_illusionary : "Static geometry with no collision. Builds a Node3D with a MeshInstance3D. Does not occlude other VisualInstance3D nodes." []

@solidClass color(204 204 204) base(Phong) = func_illusionary : "Static geometry with no collision. Builds a Node3D with a MeshInstance3D and an Occluder3D to aid in render culling of other VisualInstance3D nodes." []