I’ve moved!

You can now find me at @Ori.

  • 3 Posts
  • 24 Comments
Joined 3 years ago
cake
Cake day: June 18th, 2023

help-circle





  • Just took a look. With the previous version of kmo, it does in fact work when compatibility mode is enabled. I think that’s probably the best solution to hope for without slowing down your own enhancements to the point of being a visual hindrance. Thanks for taking a look.

    I just need to up my visual appearance game now. Your dropdown appearance and effect is much more visually appealing and while my implementation is meant to make mod options more accessible for would-be devs, it would be ideal to make it visually appealing as well.


  • Version 0.2.2 released.

    I noticed that KUP (Kbin Usability Pack) 0.2.1 by @Perry added some settings refactoring that hides the old .settings-list instead of updating in place. This unfortunately has a side-effect of causing script’s settings that are slower, or wait on DOM to load, to be hidden instead of displayed with their new refactor.

    In order to prevent this issue in the future, I’ve updated to create our own DIV and simply append it to the #settings.section DIV instead. Without KUP, you’ll notice no difference in how settings are displayed from version 0.2.1, but if you’re using KUP, it currently puts your options section at the top of the new section created by KUP. I imagine this will change if KUP moves to prepend instead of append. In my view, mod options should have always been last in any settings list solution, so I do hope that change is made at the very least.









  • Yep, I’ve looked at it, used it a bit. I feel as though the two projects are distinct enough that they could co-exist. Whereas megamod is a mod manager where you can toggle on/off, it becomes a burden for script writers to maintain two separate sets of options for their scripts - one for megamod and one for a standalone version.

    In contrast, this script isn’t intended to be installed as a userscript. Instead, it’s to supplement other developers userscripts. A userscript that is setup to work with megamod could still utilize this script and simply lightens the load on the developer.

    My reasoning is that I agree with @JohnEdwa and, subsequently, @SirPsychoMantis - at least partially. It makes sense for options to be standardized in one place, in this case the options menu. I also believe that if megamod does go mainstream, it’s mod manager should be separate.

    Hope that makes sense. ( っ- ‸ - c)