RicardoTM wrote: ↑March 6th, 2024, 10:37 pm
"Script: colors.lua:12: attempt to perform arithmetic on local 'r' (a string value)"
I'm using the correct syntax [&MeasureScript:FunctionName('255,50,197')]
Actually, this wasn't the correct syntax as per how your first two function parameters looked. You should have used [&MeasureScript:FunctionName(255,50,197)]. The third function will work with the '255,50,197' parameter though, since you extract the comma separated values from the string in the function body.
Additionally, you might want to see the tonumber() or tostring() functions in Lua, in order to solve other potential type mismatch errors.
Yincognito wrote: ↑March 7th, 2024, 2:32 am
Actually, this wasn't the correct syntax as per how your first two function parameters looked. You should have used [&MeasureScript:FunctionName(255,50,197)]. The third function will work with the '255,50,197' parameter though.
Additionally, you might want to see the tonumber() or tostring() functions in Lua, in order to solve other potential type mismatch errors.
I made some changes and now everything is working as it should (for now), when I finish adding the last functions (when I come up with them) i'll publish the entire code and then we can take a look at all my mistakes and perhaps fix them
RicardoTM wrote: ↑March 7th, 2024, 2:37 am
I made some changes and now everything is working as it should (for now), when I finish adding the last functions (when I come up with them) i'll publish the entire code and then we can take a look at all my mistakes and perhaps fix them
But it's easier taking a look at one mistake in several lines, instead of a dozen in 500 lines - not that you'll make them, of course, just in principle...
Anyway, wish you luck in your endeavor. Looking forward to see the result.
Yincognito wrote: ↑March 7th, 2024, 2:45 am
But it's easier taking a look at one mistake in several lines, instead of a dozen in 500 lines - not that you'll make them, of course, just in principle...
Anyway, wish you luck in your endeavor. Looking forward to see the result.
But it's more fun! Lol I have a question tho, the original code includes functions that return more than one color, like the split complementary for example. Is it possible to actually retrieve more than one color? I'm thinking those functions could set multiple colors to rainmeter variables instead of calling them directly with the [&measure:Function()] right?
RicardoTM wrote: ↑March 7th, 2024, 2:53 am
But it's more fun!
Joking aside, it's more fun for the user maybe. More work for the one debugging the "mess". But I know you understand it, you try to make things easier by posting only the relevant code. Looking for the needle in the haystack is something I usually try to avoid, if possible.
RicardoTM wrote: ↑March 7th, 2024, 2:53 am
Lol I have a question tho, the original code includes functions that return more than one color, like the split complementary for example. Is it possible to actually retrieve more than one color? I'm thinking those functions could set multiple colors to rainmeter variables instead of calling them directly with the [&measure:Function()] right?
Not in Rainmeter. Only one return value from Lua can be retrieved. I know, it's inconvenient, but that's how Rainmeter works, with single values. One way to workaround this is to return a concatenated string instead. Obviously, you'd then need to extract stuff from it in Rainmeter.
Yincognito wrote: ↑March 7th, 2024, 3:20 am
Joking aside, it's more fun for the user maybe. More work for the one debugging the "mess". But I know you understand it, you try to make things easier by posting only the relevant code. Looking for the needle in the haystack is something I usually try to avoid, if possible.
Not in Rainmeter. Only one return value from Lua can be retrieved. I know, it's inconvenient, but that's how Rainmeter works, with single values. One way to workaround this is to return a concatenated string instead. Obviously, you'd then need to extract stuff from it in Rainmeter.
Don't worry was just joking. I'll make sure most of the code is correct before I post it here
Well sure that is inconvenient. I guess by extract you mean using substitute. Well, good to know.
Testing is looking good so far.
Captura de pantalla 2024-03-06 212924.jpg
You do not have the required permissions to view the files attached to this post.
RicardoTM wrote: ↑March 7th, 2024, 3:30 am
Don't worry was just joking. I'll make sure most of the code is correct before I post it here
Well sure that is inconvenient. I guess by extract you mean using substitute. Well, good to know.
I know you were.
Yes, substitutes work wonders if used at their full capabilities. But you can set global variables to the desired return values as well, and retrieve the global ones in Rainmeter instead. Unfortunately, this won't work if you want to retrieve tables since Rainmeter lacks an equivalent type, so if that's the case, either returning it as a string or each element at a time is required. Another possibility is using bangs to set Rainmeter variables from Lua, but I personally try to avoid that, since such a code is less "portable" to a different skin with, say, different variables.
Yincognito wrote: ↑March 7th, 2024, 3:44 am
I know you were.
Yes, substitutes work wonders if used at their full capabilities. But you can set global variables to the desired return values as well, and retrieve the global ones in Rainmeter instead. Unfortunately, this won't work if you want to retrieve tables since Rainmeter lacks an equivalent type, so if that's the case, either returning it as a string or each element at a time is required. Another possibility is using bangs to set Rainmeter variables from Lua, but I personally try to avoid that, since such a code is less "portable" to a different skin with, say, different variables.
I think setting|writing variables would be the preferred method (from rainmeter using a measure) since using [&measure:function()] directly on meters require dynamic variables. I'm also against setting variables through the lua. The idea is for the skinner to decide where the colors go and how many they need.
RicardoTM wrote: ↑March 7th, 2024, 4:12 pm
I think setting|writing variables would be the preferred method (from rainmeter using a measure) since using [&measure:function()] directly on meters require dynamic variables. I'm also against setting variables through the lua. The idea is for the skinner to decide where the colors go and how many they need.
I though you talked about retrieving them in Rainmeter from Lua (at least that's what I was talking about), so not sure how setting / writing them from Rainmeter achieves that, but anyway, maybe we referred to different things.
On a second thought, I guess you can pass the variable name that you want to set as a string parameter to the Lua function, in order to bang back to the right one when returning, and if proper scripted using the ... variable number of parameters, control how many you need too (though even so, it might not completely solve the "portability" issue)...