Gearing up for OS8

The talk of switchable mass storage access has reminded me of something I think I mooted once before which is to have a command, accessible via the prop, to delete all temporary files (.tmp and .ini) from the SD card. In other words to restore ‘factory’ defaults just using the buttons.

I think this would be a useful feature for OS-8, particularly as prop files become more powerful making it easier for new users to inadvertently tie themselves in a knot. Rightly or wrongly, there are quite a few saber chassis out there where USB port and SD card access is very fiddly, so this would be a big help for those users.

I realise this is as much a prop file thing as anything else, but I’m assuming some part of the OS will need a little extra coding in order for there to be a command that does this action for the prop file to access.

Just an idea.
:slight_smile:

This is the default for my prop, so would I need to do anything to enable it or is it already in prop_base?

The FONT_PATTERN define is controlled by the user, not the prop.

There are use cases where people could benefit from using font paths different from "*;common" and today those use cases are not compatible with edit mode. The idea with FONT_PATTERN is to make edit mode smarter so that it can create and decode font paths even if they aren’t in the "*;common" format.

I think some “reset” menu options might be helpful.
In particular for presets.ini, where putting things back can be a lot of work.
I don’t know if a “reset everything” option is required though, the other settings are much easier to deal with…

1 Like

3 posts were merged into an existing topic: Saved Twists

So what would the usage for this look like, from a user standpoint, assuming it gets fully implemented?

I’m trying to keep up with all the new features so I’m up to date, and this sounds like it could be a game-changer.

You just add this to CONFIG_TOP

#define FONT_PATTERN "override;*;common"

And then when you specify your presets you follow that pattern. (Or whatever pattern you put in there.)

1 Like

I’m going to change it from “set_allow_mount” to just “sd”.

“sd 0” → disable mount
“sd 1” → enable mount
“sd” → prints 1 if mount is enabled, 0 otherwise

2 Likes

@Fett263 I was thinking the other day it would be a fun thing for OS8 to have the prop where you can disable Special Abilities on-the-fly the way you can disable gesture controls. Just hold pwr+clash and if someone other than you tries to make the saber go into say PartyMode, you can just say

The Force doesn’t grant you the ability to party?:rofl:

Not in my plans and not something I would want or use. Special Abilities are already highly customizable at the preset level.

Got ya. Had to ask. I’ll definitely have to explore this because it looks like it’s not entirely a “gesture control” since it’s a button and gesture action. Time to dig into the “How-To” again. :smiley:

I’ve cooked something up in my prop.
Is it ok if we make DetectTwist() a bool?

6 posts were split to a new topic: Saved Twists

Not finding the simplest case simplest at all.
Is there reference for what to call and the syntax?
Like, ToggleColorChangeMode() is handled in prop_base already. So if I need to make a function in my prop like

#ifndef CHANGE_BLADE_LENGTH_MENU_SPEC_TEMPLATE
#define CHANGE_BLADE_LENGTH_MENU_SPEC_TEMPLATE mode::SettingsMenuMode
#endif
virtual void ToggleBladeLengthMode() {
  if (!current_style()) return;
  if (current_mode == this) {
    pushMode<MKSPEC<mode::SettingsMenuMode>::ChangeBladeLengthMode>();
  }
}

I’m having a hell of a time for some reason getting this error

error: 'ChangeBladeLengthMode' is not a member of 'MKSPEC<mode::SettingsMenuMode>'

I think I really don’t get it, am way over thinking this, or both.

This is what it looks like in the saber prop:

That should be all that is required unless you want to customize.

Yours looks like you’re trying to jump directly to a specific menu.
However, “mode::SettingsMenuMode” is not a spec template.
Something like this could work:

 pushMode<MKSPEC<MENU_SPEC_TEMPLATE>::ChangeBladeLengthMode>();

The assumption here is that the user will define which spec to use, like:

#define MENU_SPEC_TEMPLATE DefaultMenuSpec
// or
#define MENUS_SPEC_TEMPLATE SettingsOnlyMenuSpec

I guess this mode needs to be used when ON, huh?

No, it’s intended to be used when OFF.

At some point I’m going to have to document the menu system I’m creating.
Here is a beginning:

g TopMenu Top Menu Edit Presets Settings Settings Settings Volume SD Access Dimming Clash Threshold Blade Length TopMenu:s->Settings:top Edit Preset Edit Preset Select Font SelectTrack Edit Style 1 Edit Style 2 Edit Style 3 Move Preset up Move Preset Down Select Preset Insert Preset Delete Preset TopMenu:ep->Edit Preset:top Edit Style Edit Style Style Settings Select Style Apply Colors Apply Settings Reset Change Style Edit Preset:style1->Edit Style:top Edit Preset:style2->Edit Style:top Edit Preset:style3->Edit Style:top Style Settings Style Settings Base Color Alt Color Arg Style Option Arg Ignition Option Arg Ignition Time Arg ... Edit Style:args->Style Settings:top Color Menu Color Menu Edit Hue Edit Brightness Adjust Red Adjust Green Adjust Blue Select Color Use Selected Reset Color Save Style Settings:col->Color Menu:top Style Settings:aca->Color Menu:top

Note that the leaf nodes are omitted, so most (but not all) of these options actually lead to a sub-mode which lets you select or adjust something, which you then have to use “select” or “exit” to get back out of once you’re done.

I’m not fantastic at usability, so if people have ideas/suggestions/comments for how these things should be organized, please let me know.

2 Likes

I just fired up the full menu for the first time. Should we make a thread for it? I don’t think blade length is working for example and don’t want to hijack this general OS8 “ideas” based thread.

Seems like a good idea. I was going to start one once I had tested everything at least once anyways.

Right now I’ve probably tested about 80% of the menus, and I’ve found bugs in almost every single one so far, that means there are a bunch of bugs left, and that’s not counting the bugs that I missed.