Closed ljoonal closed 3 years ago
I think I'll add this into main, once I make sure that the bug with things going boom and looking like streamer mode is on is sorted out. I'll port everything over to the new mod structure once it's done, and probably add the ability for users to add their own icons.
Also, UIX does (kinda) have enum support, and the reason why knah only partially supports them is because enums are basically the same as strings in Tomlet's eyes. So, a simpler way to do enums in UIX is to just make the prefs strings, and then parse the enum value whenever you need them like I did in PlayerList here.
UIX isn't the only MelonLoader preferences manager [1], and implementing a workaround for a feature that's missing in a specific mod at the cost of breaking other implementations that do properly support it seems a bit counterproductive to me, thusly I've been poking around in the UIX code to see how hard it'd be to implement support for them without needing to convert the datatypes to strings and register them explicitly. No ETA on that though (and anyways it's not a given that knah would even want it merged), since I've had loads of issues trying to compile it, thus I did a janky workaround for now x'P
I don't really think it's worth supporting sinai's mod as it's not used by basically anyone that plays VRChat. Sinai's tool was mean to support games that don't already have a preference manager, not be an alternative.
Implying people don't use something because you don't know people that do
No, there are multiple other reasons I don't think many or any people use it.
I don't disagree that UIX is the most widely used preferences manager or that it should be supported. What I do disagree on is that the preferences of a mod being strongly tied to any preferences management mod. I would like though to be able to just register preferences using standard types. Since that way there wouldn't be a need to write any extra code to convert between the different data types manually. As things currently stand though, I do agree that the workaround I did isn't good; I just wanted to experiment how it'd look. Which led me to the conclusion that the most optimal course of action is to poke around from the UIX side to add support to enums without any registration which requires UIX to be pulled in as a dependency & string to enum conversion. But that all is a bit outside of the scope of this PR, which is why I've just left this as a draft :P
What I do disagree on is that the preferences of a mod being strongly tied to any preferences management mod.
Why though? There's no point in supporting other ones when there already is a very well established one that everyone can use. There is no point in supporting other ones, especially when you've only cited one.
Also, I know that almost no one uses that preference manager. This isn't me saying "oh sinai isn't successful as a dev" I'm simply just saying that it doesn't get many downloads [1]. At most we would be helping maybe like 5-10 people? That just isn't worth it.
I would like though to be able to just register preferences using standard types. Since that way there wouldn't be a need to write any extra code to convert between the different data types manually.
As I showed before it's literally 2 lines of code for each enum pref, that's hardly anything. By the time UIX gets proper enum support, we can easily port the preference since they're just stored as strings in the config file.
By the time UIX gets proper enum support, we can easily port the preference since they're just stored as strings in the config file.
Agreed. I did already say that the current thing I did was mostly an experiment. Practically speaking that's the most logical thing to do.
Why though? There's no point in supporting other ones when there already is a very well established one that everyone can use.
Out of principle. Because I think that the burden of handling preferences management UI should be on the preferences management mods. Making a workaround for a specific mod, when the framework itself supports a better alternative, feels counterproductive to me. It's a workaround that limits the potential of any other preferences management mods, and requires extra code. And there's a (at least to me) clear better solution, which is to add support in UIX, which would benefit other mods as well.
I do get that UIX is currently the mod that VRC mods pretty much need to support. And that it can be quickly and easily worked around currently.
I just don't feel like writing things that would make my own experience worse & that I would dislike writing, since modding for me is a thing I do for fun currently :P
Honestly, I'm too lazy to argue about this. knah will add support eventually (I asked him he said he would do a couple other things as well). Let's just keep things the way they are for now and hopefully knah will roll out enum support before long.
I don't really think it's worth supporting sinai's mod as it's not used by basically anyone that plays VRChat. Sinai's tool was mean to support games that don't already have a preference manager, not be an alternative.
Indeed. I was the one who requested it for games other than vrchat
I already removed it in the release
Not sure if this would just be better to separate into it's own fork mod or not, but I wanted to at least offer a PR if this would be wanted in the main mod.
Would basically default to the current behavior, but with added icons for: public, friends+, friends, joinable private (people on blue mode) and then keeping of course the current standard private instance icon.
I'm still thinking about just maybe changing the current is icon enabled values to enums of (show icon, default, hide users), and removing the current hidePrivateInstances as the effect would be replaced by setting private&joinable private to the "hide users" value.
Created the draft PR early so you can close it if I should just separate this into it's own mod.