Is tbloader still in development?

[elvisish]

Interested if it's abandoned or if there's still plans on developing tbloader futher?

[codecat]

Not actively by me right now. I will probably get back to development on this if I get back to my Godot projects and am not satisfied with the new Qodot. If anyone wants to take over maintenance, I'm open to discussing it 😸

[elvisish]

That's a shame, this was so good and way better than the original Qodot and worked with gdscript so well.

[krazyjakee]

@codecat I'm willing to continue the development and maintenance of this project but my approach has been controversial here in the past so it may not fly. My agenda would be to take anything that didn't require top performance and continue to develop it in GDScript. My reason is simply to lower the bar for new contributors.
If that's not an issue then my credentials are here and here.

[solitaryurt]

I do think its pragmatic to utilize GDScript wherever performance isn't critical.

[elvisish]

@codecat I'm willing to continue the development and maintenance of this project but my approach has been controversial here in the past so it may not fly. My agenda would be to take anything that didn't require top performance and continue to develop it in GDScript. My reason is simply to lower the bar for new contributors. If that's not an issue then my credentials are here and here.

I think it was written in cpp to speed things up, Qodot 1 was based on gdscript and was slow, Qodot 2 is using mono to keep the speeds improved and I think tbloader probably should stay as extension for the speed (if there's further development).

[krazyjakee]

@elvisish to clarify, when I said My agenda would be to take anything that didn't require top performance and continue to develop it in GDScript., I meant it.

• Generating FGD files
• More default entities
• Helper functions and nodes for entities

All easily achievable in GDScript with little impact on performance.

Any furthering of the map reading and mesh building must remain in C++

[elvisish]

@elvisish to clarify, when I said My agenda would be to take anything that didn't require top performance and continue to develop it in GDScript., I meant it.

• Generating FGD files
• More default entities
• Helper functions and nodes for entities

All easily achievable in GDScript with little impact on performance.

Any furthering of the map reading and mesh building must remain in C++

Oh I see, sorry I understand now. To be honest, I've never really known why Qodot or TBLoader would need particularly good performance as they build static level geometry, nothing relies on runtime does it?

[krazyjakee]

@elvisish I'd love to see runtime options for Godot based map editors or community map loading.

Even if it's not at runtime the development workflow would become painfully slow.

[elvisish]

Is there any way of getting this forked and working for 4.1? I tried using Qodot today as an alternative now TBLoader is depreciated but everything in my project was broken in the mono editor, so many errors, TBLoader just... works.

[venilark]

Please don't let this fantastic plugin die. 4.2 or any future Godot version could break something and we would be left only with Qodot that needs the Mono version of Godot

[codecat]

Don't worry, I'm usually around to do updates if stuff breaks, even if I don't actively work on adding new features at this point in time. Just let me know if a big update comes out and breaks it 😄

[Skaruts]

I actually wish development could continue (if not here then maybe a fork), because I find this to be a much better approach than Qodot. I find Qodot overly complicated, and highly prone to mistakes, due to its over-reliance on Godot resources (the interface of which has also been terribly clunky so far). And now it requires you to install .NET crap to use it with the mono version...

But I think there's improvements that could still be made to TBLoader, and it's a pity if it stops here.

E.g.

• there ought to be a place outside the TBLoader node where to define the default behaviour of the plugin. Imo, a simple cfg file at res:// might be the best option, as it's the easiest for a person to edit and read. The TBLoader node could override some of those options, but the defaults shouldn't be carried by the node. New nodes lose all that, and you have to copy/paste the existinng node to work around that. But if you forget about it and delete that scene, then you have to set it all up again.

• the mesh generation should detect and exclude fully hidden faces to avoid overdraw and relieve mappers from having to manually keep using skip textures.

• users should be allowed to store materials in a separate folder from textures, if they preferred (and also in subfolders of that folder, for better organization)

• the user ought to be able to decide how to deal with certain entity properties. The plugin should automatically handle angles, but apart from that, not all entities interpret properties the same way. E.g., origin would be the hinge of a func_door_rotating, shadows would be a flag for whether to activate shadow casting on a light, color could be the light_color, but it could also be something entirely different in some other entity. All of this could be set at build time.

  • there might also be other ways to implement entities. One of my experiments with another plugin involved storing a dictionary with all the properties in the entity, rather than having the properties on the entity's node itself. That allowed discarding those that were no longer needed. The plugin could allow flexibility on this by iterating through the entities and giving them the dictionary of properties. Jitspoe's BSP importer gives entities their properties one at a time, which is also a nice way to go about it.

  • (EDIT: also, it's not a good idea to set entity properties in TB with the same name as Godot's node properties and rely on that on import, because if Godot ever changes the name of even one of those properties, it will severely break your maps. You'll have to change that property on all entities that use it in all your maps. It's much safer to use a set of property names that get "translated" by you on import, and if Godot ever changes anything, all you have to do is fix your import code.)

• there ought to be two post-import passes, one for nodes to rearrange themselves if needed (each with full access to a list of all entities), and another for setting up navmeshes, occluders, GI or lightmaps, etc.

  • One example of nodes needing to rearrange themselves, is when you want to make a trigger that activates and moves along with an elevator platform. That trigger's node will have to be parented to the elevator node during post import. In TB you could set a parent property to the elevator's name or targetname, and then on post-import that entity would search for that "parent" in the list of entities and reparent itself to it.

  • Also, for setting up navmeshes, many things need to be temporarily removed from the map, to not interfere with proper navmesh generation. E.g., the player itself, triggers, colliders that only affect the player or projectiles, etc. Or else the navmesh will go around all of them.

• can this plugin be used fully during runtime? I haven't tested this yet, but that will be a deal breaker if it can't, because I'm aiming to make a moddable game.

There's a whole lot that could be improved. I'm personally not great with C++, so I don't suppose there's much I can do about it. :(

[venilark]

I actually wish development could continue (if not here then maybe a fork), because I find this to be a much better approach than Qodot. I find Qodot overly complicated, and highly prone to mistakes, due to its over-reliance on Godot resources (the interface of which has also been terribly clunky so far). And now it requires you to install .NET crap to use it with the mono version...

But I think there's improvements that could still be made to TBLoader, and it's a pity if it stops here.

E.g.

* there ought to be a place outside the `TBLoader` node where to define the default behaviour of the plugin. Imo, a simple cfg file at `res://` might be the best option, as it's the easiest for a person to edit and read. The `TBLoader` node could override some of those options, but the defaults shouldn't be carried by the node. New nodes lose all that, and you have to copy/paste the existinng node to work around that. But if you forget about it and delete that scene, then you have to set it all up again.

* the mesh generation should detect and exclude fully hidden faces to avoid overdraw and relieve mappers from having to manually keep using skip textures.

* users should be allowed to store materials in a separate folder from textures, if they preferred (and also in subfolders of that folder, for better organization)

* the user ought to be able to decide how to deal with certain entity properties. The plugin should automatically handle `angles`, but apart from that, not all entities interpret properties the same way. E.g., `origin` would be the hinge of a `func_door_rotating`, `shadows` would be a flag for whether to activate shadow casting on a light, `color` could be the `light_color`, but it could also be something entirely different in some other entity. All of this could be set at build time.
  
  * there might also be other ways to implement entities. One of my experiments with another plugin involved storing a dictionary with all the properties in the entity, rather than having the properties on the entity's node itself. That allowed discarding those that were no longer needed. The plugin could allow flexibility on this by iterating through the entities and giving them the dictionary of properties. Jitspoe's BSP importer gives entities their properties one at a time, which is also a nice way to go about it.
  * (EDIT: also, it's not a good idea to set entity properties in TB with the same name as Godot's node properties and rely on that on import, because if Godot ever changes the name of even one of those properties, it will severely break your maps. You'll have to change that property on all entities that use it in all your maps. It's much safer to use a set of property names that get "translated" by you on import, and if Godot ever changes anything, all you have to do is fix your import code.)

* there ought to be two post-import passes, one for nodes to rearrange themselves if needed (each with full access to a list of all entities), and another for setting up navmeshes, occluders, GI or lightmaps, etc.
  
  * One example of nodes needing to rearrange themselves, is when you want to make a trigger that activates and moves along with an elevator platform. That trigger's node will have to be parented to the elevator node during post import. In TB you could set a `parent` property to the elevator's `name` or `targetname`, and then on post-import that entity would search for that "parent" in the list of entities and reparent itself to it.
  * Also, for setting up navmeshes, many things need to be temporarily removed from the map, to not interfere with proper navmesh generation. E.g., the player itself, triggers, colliders that only affect the player or projectiles, etc. Or else the navmesh will go around all of them.

* can this plugin be used fully during runtime? I haven't tested this yet, but that will be a deal breaker if it can't, because I'm aiming to make a moddable game.

There's a whole lot that could be improved. I'm personally not great with C++, so I don't suppose there's much I can do about it. :(

I'm thankful the dev is willing to fix the plugin if any new godot version breaks compatibility but yes, if someone else can step in and continue development would be awesome
what you said about the settings file would be great, I often forget to set the collision layers and masks to the ones I need once I rebuild a map

[venilark]

I just tested it with the 4.2 beta 5 and everything seems working fine. It was also a 4.1 project and it had to reimport the meshes because they changed how meshes work and still nothing went wrong.
The TBLoader node icon is gone for some reason and hopefully that doesn't mean anything important is broken

I'll test again with newer betas/RCs and then 4.2-release

[Skaruts]

what you said about the settings file would be great

I have to admit, though, that it's way easier said than done. I really needed some of my suggestions for my project, so I decided to try to put my own ideas to the test, and take a bit of the rust out of my C++, and I've managed to get some things done, but the settings file isn't one of them.

(EDIT: actually managed to get it working. Will see how it how it fares as I use it.)

---

On the other hand the post-import passes were easier than I thought, and a single one is actually enough. From there, users can gather up all entities (children of TBLoader node) and do a pass on each of them however they want, and also set up navmeshes, occluders, GI, whatever. In my code I put the root node of the map scene to good use: if the root node has a script that implements the post-build function, it gets called. I also added a pre-build pass, just because why not (I can't think of a use for it, but it's just another function call).

I also played with the idea of having a separate script for that same purpose. So I have both options currently implemented.

I've been doing all this in Godot 4.1.1 for now.

[venilark]

4.2 RC1, still working fine :)