Bolt-Scripts / MHR-InGame-ModMenu-API

A user-friendly IMGUI inspired API for drawing in-game settings menus for REF mods in MHRise
13 stars 4 forks source link

[Feature Suggestion] Custom Colors #2

Closed GreenComfyTea closed 2 years ago

GreenComfyTea commented 2 years ago

As you know there are 3 colors available: YEL, RED and GRAY for <COL> tag. The singleton that handles is snow.gui.MessageManager. There are fields are might be interested in: 1) snow.gui.MessageManager -> ColTagUserData -> DataList contains colors and their color hex codes (as strings). You can probably populate it with your own colors. 2) snow.gui.MessageManager -> AdditionalMessageTagList contains tags and each tag has a function that does the magic associated with it. So theoretically you can make your own tags, thou I imagine it being pretty hard to do.

image

Bolt-Scripts commented 2 years ago

I looked briefly for something like this when I originally found the color stuff but didn't find anything too interesting, so this is neat. Not really sure what kind of custom tags would even be useful though, but I imagine for sure custom colors are possible then.

Bolt-Scripts commented 2 years ago

I've got this working (90a100bfc388e5441e8af1940e234b83294de715) and it was pretty simple but man this feels implemented pretty dumb lmao. I wasn't expecting it to work because its just a list of strings essentially and I thought it might just be used on initialization of something else, but no it just works if you add to the list. They really should've used a dictionary or something for this. Now somewhere the game has to iterate this list to look for the tag based on string equivalence. It doesn't really matter but setting it up with a dictionary just would've been easier and faster. Bweh Bweh Bweh The only real annoyance on my part is that I now have to actually make sure not to add duplicate stuff on script reload

GreenComfyTea commented 2 years ago

Nice! Maybe rename purp to PUR thou to follow same naming pattern as capcom?

Bolt-Scripts commented 2 years ago

Idunno, it's just an example. The point is that it can be anything so It shouldn't matter. People can add their own colors and I wouldn't want to encourage using simple names because they could overwrite each other. In practice, I doubt it'll matter

GreenComfyTea commented 2 years ago

Will you provide endpoints in your mod to add custom colors? Because as you said you need to check for duplicates. Leaving it to modders will create a mess.

Bolt-Scripts commented 2 years ago

It's already there, youll see modUI.AddTextColor("purp", "9F2B68"); in the example thing for that color.

It doesn't actually matter if there's duplicate things in the list, it'll just use the first one. On initialization I reset the list though. A mess, maybe, but it's a mess that nobody will have to look at. Maybe it's giving too much control all willy nilly but modding is about freedom bayybeee

GreenComfyTea commented 2 years ago

Ah sorry, my brain disabled itself. Of course, you already added AddTextColor, since there is purp now xD.

GreenComfyTea commented 2 years ago

Offtopic: It seems that when I do menuUI.OnMenu(name, description, callback), the callback is getting called once during initialization. I run into a problem that its getting called, but my other modules are not initialized yet, so it throws an error. Maybe don't do the call?

Screenshot ![image](https://user-images.githubusercontent.com/30152047/183245276-573c498a-dcb0-4ba4-b658-47d235f19799.png).
Bolt-Scripts commented 2 years ago

Ah yeah, somewhat of a holdover of the initial design. It needs to be called at some point on initialization because that's how it generates the data, but it can easily be moved to the rest of the UI init stuff that runs only when the menu is actually opened. Now fixed in bcb27793c0923f2884e60fd75dbb08183ee20d7f