The reason why is easy to deduct, since the reference to the value of a #variable# in Rainmeter is typically enclosed by # symbols. Therefore, what you experience basically means that the skin cannot get the values of the variables it uses, so the literal reference to the value of that variable (similar to the example above) is used / displayed instead (e.g. #Disco#, #Drive1#, etc).Hey, that worked on one of them! Thanks! Problem is, I tried it with another one, Pixcell's Radiante suite, which I have been tinkering with, trying to get it to work with the changes. Problem is, simply changing the config name causes the skin's colors to go from green to white, and some of the text to have # next to them, as well as the drive panels not to work as the options panel not to work, doesn't matter if I change the layout file. I don't know why, though. Might just have to leave skins like that alone, unless you can think of a reason why it does this. I have a screenshot here. https://imgur.com/a/5w3LAkG
As for the solution to this, it is indeed a bit more complicated and requires more time and effort to implement. A config / skin can declare and store the variables it uses either in its own .ini file, or in other .inc files that are "embedded" into that .ini by using @include...=<pathtotheincfile> options:
https://docs.rainmeter.net/manual/skins/include-option/
The problem with this suite is that, unlike most suites / skins that are perfectly "portable" by referring to various such .inc file paths exclusively using generic / system independent built-in variables:
https://docs.rainmeter.net/manual/variables/built-in-variables/
this suite resorts to referring to such paths using the literal "Radiante" name, which will obviously not work if you rename the suite's folder and such. For example, in the Disco 1.ini file, you have:
Code:
@include=#SKINSPATH#Radiante\variables.inc
Code:
@include=#ROOTCONFIGPATH#\variables.inc
There are many such instances if you look at all the codes in that suite, so it would take a while to correct them all, because what I mentioned was just an example, there are other forms and paths in the same vein, not to mention the author often using his own local paths which would not exist on someone else's computer. One of the main concerns an author should have when releasing his skin publicly should be to ensure it would work on anyone's computer and in any circumstances, which here is not pursued completely, though the suite actually looks nice overall.
As for what you should do in this case, it's up to you. Renaming only the skin packages, making a text file, a table or even an image, saving layouts under the desired names, creating a simple "skin list" skin to use as a "helper", there are many creative ways to do what you want, but obviously you need to choose the most suited / comfortable one.
Statistics: Posted by Yincognito — Today, 12:12 am