If you don't mind to review my config. Comments and questions added in the config

Proffieboards Padawan Area
1

Hello The Crusible,

I have read as much as I could digest so far from https://pod.hubbe.net/ & GitHub - profezzorn/ProffieOSDocs: Documentation for ProffieOS, I still need to go through most of Fett263 Proffieboard ProffiePixel Lightsaber Resources and I am sure I missed a lot.

I have added many #define, the ones I thought will be helpfull.
I have added many of my comments and/or questions in the config.

I would greatly appreciate any comments and suggestions if you care to look through it.

Thank you.

my_oliconfig.h (20.4 KB)

2

In mine, I get a little clickable blue arrow icon thing when I roll over a URL.

In my limited experience, I never found these did anything. It didn’t matter with or without.

This is when the MOSFETS (all 6 of them) turn off, so it’s not necessarily just accent LEDs.

Nope.

Edit Settings is a smaller subset of all of the available Fett263 menu items. Edit Mode is the full blown, all the options version. You can choose to use one or the other based on how the defines are enabled.

SAVE_STATE is one define to encompass SAVE_COLOR_CHANGE, SAVE_VOLUME and SAVE_PRESET. (From ProffieOS 7.8 onward, this also encompasses SAVE_BLADE_DIMMING). You do not need to explicitly define those if you use just SAVE_STATE.

“Special Abilities” are user effects such as EFFECT_USER1 that a prop file can set to do anything, as opposed to like “EFFECT_CLASH” which would always be a clash.
By using the Fett263 Style Library, many different features and effects can be set to use them with a ton of flexibility in your blade styles created there.

NO_REPEAT_RANDOM is an OS System level define that prevents the same effect file from playing back-to-back (like blst02.wav, blst02.wav) so as to keep variety and avoid noticeable repeats. FETT263_RANDOMIZE_QUOTE_PLAYER is specific to using the saber_fett263.buttons.h prop file, and deals with whether quote sound files are randomized or played sequentially.

COLOR_CHANGE_DIRECT makes it so that simply entering Color Change Mode will select the next color in the ColorChange list and exit Color Change Mode. Fett263’s prop handles ColorChange a bit differently, so check with his documentation.
EXTRA_COLOR_BUFFER_SPACE is a define that can speed up processing a bit. Basically, it can calculate the colors for the next blade (or the next frame for the same blade) even though it’s not done feeding out the data for the data in the color buffer yet. It’s the equivalent of just increasing maxLedsPerStrip.

I guess you mean all in the same thing (saber?) as opposed to removing the board from one prop and installing it into another?
Either way, the answer is yes. There are prop files that turn the controls into whatever is appropriate for those uses. Look in the ProffieOS/props folder and read through the top comments section of the files. You can even have a dual_prop file situation, such as Ezra’s blaster that turns into a saber.

Note that you don’t “need” to have a separate preset array for a no-blade state.
You can set both blade arrays in the BladeConfig to use the same CONFIGARRAY(), like CONFIGARRAY(presets). Having 2 different preset “banks” is for when you want different fonts or blade styles for when you remove the blade.

Nothing much, only you’d only have a few pixels so location based effects wouldn’t really show obviously.

You’d need an RFID reader and tags of some sort. I have not dabbled with this so someone else can chime in, but the use I’ve seen someone use was to differentiate crystals in a chamber, sort of like Savi’s Workshop stuff does, utilizing PoroffieOS Blade ID.

Hope that helps.

3

Yeah, BLE_NAME/BLE_PASSWORD only works with BLE modules that have been customized to support these, and currently there are no such modules available.

Most of these defines are documented here:

If the documentation isn’t clear enough, either suggest an edit, or file an issue on the POD github to remind me to improve it.

4

When using my prop, this page will help with all of the “FETT263” defines as well as controls and set up.

-or-
use my config tool, as it explains each define for you in simple terms to make customization of my prop much simpler (just watch videos and read through as you go):

5

When I woke up I was pleasantly surprises to find your detailed answers. Obviously this triggered a few more questions:

I would love that. But I found I can right click and get “Open https://…”. Much better than select-copy-paste in browser. What is your version (I have build 4180) & did you do anything in Preferences-Settings ?

So would that be #define ENABLE_ALL_EDIT_MODE ?
Instead of #define ENABLE_ALL_EDIT_OPTIONS ?

But I probably need to add:

#define DYNAMIC_BLADE_DIMMING
#define DYNAMIC_CLASH_THRESHOLD

Any other ? I probably don’t need #define DYNAMIC_BLADE_LENGTH unless I want to check it’s length ?

So I can keep both since I use the saber_fett263.buttons.h prop file ?

Yes exactly, one saber that can do it all - mwhahahahaha (imagine Dr. Claw - from Inspector Gadget - evil laugh :rofl:) . How can I change between props, the dual_prop is if I understand to have blaster or saber (like EZra as you said) with a blade/no blade situation. I would like a bladed saber (when blade is in), a no bladed saber (when blade is out or with baselit blade plug, and be able to switch to blaster (with bullets counter on OLED) or thermal detonator independently of having a blade or not. Is this even possible ? For the thermal detonator it is just a matter on finding/buying/making the right font, I think. But for the blaster ?

Exactly what I thought. I will probably keep the blade plug as baselit, for now at least.

I did get one but it is bigger than the chassis. Is there a small RFID board out there ? Or a magnetic switch sensor would work too. To be honest I don’t really care about the RFID thing, I just would like a way to"use the force" to wake up the saber. But I was told it would be very difficult to adjust the sensitivity of a magnetic switch with a Proffie, unlike on CFX where it is build in the board of some models. That would be my whish for Proffie V4.x :yum:

OH yes, tremendously.

Thank you for your time. Have great day.

No no, the config top section was clear. I was just wondering if BLE_NAME would work with the BT909 module. But since it is a “no”, I will remove that code from my config.

Thanks profezzorn.

Thank you FETT263, that is now next on my “ToDo” list.

7

I’m running 4150, but I have a bunch of packages installed. You can use Package Control to install, or manually download and place in the appropriate user/something/Sublime Text support directory.

I would suggest adding
“Open In Browser”, which is likely what’s giving me that URL behavior.
Also, I highly recommend “BracketHighlighter”, which will make it highlight matching brackets, braces, if/ends … it’s great for checking that there’s a match for each, especially helpful in nested/layered blade styles where you need to see that you are/aren’t missing a closing bracket.

This should be answered by following Fett263’s suggestion of reading the documentation on his prop file.

It’s up to you. DYNAMIC_BLADE_LENGTH will let you adjust blade length “on-the-fly” using an on-saber menu as opposed to a hard coded setting only that is set in the config file’s BladeConfig section.

Any defines that are prop specific will have the name of the prop in it, so NO_REPEAT_RANDOM is a system wide define, while FETT263_… only pertains to options available when using the prop file. So yes, you can use both since they are unrelated.

At the moment, I think only a 2-way switch is available. It would take some additional development to allow for tri-prop use (which is what i think you’re talking about).
It might be easier for now for you to just make a config file for the blaster/saber, one for the thermal D and take 2 minutes to upload the one you want to play with.
As far as fonts go, yes there’s plenty of resources out there for fonts for any of this.

8

That sounds really good, I will look into it. If I get lost, may I ask about over here or is it Off-Topic ?

I believe I found it:
#define FETT263_EDIT_MODE_MENU
Confirm ?

Thanks

I will go the sound font way for the TD

I am trying to compile for “Saber/Blaster with bullets count” combo but I get this error:

In file included from C:\Users\Olivier\Desktop\Lego Manuals\LightSabers\$Oli\ProffieOS_7.14\ProffieOS_7.14.ino:1560:

C:\Users\Olivier\Desktop\Lego Manuals\LightSabers\$Oli\ProffieOS_7.14\config\olicomplex1.3_from-basic4-fett263-Ryryog25.h:459:3: error: conflicting declaration 'DisplayHelper<128, long unsigned int, BaseLayerOp<StandardDisplayController>, ClearRectangleOp<10, 80, 8, 24>, WriteBulletCountOp<10, 20, 5> > display_controller'

  459 | > display_controller;

      |   ^~~~~~~~~~~~~~~~~~

C:\Users\Olivier\Desktop\Lego Manuals\LightSabers\$Oli\ProffieOS_7.14\ProffieOS_7.14.ino:1407:42: note: previous declaration as 'StandardDisplayController<128, long unsigned int> display_controller'

 1407 | StandardDisplayController<128, uint32_t> display_controller;

      |                                          ^~~~~~~~~~~~~~~~~~

In file included from C:\Users\Olivier\Desktop\Lego Manuals\LightSabers\$Oli\ProffieOS_7.14\ProffieOS_7.14.ino:1560:

C:\Users\Olivier\Desktop\Lego Manuals\LightSabers\$Oli\ProffieOS_7.14\config\olicomplex1.3_from-basic4-fett263-Ryryog25.h:460:32: error: redefinition of 'SSD1306Template<128, long unsigned int> display'

  460 | SSD1306Template<128, uint32_t> display(&display_controller);

      |                                ^~~~~~~

C:\Users\Olivier\Desktop\Lego Manuals\LightSabers\$Oli\ProffieOS_7.14\ProffieOS_7.14.ino:1408:52: note: 'SSD1306Template<128, long unsigned int> display' previously declared here

 1408 | SSD1306Template<128, uint32_t, DISPLAY_POWER_PINS> display(&display_controller);

      |                                                    ^~~~~~~

Using library Wire at version 1.0 in folder: C:\Users\Olivier\AppData\Local\Arduino15\packages\proffieboard\hardware\stm32l4\3.6.0\libraries\Wire 

exit status 1

Error compiling for board Proffieboard V3.

And I have in CONFIG_TOP

#define ENABLE_SSD1306
#define BLASTER_SHOTS_UNTIL_EMPTY 20
#define BLASTER_JAM_PERCENTAGE 10

And CONFIG_PROP

#ifdef CONFIG_PROP
#include "../props/dual_prop.h"
#include "../props/saber_fett263_buttons.h"
#include "../props/blaster.h"
#undef PROP_TYPE
#define PROP_TYPE DualProp<SaberFett263Buttons, Blaster>
#endif

Is there anything else I am missing ? My config compiles fine without the CONFIG_BOTTOM section.

9

It’s still relevant to your post here, so inline in this thread is fine I would say.

I really don’t know, it’s whatever his documentation says.

I have notes about this, but never actually played with bullet counts or DisplayHelper stuff. @profezzorn could clarify.
Looks like a re-declatration issue.

10

I highly recommend using the SaberBlasterProp instead of DualProp.
It works mostly the same, but handles translating between fire buttons and power buttons in a reasonably sane way.

For the bullet count error, since you’re declaring your own display, you need to use INCLUDE_SSD1306 instead of ENABLE_SSD1306

11

You’ve mentioned this before, but I’m a little unclear on what you mean.
Those classes are both in the dual_prop.h file. So… what is supposed to happen here now?

#ifdef CONFIG_PROP
#include "../props/dual_prop.h"
#include "../props/saber_fett263_buttons.h"
#include "../props/blaster.h"
#undef PROP_TYPE
#define PROP_TYPE DualProp<SaberFett263Buttons, Blaster>
#endif
12

In the PROP_TYPE define you just use SaberBlasterProp instead of DualProp.

#ifdef CONFIG_PROP
#include "../props/dual_prop.h"
#include "../props/saber_fett263_buttons.h"
#include "../props/blaster.h"
#undef PROP_TYPE
#define PROP_TYPE SaberBlasterProp<SaberFett263Buttons, Blaster>
#endif
13

ah yes, thanks. I do have that. I’ll update the dual_prop.h file to specify that as the preferred way for saber/blaster use. PR incoming.

14

Thanks, I found my way around (so far). For info, I do not like the behavior of “Open In Browser” function, I prefer the right click option. But the “BracketHighlighter” is neat.

With those changes it compiles. Thank you profezzorn.

Question, what is the difference between INCLUDE & ENABLE ?
And with INCLUDE, will the OLED still display “font.bmp” or the name for the preset in Saber mode ?

Talking about preset name, does each preset need a different name or can some/all have the same if I wish ? Say I have more than 1 Luke preset style can I call them all “luke” ?

Would there be any other way than with “BLADE_DETECT” to change from Blaster to Saber or vice-versa, like for example a long push on both Power & Aux buttons simultaneously ? Not that I would know how to code that.

But I want to turn off the NPXL connector if a blade is inserted with
StylePtr<Black>(), but obviously when the blade is removed it will turn off no mater what style is inserted. So if I want to add 50 sound fonts, I still would need to double it for Preset presets[] = {... & Preset no_blade_presets[] = {....

Are those 2 preset names set in stone or may I change them to Preset blade_in_presets[]& Preset blade_out_presets[] ? I have found the original confusing since I first laid eyes on them. And would I need to change something else to rename the 2 ?

Once again, I thank you all for your continuous help.

15

The “name” argument at the end of the preset itself can be anything you want. It is used to display on OLED displays, used in the online ProffieOS Workbench, and in Serial Monitor. Having the same name for different prests is completely fine, albeit possibly a bit confusing to the user, but that’s up to you.

The name you give the Preset arrays is also up to you, it just needs to be the same as what you call with CONFIGARRAY in the BladeConfig blade arrays.

If your only goal is to “turn off” the NPXL connector when a blade is in, then that’s fine, but let me just say that since you can’t see it anyway, and there’s really no drawback to it being on when the blade is IN, it would save a bunch of memory by using only one set of presets for both blade-in and blade-out states, especially if you’re looking to cram 50 presets onto the board.

16

Thank you.

I was thinking about battery consumption, and heat, but maybe they are both negligeable ?

17

It’s that which you put on the other side of the balance scale.
More memory vs negligible battery runtime.

18

I wasn’t seeing it like that. Thanks for enlightening me.

19

In proffieOS, there is a file called display/ssd1306.h. It is the display driver code. In an ideal world, ProffieOS would always include this file, because it doesn’t really do anything, it’s just some extra code for the compiler to read. Unfortunately, the world is not ideal, and including that file causes makes the compiled ProffieOS slightly bigger, even though it doesn’t really do anything.

This is why INCLUDE_SSD1306 exists, which controls whether this file is included or not. Once it is included, it becomes possible to declare a display object, such as the one you have in your config file.

Earlier in the ProffiOS history INCLUDE_SSD1306 was called ENABLE_SSD1306, and the display object was actually declared in ssd1306.h. That worked just fine, because there was really only one way to declare it. However, since the invention of display controllers, which can change what is displayed on the screen, there is now lots of ways to declare a display object.

Nowadays, the display object is declared in ProffieOS.ino, but only if you use ENABLE_SSD1306. If you use INCLUDE_SSD1306, then the file is included, but you will have to declare your own display object in your config file.

Generally speaking, yes. However, it actually depends on how you declare your display object. It’s possible to write a new display controller that doesn’t do that, however, to my knowledge no such display controller exists yet.

They can be the same. It may make using edit mode or the workbench a bit confusing though.

There are lots of ways, but they do all require some coding to do.

You can name them whatever you like, as long as you update your blades[] array accordingly.

1 Like
20

Thank you so much profezzorn for using your to reply to a Padawan like me, I find your knowledge fascinating.

Is it declared with this:

#ifdef CONFIG_BOTTOM
DisplayHelper<128, uint32_t,
    BaseLayerOp<StandardDisplayController>,
    ClearRectangleOp<10, 80, 8, 24>,
    WriteBulletCountOp<10, 20, 5>
> display_controller;
//IfImageOp<OP>     //I don't know what this means ?: "This executes OP if the base layer is showing an image, but not otherwise. 
                    //The idea is that you could have a bullet count that draws over images, but not messages and battery monitors."
SSD1306Template<128, uint32_t> display(&display_controller);
#endif

Or do I need to add something else ?

I will try not to name two the same but I was more thinking about what if I mistakenly name two the same name. And I know “do or do not, there is no try”, yet I will still try until I do.

Could you give me an idea of what way you are thinking ? I would love to learn some basic coding but I have always lacked in the “creating a vision” department. I can create somebody else vision, but I rarely come up with my own (any good ones at least). If that makes any sense.

Done, thanks.

21

Yes, it might nto be super obvious because of the wonky C++ syntax, but this creates two global objects, one called display_controller and one called display. I split it up like this based on the idea that in the future, different presets could use different display controllers.

Well, there is a define in dual_prop.h called DUAL_PROP_CONDITION. It could be replaced with any logical expression that determines which prop to actually use. This could be changed to a variable in the prop (which could then be controlled with button combinations), or anything else, like the variance, the ALT sound number, or even something that changes randomly, but that would be pretty stupid.

I don’t always have the creative vision either, I’m better att expanding the possibilities than actually using the possibilities. :slight_smile: