Skip to content

Conversation

@elliethepink
Copy link

Additional slots were not getting added when the local wardrobe was enabled, so player that didn't already have local wardrobe data saved wouldn't get any extra wardrobe slots. loadExtendedWardrobe calls WardrobeFixLength() to add the new slots but loadLocalWardrobe doesn't. I've added it to settings in the same place that the wardrobe size is adjusted for the local wardrobe, although for extended wardrobes this is all done in loadExtendedWardrobe.

@netlify
Copy link

netlify bot commented May 7, 2025

Deploy Preview for wce ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit 5f489b8
🔍 Latest deploy log https://app.netlify.com/sites/wce/deploys/681b33626a9cb000083aa8e7
😎 Deploy Preview https://deploy-preview-90--wce.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@KittenApps
Copy link
Owner

KittenApps commented May 7, 2025

Having localWardrobe enabled requires the extendedWardrobe to be enabled, so we already are guaranteed to call WardrobeFixLength() once. Calling it a second time is completly unnecessary.

Additional slots were not getting added when the local wardrobe was enabled, so player that didn't already have local wardrobe data saved wouldn't get any extra wardrobe slots.

That's not true. I've just confirmed, that it works correctly.

@KittenApps
Copy link
Owner

KittenApps commented May 7, 2025

This issue might be about Player.WardrobeCharacterNames instead?

Nope, seems to work correctly too.

If there should be a bug, please report it with proper repdrocutions steps. This is at least not the correct fix and seems to 'fix' a non-issue.

@elliethepink
Copy link
Author

Indeed, but the localWardrobe settings side effect code is called after the one for extendedWardrobe so although the WardrobeSize variable gets set correctly, the length of Player.Wardrobe doesn't get fixed to match because WardrobeSize is still 96 when WardrobeFixLength() is run.

I found this after investigating why someone still only had 96 slots even after enabling the local wardrobe option.

Repro steps:

  1. Make sure you're in a browser environment with no wce-local-wardrobe data in IndexedDB
  2. Log in to bc
  3. Enable both 'extended wardrobe' and 'local wardrobe' options in WCE settings
  4. Go into your bc wardrobe, go back a page, see that the last slot on the page is 96

This is testing on chrome.

How are you testing? Is it possible you already have local wardrobe data set? It works fine in this case as the wardrobe data is loaded with the right number of slots, effectively.

@KittenApps
Copy link
Owner

KittenApps commented May 7, 2025

The only thing slightly fragile about the legacy settings code is, that the side effect handling assumes that Object.entries() will return them in the specified order, so that extendedWardrobe side effect is always called before the one from localWardrobe and I'm not sure if this is even garunteed by spec, even though it hold for all common JavaScript engines. It would be interesting to know if there are some exotic JavaScript engines out there, which doesn't fullfil that assumtion.

https://github.com/KittenApps/WCE/blob/beta/src/util/settings.ts#L946-L962

@elliethepink
Copy link
Author

Ah, if it's reliant on iteration order, this will be insertion order in this case, ie. order they appear in the JSON: probably how the settings have been saved rather than javascript engine differences. That might explain the difference. For all my accounts / test accounts I've looked at, extendedWardrobe appears before localWardrobe which would explain why it's not working for me. Possibly for you they are the other way around somehow?

I only started looking at this because someone reported their extra local wardrobe slots weren't appearing, and then I noticed the option didn't work for me either, so this is definitely a problem in practice (I got them to run WardrobeFixLength() manually which got their slots back).

I've reproduced the same problem on a completely fresh browser environment and new BC account. So, new repro steps:

  1. Open a new, fresh browser profile / private window (I'm using chrome 136)
  2. Go to https://www.bondageprojects.com/R115/
  3. Go to https://sidiousious.gitlab.io/bc-addon-loader/ and copy the "Manual bookmark loader" link location
  4. Go back to the BC tab and paste into the url bar, add the 'javascript:' at the start of the text and press enter
  5. Press the 'Addon Manager' button
  6. Under 'WCE', change to 'stable', press save
  7. Create a fresh BC account, click through the intro screens
  8. Obtain enough money to buy private room and wardrobe, go into private room, buy both
  9. Go to player profile / settings / extension settings / WCE / Appearance & Wardrobe
  10. Enable extended wardrobe
  11. Now that local wardrobe is enabled, enable that too
  12. Exit settings, go to Change Appearance, click Wardrobe
  13. Click left arrow to go back a page
  14. Observe last slot is 96
  15. Optionally, reload and open wardrobe again, still see 96 slots

If you'd rather fix this a different way, eg. run WardrobeFixLength() just once after applying the settings if any of the wardrobe settings are enabled, that's totally fine. I just thought I would offer this fix since I'd already found the bug by that point and it seemed like a simple enough fix (ie. it seems logical to me to always run the function to fix up the length of the wardrobe length after modifying WardrobeSize).

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants