search

phijor / SpecializeMii

Golden Pants for everyone!
GNU General Public License v3.0
27 stars 3 forks source link

Re-enable Sharing when un-specializing Personal Mii #2

Closed XT-8147 closed 7 years ago

XT-8147 commented 7 years ago

I specialized my Personal Mii just to see what would happen. After nothing bad happened, I un-specialized it and made an identical Mii to specialize instead. However, I can't re-enable Sharing on my Personal Mii from within Mii Maker since it still pops up the dialog saying "Sharing cannot be disabled for your Personal Mii".

phijor commented 7 years ago

I see, this is definitely unexpected behavior. What happens is:

  1. Make the Mii special: sharing and copying is turned off so that Mii Maker does not crash.
  2. Un-specialize the Mii: sharing and copying is not re-enabled as the application can not know what the original value for those two attributes was.

If I simply forced share-/copy-ability when un-specializing, that'd be bad for people that do not want their Mii to have either of those attributes.

A possible solution to this dilemma could be to only force share-/copy-ability on a personal Mii.

If you do not mind, could you share your Mii-database with me so that I can try to create the desired behavior? To dump the database to the root of your SD-card, simply hold X when launching the application.

On 17 Jan 2017, at 01:36, XT-8147 notifications@github.com wrote:

I specialized my Personal Mii just to see what would happen. After nothing bad happened, I un-specialized it and made an identical Mii to specialize instead. However, I can't re-enable Sharing on my Personal Mii from within Mii Maker since it still pops up the dialog saying "Sharing cannot be disabled for your Personal Mii".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

phijor commented 7 years ago

I implemented re-enabling sharing when unspecializing your Personal Mii locally, would you mind testing if that fixes your issues?

Below is the precompiled application.

SpecializeMii.zip

XT-8147 commented 7 years ago

I apologize for the lateness of my reply.

I had fixed the issue using JKSM to dump the shared extdata and a somewhat buggy Mii editor I found on GBATemp. For testing purposes, I recreated the issue and tested the build you linked with the following steps:

(Testing environment: old3ds a9lh+Luma, 11.2.0-35U sysNAND, using SpecializeMii as an installed CIA)

  1. Back up my CFL_DB.dat using JKSM (personal mii fixed in this one, sharing flag set, copying flag not set, special flag not set)
  2. Open SpecializeMii (the original build I installed from FBI's TitleDB menu), press A on my personal mii and then select followed by A to make it special
  3. Toggle my personal mii back to non-special, press select then A to make it so, and exit
  4. Open Mii Maker, confirm that my personal mii is not special and does not have the sharing flag set. The copying flag is still not set.
  5. I then installed the test build of SpecializeMii linked above with FBI.
  6. Open the test build of SpecializeMii, toggle my personal mii to special, press select then A, toggle it back from being special, press select then A again, then exit.
  7. Open Mii Maker, and now my personal mii has both the sharing and copying flags set, and is not special.

Looks like it works to me. Personally I don't think the copying flag needs to be set when un-specializing the personal mii, the main issue is that Mii Maker will not toggle the sharing flag for a personal mii. It always pops up a dialog saying that sharing can't be turned off, and even if sharing is already off, it doesn't re-enable it.

One thing I noticed while recreating the issue (should I open a separate issue for this?) is that the confirmation on making your personal mii special checks to see if I'm pressing A while I still have A pressed originally, from trying to make it special. The confirmation ever so briefly flashes up on screen before going away (since pressing A confirms it). This is also present in the test build that you linked. I can get the confirmation to stay on screen by very quickly pressing and releasing A, but ideally the confirmation should either wait for the A button to be released and re-pressed, or use a different button.

Thanks for looking into this. I've done work in support before, hence the thorough documentation of my process. Though it doesn't seem necessary now, I can still generate a CFL_DB.dat that contains the issue if it's needed.

phijor commented 7 years ago

Thank you very much, that was very detailed and confirmed what I assumed to be the bug.

I will not force the copy-flag if it does not seem to be necessary (as you pointed out). Otherwise, this seems to be ready for a bug-fix release. Thanks again!

If you could open a seperate issue for the prompt not displaying properly, that'd be nice of you.

PS: I you confirmed the test build to be working, I won't need your CFL_DB.dat anymore.