@Bimbam said:
To clarify, plugins/extensions are in my mind 'Godothonic' (idk, that made sense in my head) and serve to keep the engine lightweight by being a bolt-on. Forks, technically, fall into this category depending on their intent and without Forks we wouldn't have many of the extensions available that require more extensive changes to core code (like navigation-lite).
That said, these extensions do not tend to be a whole slue of extensions bundled together a la goost, which I admit I have only briefly looked at, so apologies if I'm jumping to conclusions, but it strikes me more like a competing/complementing project (I mean it's called 'goostengine') with a different core direction (i.e Godot core is too lightweight).
It's quite interesting to see how you interpret this!
goostengine is an umbrella organization for all extension-related repositories. I could've picked goost name, but it's already taken by some user at GitHub. :D
Due to this, I've decided to (re)name organization to goostengine, in a way which reflects the intention of "if something should be in Godot, let it be in Godot". The idea is that, if you were to take all Goost features and git merge it into Godot, on a conceptual level it would not lead to "merge conflicts" and it would "just work", so to speak. This is to speed up the process of upstreaming features to Godot, if seen useful by Godot core developers.
Even when you look at the source, you may mistakenly say that it's a Godot fork, but the thing is that the structure is made in a way to reflect Godot's one, for maximum workflow compatibility (again, with an intention that features could be easily ported to Godot in the future).
That said, these extensions do not tend to be a whole slue of extensions bundled together a la goost, which I admit I have only briefly looked at, so apologies if I'm jumping to conclusions
Yes, I strongly recommend going through Goost development philosophy and principles first, and Goost documentation in general.
Saying it's not a fork is like saying WINE is not an emulator. Even if it is not technically by definition, the majority of people using it won't/don't care or know the difference, because it serves the same purpose. Whether this is a good or bad thing is yet to be seen, I don't know the historical/political reasons for the 'not a fork' and was only basing my reply on situations I have seen first hand.
You say that you don't know whether it's a good or a bad thing. But according to previous discussion here, when people hear "fork", they get annoyed, which in most likelihood means that they see it as a bad thing. That's why I have to explicitly state that it's not a fork, and the intention is completely different. If this intention ever changes, it's going to be another project, but maintaining a fork for a project like Godot is a full-time job endeavor, so no thanks... :tongue:
@Megalomaniak said:
Well, goost seems to me like a redistribution of godot including some extra things, but not really substantially changing the core of whats already there. Feel free to correct me if I'm wrong on that. To me a 'Fork' can be that but what most people think of when using the term fork is probably something more significantly divergent.
I'm distributing Godot + Goost builds, and don't call it just Goost (you can see this as a Boost C++ libraries). Unfortunately, distributing binaries by recompiling the engine is the only way C++ modules can be integrated, it's just that some people asked me to distribute Godot + Goost builds (I'd even recommend compiling your own version of Godot if you already code in C++ in your project, especially when you need other stuff like Steam/FMOD integration). I know that there's GDNative but I have found it quite complex to use, and not everything can be implemented via GDNative alone. I really hope GDExtension could change this!
And by the way, one cannot really change the core via C++ modules. You can only patch it, but as I said, it's a great maintenance burden of having to constantly update those patches due to merge conflicts, so I only revert to this kind of approach in cases when it's simply not possible to implement a feature without applying that small patch, yet in most cases those kind of patches eventually get merged directly in Godot.
Having said that, it boils down to intention, and it's essentially about trust: do you believe what I say? :)
