Nope, RedirectTexture simply redirects the texture and is not able to change a color. The color needs to be changed AT EACH control (e.g. textureControlContainingACircle:SetColor(r, g, b, a)) which means you need to find out each control to change and change it via lua calls.
That's far too much work anyone would like to do. At best you create .dds textures with the correct values you want to see ingame and test them there.
But if e.g. the ingame control is setup by default to change the alpha / opacity to 0.8 (1 is non-see-through) you cannot fix this unlesss you find out the correct control name and use :SetAlpha(1) on it again. Same relates to colors. If the ingame control was set to use SetColor(1, 0, 0, 1) it will just make the texture red. No matetr what your standard .dds texture will look like.
|
appears like the only differences are with the textures, updated lib statement, and a few less indents in the code (cant imagine the latter makes any difference?)
|
Sure, what else would be needed?
If the texture paths changed you cannot redirect a non exisitng texture path to a new existing one. As the old cannot be found it will never be used any where. So the texture paths need to be the correct ones.
You can spy them from the gams source code by using the tool "Black Book Browser", search for .dds files in it.
Libraris also are a big problem if included and old -> settings do not work or whole addons cannot run properly. Could have been the reason why the addon did nothing. Remove alll libs of old addons "libs" subfolder and install them to live/AddOns "once" (single source of truth) should fix most of these issues. Maybe you need to add the libs to the addon's manifest txt file, via ## DependsOn: LibName1 LibName2 in order to load them before the addon.
And no, indents should not matter. Line braks could if placed wrong inside variable/function names, destroying the known name
