forked from OpenNeo/impress
Emi Matchu
dc44b4dbb3
Okay right, the wardrobe-2020 app treats `state` as a bit of an override thing, and `pose` is the main canonical field for how a pet looks. We were missing a few pieces here: 1. After loading a pet, we weren't including the `pose` field in the initial query string for the wardrobe URL, but we _were_ including the `state` field, so the outfit would get set up with a conflicting pet state ID vs pose. 2. When saving an outfit, we weren't taking the `state` field into account at all. This could cause the saved outfit to not quite match how it actually looked in-app, because the default pet state for that species/color/pose trio could be different; and regardless, the outfit state would come back with `appearanceId` set to `null`, which wouldn't match the local outfit state, which would trigger an infinite loop. Here, we complete the round-trip of the `state` field, from pet loading to outfit saving to the outfit data that comes back after saving! |
||
|---|---|---|
| .. | ||
| assets | ||
| controllers | ||
| helpers | ||
| javascript | ||
| mailers | ||
| models | ||
| services | ||
| views | ||