Features of the Future

[RhapsodyInGeek]

So FuncGodot is already capable of an incredible amount between the brush generation and FGD systems it employs. That said, there are a few things that we'd like to see as the plugin continues to mature.

Features I'd Like to See

Proper Phong Shading

One of the features in FuncGodot is using the _phong and _phong_angle key value pairs to modify generated meshes vertex normals, to allow for smoother shading on brush entities. Currently the implementation only does this on a per brush basis, when it should be done on a per mesh basis. This issue was around in Qodot and has been carried over to FuncGodot. Hopefully we can get this sorted out in the near future.

Half-Life WAD Support

Currently only Quake 1 WAD files are supported. It probably wouldn't be too too much trouble to add in considerations for Half-Life's WAD format, but right now they can't be used. Also, I think the Quake 2 WAD file might also not have support? I think it'd be worth it for a lot of folks if we added support for them.
Half-Life WAD3 is now supported!

Quake 3 Patch Support

NetRadiant Custom is supported in FuncGodot. I don't personally use them, but it'd be cool to get patch support in for Q3 engine mappers.

ENT File Export Support

NetRadiant Custom thankfully supports FGDs, but I'm not sure that all of the Radiant forks do. It's a bit tricky to support since FuncGodot is pretty heavily geared towards the FGD format, but it might be worth it for the large Radiant audience.

More Map Editor Config Support

Speaking of the Radiant family of editors, so far we've got only one officially supported. It'd be cool to get FuncGodot to be even more editor agnostic. Official Support would be in the same way as TrenchBroom and NetRadiant Custom are currently supported: custom resources that can output game configuration files and help tailor the editor towards your Godot game.

Features You'd Like to See

As far as feature requests go, it's important to remember that FuncGodot is not meant to create game logic for you. It's design goal is to generate your maps, place your entities, apply their properties, and orient them properly in your game world. FuncGodot places your doors that you define, but it doesn't create the game logic for your doors.

With that in mind, I'm curious to know what sorts of features the community is interested in seeing that currently can't be done by the plugin?

[Calinou]

Also, I think the Quake 2 WAD file might also not have support?

Quake 2 uses the WAL texture format (as individual files for each texture) as opposed to WAD files. It should be feasible to develop a loader in GDScript.

[sinewavey]

As an aside: Q3 mappers themselves tend to avoid patches, but it was typically for limitations in idTech engines that may not be present today in Godot!

I'll be taking a look (eventually) there as well, if nobody else does first.

[Hipshot-zz]

Could be like this: You can specify the "converted subdiviosns per "patch length"" or something like that, then another setting for how tesselated the collision mesh should be per "subdivision" or somehting. That way you could have an advanced looking mesh but with a simple collision shape.

Then ofc you specify this in the build settings, I'm guessing, so you get it consistent per built level, or maybe add a setting to a func_patch group or so maybe, but that seems annoying to do, but I assume you should group the patches anyway, to make them weld all vertices?

I would love to test this as soon as possible. I have made a lot of q3 levels and are currently doing a new one as we speak so =)

[sinewavey]

That's almost exactly how I've been planning it out (subdivisions for collision, and subdivisions for visual meshes)

At first it would make sense to do it on a per map basis but then offer entity properties to override map defaults, or let the mappers decide.

[Calinou]

In general, large curves (in world units) should have more subdivisions than small curves. I believe this is how id Tech 3's r_subdivisions cvar works already (however, with that cvar, lower values are more detailed – I always play with 1 personally).

[sinewavey]

What's interesting to me is that the r_subdiv setting is something done in-game though requiring a vid restart.

Definitely, these would be be in world resolution, as opposed to subdivisions per each patch's size (I may not be wording this correctly but I agree and understand what you're saying here- thanks for the input)

I'm imagining this setting should stand in for that and perhaps be offered to end the end hsers of a map post build to allow changing LOD in this way.

[RhapsodyInGeek]

Perhaps what would be best is not only a pair of mesh and collision subdivision variables in FuncGodotMapSettings and also dedicated _patch_mesh_subdiv and _patch_collision_subdiv key value pairs that the build process can override with, like how it treats _phong and _phong_angle in GeoGenerator. That way it's consistent, accessible, and can be defined on a per entity instance basis rather than a per class basis. I imagine those KVPs would unlikely to conflict with user defined ones.

[mode777]

I‘ve only worked with func_godot for alittle over a week but here are some thing from my personal whishlist

• If possible adapt the project structure to male it easy to integrate as a git submodule, meaning the addons/func_godot should be the top-level
• Add some extension points for custom texture loading. I‘m doing a lot if runtime loading and while I can load a map at runtime, I cannot load textures. I managed to work around that by subclassing FuncGodotTextureLoader but there is some code replication needed.

[RhapsodyInGeek]

Add some extension points for custom texture loading. I‘m doing a lot if runtime loading and while I can load a map at runtime, I cannot load textures. I managed to work around that by subclassing FuncGodotTextureLoader but there is some code replication needed.

Not sure exactly what you're asking for. Are you trying to build maps at runtime and they're not being textured? Because if that's the case that sounds like a bug. Could you elaborate more on what you're trying to do?

[mode777]

I‘m trying to load maps and textures that are outside of the godot project at runtime (runtime texture import). This is for both concenience and mod support.

[RhapsodyInGeek]

Does runtime building work when the textures are within the project folder? FuncGodotMap nodes utilize the FuncGodotMapSettings, which tells the map where to find the textures. You might be running into a case where the map settings are searching the in the folder specified by the base_texture_dir property. If you're trying to find textures outside of that folder, it's expected that you'll have problems.

I've had other users experiment with runtime building and they found that you could add loose textures into an exported project's folder within the same structure (i.e: if map settings is set to res://textures/ then mygame/textures/ will work).

You could try experimenting with programmatically creating a FuncGodotMapSettings on runtime build that sets the base_texture_dir to whatever directory you're trying to search for them in. That would have the adverse effect of not searching the game project's texture folders, but at that point I would just recommend you instruct your modders that the custom textures need to be copied to the game's installation folder rather than try to make it work with external folders.

[mode777]

Yes thats all true but func_godot is still using „load“ to get textures which requires them to be imported into the engine offline first. I want to load textures after the game has been exported.

[sinewavey]

I don't see that happening in my setup (to clarify, confirming problem)

Test was twofold:

1. export build from Godot to releases folder; copy /sdk/ folder from project to release directory to match .../sdk/textures/

2. create a brand new texture after export was finished; no way base game could have ever known about it:
   sf/sdk/common/acid-alt.png

3. re-point NRC to export build gamepath instead of Godot project folder:
   .../lux_systems/dev/sf/ to .../lux_systems/release/sf. New texture shows up as expected in NRC.

4. create a new map saved in the new export, and load at runtime!

5. Texture appears in-game falling back on fgd default.

6. game closed; removed and renamed an existing working texture + files:

origin.png -> origin2.png; deletion of origin.import and origin.tres

7. textures appeared in-game with default material as well

Happy to upload MRP later upon request

[Hipshot-zz]

Have you guys ever thought about making the misc_model function "usable" without us having to code it ourselves someway? This could be very usable to combine models and brush based meshes via the compile. Right now I need to attach (see: manually move or set transforms to align) my map models myself, for small props like a table or vase I don't mind at all, but for larger map pieces which are suppose to emulate and blend in with geometry it would be nice.

Without really knowing how advanced it would be, to me it seems that the plugin should just read the path from the misc_model and place it inside godot somewhere inside the node?

This is a basic misc_model

// entity 75
{
"classname" "misc_model"
"model" "models/hipshot_m8/jumpplat.ase"
"origin" "-560 -1184 440"
}

There's a lot of features attached to this, but the only ones func_godot would need to consider itself with would be angles and scale, all other settings should already be taken care of by godots importer.

There's two settings of scale and angle: "angle N & angles N N N" and then "modelscale N & modelscale_vec N N N", the basic one could be ignored really, just read the vec3 one.

[RhapsodyInGeek]

This is one of those things that's outside the scope of func_godot, especially since there are plenty of ways to implement a misc_model or prop_dynamic or a prop_multi_mesh or whatnot that may be very game specific.

Default entities that come with the plugin are unlikely to have any scripts attached to them, as the intent of the plugin is building geometry, placing entities, and providing key value pairs, but not deciding how those entities behave once they've been generated. We also don't want any complex entities packaged with it; the idea is that if all you want to do is build geometry, collision, and occlusion in your map editor, the default FGD will let you do that; if you want to do more, you have to build the logic yourself. The intent is to provide as slim a package as possible, and to make sure we don't dictate how you design your game as much as possible.

[Hipshot-zz]

I see, well, that makes sense.

[Pspritechologist]

I was thinking about how the plugin worked, and was just wondering if the concept of converting it to generate Scenes upon import was ever considered. It seems like a more 'Godot' style way to do it, and would fit more seamlessly into some workflows.
You would add a .map file to your project, Godot would import the file as it does, but at this stage it would then perform the usual FuncGodot build logic, allowing the resulting Scene to be accessed by simply using the .map file as a Resource. This would align it 1:1 to how using .blend files works when importing with Blender.

This would solve a number of minor issues with the plugin- Maps would be updated automatically upon changes occurring to the file and would do so project-wide, you would no longer have duplicated data from reuse of maps since they'd point back to the same Scene, Scenes could be instantiated, reused, and manipulated without worry of a rebuild messing it up since Godot has a whole system in place for parenting Scenes, and finally you could load .map files in just like any other Resource at run time.
Most of these issues are small, as I said, and don't harshly limit functionality, but overall I feel that all of them would make the plugin seem far more refined and generally better integrated. I'd have to look at the specifics of how the build process goes more closely, but I don't think the code would need to be fundamentally reworked very much- as I understand it, generating a Scene file upon importing should be about the same as working within an active Scene's Tree. It may become more awkward to pass certain settings- such as map data, or bool toggles, but I think most of these could be repurposed as either import settings, or by making better use of ProjectSettings. In particular, I think better use of ProjectSettings could reduce the amount of strange Resources only one instance of is ever kept used for configuring.

[Pspritechologist]

This would of course be the kind of thing that would require a full version switch, since even if it ended up being quite easy to convert the logic, it would fully break compatibility with current set ups.

I'd also like to just take a second to gush about how cool this plugin is. As someone who's made a few maps by hand in Godot, that quote I remember about it really not being a map editor rings true. TrenchBroom has been lovely to learn and, as my first ever map editor, I now understand why people don't do it in Blender. Bringing that workflow into Godot projects opens so many possibilities, and as I haven't seen any other plugin or addon serve quite the same purpose, I consider this one very important.

[sinewavey]

I think it might be wise to have said scene file path an option of the map, and when building, if the scene is not set or does not exist, open a file dialog much like light map GI does to save the new one. If the scene path is provided via code but the file is missing, bypass the UI and just save.

There's some interesting options with saving signal connections, too.

[sinewavey]

Yeah, GitHub and my phone and my hands don't mix - I meant to reply to you with this comment.

[Pspritechologist]

So, you're suggesting the normal build process, but it saves the results to a Scene and places that Scene beneath the Node? That seems a little counter intuitive. The system I'm suggesting would simply import the map automatically, and it would be instantly available as a Scene. I actually got it working on a branch here; You can try it out yourself :P
func-godot/func_godot_test_project@main...Pspritechologist:func_godot_test_project:main

[sinewavey]

A bit, but the build process would have already created the nodes and done things, so there wouldn't be a need to place the scene in again; just serializing it. At the time I hadn't read much of your proposal, though now that's changed

This is largely a question for runtime map building, and essentially, this is two sides of the same coin. If your method works in exported projects, then it more or less addresses things I was wondering about and can likely be done the same way, and if not, it can just be handled manually (like I am now; it's not much extra, in all honesty)

I'll have to tinker around with what this can do later!

[RhapsodyInGeek]

@sinewavey

If your method works in exported projects

It can't. You can't import resources at runtime, and part of the resource import process is to save them in compressed Godot format to be later packed into a PCK container. It's pretty much an Editor only feature.

Additionally, the only way you'll be able to "specify a different location for the generated scene" using the importer method would be to place the map file in another folder location.

The .map file is essentially treated like other scene files, like GLTF and .blend: it keeps the source file in the original location, then creates a resource in the .godot/import/ folder which is the actual imported scene file (AFAIK anyway). This is effectively an inheritable scene that needs to be placed in other scenes, so the only way to really specify a scene file path would be to just manually create the scene that uses the inherited map scene resource (if I'm understanding what you're asking).

[sinewavey]

Additionally, the only way you'll be able to "specify a different location for the generated scene" using the importer method would be to place the map file in another folder location.

I think it'd be expected the user would be prompted to save a file somewhere, even with a default location selected

The .map file is essentially treated like other scene files, like GLTF and .blend: it keeps the source file in the original location, then creates a resource in the .godot/import/ folder which is the actual imported scene file (AFAIK anyway). This is effectively an inheritable scene that needs to be placed in other scenes, so the only way to really specify a scene file path would be to just manually create the scene that uses the inherited map scene resource (if I'm understanding what you're asking).

Oh, that's annoying. I think that answers pretty much all of my questions (not that I mean any pushback - just curious about some capabilities) Thanks for the explanation.