[closed] Why is there no generic mod config GUI?

[GenElectrovise]

Heyo, I'm currently in the process of making a GUI for my mod's configuration options, accessible from "Mods > My Mod > Config" (The whole business of registering an extension point etc). Given the shear number of times poor Diesieben has had to answer the same question of how to achieve this I'd say it's a pretty common query (and why wouldn't it be config is pretty standard stuff).

 

Why is this config GUI not built into Forge? Is there some secret reason I should know about or has simply noone gotten round to it? Maybe just a decision to let modders implement it themselves? But then surely you could still have a generic GUI and provide a hook for modders to edit or replace it if they choose?

 

If my implementation is successful enough and testable I may just put in a pull request on the Forge GitHub to implement this. But it does perplex me why this isn't a thing...

 

All the best to whomever reads this!

 

P.s. Apologies if I have missed something important: it is very late.

Edited May 8, 2022 by GenElectrovise
Closed.

[diesieben07]

8 hours ago, GenElectrovise said:

Why is this config GUI not built into Forge?

Because it is surprisingly complex to write and maintain a fully generic config GUI code. Nobody has stepped up to provide a stable and maintainable implementation.

[GenElectrovise]

Fair enough seems like a pretty good reason.

 

11 minutes ago, diesieben07 said:

Nobody has stepped up to provide a stable and maintainable implementation.

In this case sounds like it could be more complex than I thought, but if I achieve anything worth sharing I'll put in a pull request.

Thanks!

[LexManos]

More specifically, we used to have one, but then our rendering guy got stolen by Mojang. And thee cost of updating it everytime they changed something upstream got too  much.

There are mods out there that add generic screens. The main reason there isn't one in Forge is manpower to maintain them in the future.

[GenElectrovise]

 

13 minutes ago, LexManos said:

And thee cost of updating it everytime they changed something upstream got too  much.

If I may ask, what was the bottleneck in updating it? I suppose changes to screen rendering, given you mentioned the rendering guy?

If I'm going to try to implement my own version, I may as well try to target the problem!! 

[GenElectrovise]

13 hours ago, LexManos said:

The main reason there isn't one in Forge is manpower to maintain them in the future.

What would this mean in this context exactly? (Trying to consider whether this project would be a valuable addition to Forge)

To clarify, does this mean: "any system is too much to maintain, so it's better to just leave it to mod authors"

Or does it mean: "If we had a more maintainable system, it would be a useful addition"

I'm basically asking because if it's the former, then I'll only make a screen for my own mods; if it's the latter, then I'll at least have a shot at implementing it in Forge itself

[LexManos]

Most  likely its the later. But the cost is quite a lot with mojang liking to re-write the rendering system.
Again, there are already a few 'generic config gui' mods  out there that work.
We provide a  fairly simple data layer for defining config objects, so a few  people have taken it  upon themselves to make them into mods.

[GenElectrovise]

3 hours ago, LexManos said:

But the cost is quite a lot with mojang liking to re-write the rendering system.

It seems to me that anything that you'd need in order to make the GUI could be accomplished with #drawString or with Widgets. Is maintaining these the cost of which you speak?

After all, a config GUI is just rendering a list of keys and a way to edit each value (either toggles or text widgets), no?

I suppose if you wanted to cut down on maintenance then the first port of call would be to minimise independent calls to volatile 3rd party code (i.e. Minecraft itself).

Perhaps it is not so simple though... If it was I'd think that someone would have gotten there before me?

Edited May 7, 2022 by GenElectrovise

[LexManos]

Again people HAVE done this. It's not just draw strings and widgets. Because configs can have a lot of config value types that dont exist in vanilla.
All I can say is just go do it and see what happens.

[Draco18s]

35 minutes ago, LexManos said:

Because configs can have a lot of config value types that dont exist in vanilla.

Case in point, my work project. Which is Unity/C#, but the idea is the same.

The Unity inspector is pretty good at finding public/serializable values and showing them in a list in the Inspector gui, but it's layout or labels aren't always the best, and there's only so much you can do with annotations (of which there are several). So for more flexibility, Unity offers both a CustomInspector feature and a CustomPropertyDrawer feature (the former is for Unity-objects that appear in the inspector, the latter for miscellaneous objects that are contained within the former).

However even this is limited to only the things Unity knows how to serialize. Generics? Lists of Interface objects? Abstracts? Not supported.

But my project needed support for generic objects because of how our interaction system (ECS components encapsulating simple finite state objects) and our grading system (did the user perform the following steps in the prescribed order?) had to integrate with each other.

I had a hard requirement to be able to display any object Foo in the inspector, regardless of what Foo's type was. So I had to dig into Unity's inspector code and extract out how it handled all of the types it did handle and rewrite it to accept arbitrary values, that if it didn't match the available types, would use reflection to find all of the object's public/serializable fields and then try to draw all of those, recursing down again and again until a primative type was able to be drawn.

And even with caching to avoid duplicate reflection lookups, it still isn't fast. There's a soft limit of about 20-50 of these inspector drawers that Unity can draw at one time before the lag becomes disruptive. And when you're dealing with complex custom types, the layout isn't pretty. Thus I had to go reimplement Unity's custom editor and custom property drawer system as well.

Which is to say...if it's more than a handful of very simple objects (ints, strings, booleans...) you're going to have to do the work yourself.

[GenElectrovise]

7 hours ago, LexManos said:

All I can say is just go do it and see what happens.

Wise advice for many circumstances. Interesting commit also.

 

6 hours ago, Draco18s said:

Case in point, my work project. Which is Unity/C#, but the idea is the same.

The Unity inspector is pretty good at finding public/serializable values and showing them in a list in the Inspector gui, but it's layout or labels aren't always the best, and there's only so much you can do with annotations (of which there are several). So for more flexibility, Unity offers both a CustomInspector feature and a CustomPropertyDrawer feature (the former is for Unity-objects that appear in the inspector, the latter for miscellaneous objects that are contained within the former).

However even this is limited to only the things Unity knows how to serialize. Generics? Lists of Interface objects? Abstracts? Not supported.

But my project needed support for generic objects because of how our interaction system (ECS components encapsulating simple finite state objects) and our grading system (did the user perform the following steps in the prescribed order?) had to integrate with each other.

I had a hard requirement to be able to display any object Foo in the inspector, regardless of what Foo's type was. So I had to dig into Unity's inspector code and extract out how it handled all of the types it did handle and rewrite it to accept arbitrary values, that if it didn't match the available types, would use reflection to find all of the object's public/serializable fields and then try to draw all of those, recursing down again and again until a primative type was able to be drawn.

And even with caching to avoid duplicate reflection lookups, it still isn't fast. There's a soft limit of about 20-50 of these inspector drawers that Unity can draw at one time before the lag becomes disruptive. And when you're dealing with complex custom types, the layout isn't pretty. Thus I had to go reimplement Unity's custom editor and custom property drawer system as well.

Which is to say...if it's more than a handful of very simple objects (ints, strings, booleans...) you're going to have to do the work yourself.

Thank you - this is very comprehensive and I understand the point that LexManos is trying to make now. This is the explanation I've been looking for.

I will now close this thread.