-
Notifications
You must be signed in to change notification settings - Fork 32
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
Update YAML Version and Cargo Update #190
Conversation
up: !SingleAxis | ||
axis_type: !Gamepad LeftStickY | ||
positive_low: 0.1 | ||
negative_low: -1.0 | ||
|
||
left: !SingleAxis | ||
axis_type: !Gamepad LeftStickX | ||
positive_low: 1.0 | ||
negative_low: -0.1 | ||
|
||
down: !SingleAxis | ||
axis_type: !Gamepad LeftStickY | ||
positive_low: 1.0 | ||
negative_low: -0.1 | ||
|
||
right: !SingleAxis | ||
axis_type: !Gamepad LeftStickX | ||
positive_low: 0.1 | ||
negative_low: -1.0 | ||
flop_attack: !GamepadButton South | ||
shoot: !GamepadButton East | ||
throw: !GamepadButton West |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also less lines which is nice 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, overall seems nice.
fn deserialize_range_from_array<'de, D>(de: D) -> Result<Range<usize>, D::Error> | ||
where | ||
D: Deserializer<'de>, | ||
{ | ||
de.deserialize_tuple(2, RangeVisitor) | ||
} | ||
|
||
struct RangeVisitor; | ||
|
||
impl<'de> serde::de::Visitor<'de> for RangeVisitor { | ||
type Value = Range<usize>; | ||
|
||
fn expecting(&self, formatter: &mut std::fmt::Formatter) -> std::fmt::Result { | ||
formatter.write_str("A sequence of 2 integers") | ||
} | ||
|
||
fn visit_seq<A>(self, mut seq: A) -> Result<Self::Value, A::Error> | ||
where | ||
A: SeqAccess<'de>, | ||
{ | ||
let start: usize = if let Some(start) = seq.next_element()? { | ||
start | ||
} else { | ||
return Err(serde::de::Error::invalid_length( | ||
0, | ||
&"a sequence with a length of 2", | ||
)); | ||
}; | ||
let end: usize = if let Some(end) = seq.next_element()? { | ||
end | ||
} else { | ||
return Err(serde::de::Error::invalid_length( | ||
1, | ||
&"a sequence with a length of 2", | ||
)); | ||
}; | ||
|
||
Ok(start..end) | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reminds me of something I was wondering about before, which is not entirely relevant here, but I wonder if we can implement clips/animations which play a non-contiguous array of frame indexes. I had a usecase for it before when I was adding a waiting state and it didnt really match any of the available animation frames, but I'm not sure if that would be a good design. It would let us piece together frames from a spritesheet to make "ad-hoc" animations of the correct length, or skip frames in the middle of an animation if we needed to. The more I write it out the more janky it sounds though so maybe this is not a good idea 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could make sense. It would essentially be an array of ranges, which might not be bad.
Some of the exact details of the syntax become less important with an editor, too, so if it was a useful feature and we could make a good interface for it, it seems like it might be good to include. ( Not in this PR )
We good to merge this then? |
bors r+ |
@zicklag this broke level loading, getting past Main Menu panics reverting for now. |
Ah, I forgot about that. The issue is that the format for the local storage file changed with the new YAML format. You just have to delete the storage YAML file and start the game again and you'll be good. On linux the file is This does bring up something we need to figure out. How do we gracefully fail when the YAML format changes or is otherwise corrupted and we can't read it? I think the best option is to move the old storage file to I don't really like that behavior in general, but at least while the game is unstable I feel like it makes sense. |
Ohh interesting, so then it wasn't really broken? I didn't think of the locally stored settings causing the issue. |
I'll just open another PR that un-reverts it with an extra commit to provide a non-panicky fallback on failure to deserialize the save data. I'm thinking the simplest solution is best for now and I'll just delete the save data if it fails to deserialize. We can re-visit when we have save data that's important, but I don't think we really have to worry about a user losing their hard-earned progress right now because there's no progress to earn. 😁 Even if there was, they could just edit the YAML of their own save data. |
This updates the last dep we had out of date,
serde_yaml
, which uses a new syntax for enum tags:Before:
After:
It's a little different than I'm used to. I didn't know YAML had tags, I think it might be a YAML 2.0 feature or something, but I what I do like is that it fixes the inconsistency of using
snake_case
for all of the keys ( leafwing input didn't rename the fields to use snake case like we did ). Since enum tags are now using the!
syntax and that feels a little bit more consistent and valid to have them use the CamelCase for the tags.Another note is that I had to add a custom deserialize implementation for keeping our
[start_frame, end_frame]
syntax for animation clip ranges. Serde deserialize implementations are a little verbose, but it didn't turn out that bad.