Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate Memory Core from Diaper #71

Open
DoomRater opened this issue Aug 27, 2015 · 3 comments
Open

Separate Memory Core from Diaper #71

DoomRater opened this issue Aug 27, 2015 · 3 comments
Assignees

Comments

@DoomRater
Copy link
Owner

A lot of settings migration issues stem from the fact the memory core is essentially attached to the diaper. In reality, the diaper already keeps track of all the necessary values and doesn't need the core except as a backup for when it needs to be reset (which should be very rarely now). The core could conveniently be worn as a seprate object or even as a HUD although that would increase listen traffic. At the same time, it would make updating the diaper as simple as getting the latest one, and never having to worry about settings migration again.

If there's an overhaul that I should do, it's this.

@DoomRater
Copy link
Owner Author

PReliminary work on separating the memory core from the diaper is done. They still need to communicate with each other.
-if the diaper is worn first, it tries to poke the HUD about settings. If the HUD is put on second, it should try to send settings to the diaper once it is attached. The diaper shouldn't send settings to the HUD unless the user wants to send them.

@DoomRater
Copy link
Owner Author

I have only one idea on how to accomplish only sending to the HUD AFTER the HUD has synced its data with the diaper. I'd set the diaper to never send any settings until it has first heard from a HUD since last rez. This is to prevent the HUD from being overwritten at launch time with a status change right off the bat.

Additionally, perhaps the diaper should be set to off by default on reset. That would ensure the diaper doesn't send any status messages when it's brand new. Aside from that, I don't have any other "how I want it to behave" descriptions or "how I intend to achieve" descriptions.

@DoomRater DoomRater self-assigned this Aug 30, 2015
@DoomRater
Copy link
Owner Author

I have a new problem, and this one has hung me up on further development. Because the HUD and diaper are two separate objects, and technically the HUD is needed to save data long term or between diapers, I need a way for users of the original Fluffems to receive this HUD when they update their diapers. As many settings issues as this enchantment solves, it creates a distribution problem- do I update my marketplace listings to the latest version, and box everything... or do I deploy the latest version of the diaper, with a notice that users should request a HUD as well?

Until now I've been able to simply deploy a new version of the diaper and everyone just gets that diaper. Because of the HUD I'm unsure how to go about this. The closest thing I can think of is to add the HUD to the diaper and allow the users to get a basic HUD from the diaper itself... and continue that trend until all the oldest Fluffems are out of circulation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant