I just went in to edit the provided config for a Plo Koon saber, and I noticed some defines in the top part of the config that were unfamiliar to me. I posted the whole config if you need to take a look, but the part I didn’t recognize is this:
#define RR1 Rgb<255,8,0>
#define RR2 Rgb<120,4,0>
#define RR3 Rgb<65,2,0>
#define OO1 Rgb<255,33,0>
#define OO2 Rgb<130,17,0>
#define OO3 Rgb<61,8,0>
#define YY1 Rgb<255,180,2>
#define YY2 Rgb<125,88,1>
#define YY3 Rgb<79,56,0>
#define GG1 Rgb<10,255,0>
#define GG2 Rgb<5,125,0>
#define GG3 Rgb<3,73,0>
#define LB1 Rgb<10,85,255>
#define LB2 Rgb<6,45,140>
#define LB3 Rgb<3,23,70>
#define BB1 Rgb<8,35,255>
#define BB2 Rgb<4,21,150>
#define BB3 Rgb<2,11,75>
#define WW1 Rgb<120,120,120>
#define WW2 Rgb<60,60,60>
#define WW3 Rgb<30,30,30>
#define PP1 Rgb<120,0,255>
#define PP2 Rgb<60,0,128>
#define PP3 Rgb<30,0,64>
I don’t think I’ve ever seen that in a config before. what is it, and is it necessary? Thanks!
I would ask whoever created. For some reason they’re using defines to name colors in the styles, no idea why but your presets won’t compile without those defines as they’re currently written. Only the person who wrote it could explain why though.
Those are color definitions and they are used in the styles. I didn’t go looking for all of them in details but with a quick glance, I saw several of them in the styles.
If your saber is working, keep a backup before deleting them.
I don’t really need to delete them for any reason, I guess. I was just going to customize a few settings (like add edit and battle modes) and add some of my own blade styles. can I still add new blade styles like I normally would with all of that in there, or will it mess with those?
You can update it as it is BUT those styles are really old syntax (and missing most of the current features), so if you start adding new styles you may find you run out of memory very quickly, especially if you generate styles in my library.
Mixing OS version syntaxes will often waste a lot of memory, to maximize space, especially if you overflow FLASH I would recommend generating new style code for all presets from the same source.
My library, in particular, generates styles as optimized as possible but if you have really old styles in the config most of the optimization isn’t realized.
If you want to keep what is on your saber and add your own stuff to your saber/config, then leave the original code as it is, you certainly don’t want to delete something that you don’t know/understand what it does, add your own code to your config the same way you normally do but being cautious to not “break” what is already there: add one thing, test to see it it compiles ,add the next thing, test again, …
yeah, it’s at 99% as it is, and it seemed to be having some issues on a few of the blade styles (seemed to lag or have sound issues, crashed once just cycling through styles). is there any easy way of doing that, or would I just need to go through them all one by one and redo them from scratch?
add: most styles I would add are from your library
Lag or crashing is almost always due to SD card speed, I would run ‘sdtest’ and make sure that card meets minimum requirements.
You would recreate the styles in the library for the presets. Especially, styles as old as those, there’s no other way to really replace. A lot those look like OS3 or 4 to me, so “ancient” by today’s standards.
Yeah, if using my library AND you generate all of the styles over, you’d probably fit more. If you’re at 99% you won’t be able to add anything else.
yeah, I was planning on deleting a handful of them that I don’t really care about. there are a lot on it. it has 4 different Zelda fonts for some reason .
I’ll probably just leave the config as is, delete about half of the styles, and add a few that I really want.
wouldn’t cause any issues with adding defines like edit mode or anything, though, correct?
thanks a ton to both of you for helping out, as always.
Like I said, if you mix old syntax and new ones from my library you’ll be wasting some memory, adding new features like edit mode will use up even more memory - plus those old styles are not Edit Mode compatible - so you’d probably have to remove a lot more. If you get it to fit then everything would still work, but none of those old styles would be editable AND each of those old styles will reduce the new editable styles you can potentially add.
At the end of the day, they’ll work BUT you’re going to waste memory that could allow for other things by having them mixed in.
There’s also required set up for Edit Mode and other features, so as you add defines and set things up you will be using more memory than that config as is.
makes sense. it has some unique blade styles, but they may not be worth it. especially if I can recreate any that I really want. if I do decide to redo them all, should I just cut that first part that I posted along with all the blade styles and then add my own? okay to leave everything else the same?
You’d edit your config accordingly. I would keep a backup first and foremost. Then I would update one preset at a time or delete the preset entirely. This is the safest way to make sure you don’t change or delete anything and cause an issue.
If you need a refresher on updating your config I would recommend this page:
You never want to change your BladeConfig unless you’ve made wiring changes, as to the top section defines, those would remain roughly the same and you’d add others based on features or options you want (as well the prop you’re using).
yeah, this config is all goofy. It’s also set up as having two blades. there is definitely only one blade. no accent lights or crystals or anything. not sure who put this thing together. probably worth just redoing it.
Fwiw, no defines are real. They’re all in your mind
In seriousness, you can #define just about anything. (Well, anything the cpp accepts)
It’s a kind of weird pattern in C and C++ that the cpp’s macros are used to enable/disable code conditionally via checking if a macro is defined. (Often an empty macro)
If you define an empty macro, and there’s nowhere that checks whether it exists to enable/disable something, it simply does nothing.
Wherever a macro is used though (besides “if defined” blocks) it’s just like find/replace.
That’s somewhat simplified and probably more than you care to know, feel free to ignore me, but if you’re at all curious, now you know
.
