Allow saveload to serialize/deserialize more than 8 component types

[andreivasiliu]

I'm not sure if I'm doing something horribly wrong or commendably right, but I've hit the size limit of tuples that implement the SerializeComponents/DeserializeComponents traits, which is currently 8 component types.

This will not compile:

 SerializeComponents::<Error, U64Marker>::serialize(
            &(positions, sizes, shapes, rooms, in_rooms, player_controllers, velocities,
              forces, aims, collision_sets, revolute_joints, jumps, animations),
            &entities,
            &markers,
            &mut serializer
        )

I think the proper solution here would be to implement SerializeComponents for any structure with #[derive(SystemData)], but I don't know enough Rust to figure out how to do it myself.

Short-term I'd be happy with increasing the tuple size limit too.

[zakarumych]

I'd add another custom derive (SerializeComponents, DeserializeComponents) instead of implementing everything in one.
I've being playing with custom derive lately so I think I could do it.

[torkleyy]

@WaDelma @Xaeroxe Do you think we should add another custom derive?

[AnneKitsune]

Hi. Is this still an issue?

[andreivasiliu]

I'm still using tuples, and have to modify 6 different places whenever adding a new component (declaration+parameter+tuple for both serialization+deserialization), since I couldn't figure out how to implement SerializeComponents:
https://github.com/andreivasiliu/stacked-worlds/blob/master/src/saveload.rs#L46-L48

Documenting an example of SerializeComponents implementation or adding an automatic derive for it would help.

My biggest issue (the limit of 8, as per the issue title) was fixed though, so feel free to close this; I assume the saveload module will eventually get better documentation/examples even without this issue.

[expenses]

@andreivasiliu you can bring that down to 2 if you change it to

type SystemData = (
        Entities<'a>,
        (
                ReadStorage<'a, Position>,
                ...
        ),
        ReadStorage<'a, U64Marker>,
    );

    fn run(&mut self, (entities, components, markers): Self::SystemData)
    {
        let mut serializer = ron::ser::Serializer::new(Some(Default::default()), true);
        SerializeComponents::<Error, U64Marker>::serialize(
            &components,
            &entities,
            &markers,
            &mut serializer
        ).unwrap_or_else(|e| {
            // FIXME: handle this
            eprintln!("Error: {}", e);
});

or equivalent.

[torkleyy]

I think this is a huge usability issue in saveload that should be addressed before stabilizing it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Feel free to comment if this is still relevant.

[abesto]

I've just run into this, except at 18 instead of 8 now. I understand I can manually implement SerializeComponents and DeserializeComponents, but it feels like I shouldn't have to (this is purely boilerplate). Re-opening this issue would be nice to make sure it doesn't get lost (or a separate issue I guess tracking custom derive macros, or however you think it's best to approach this)

[rodya-mirov]

Any progress on this? For whatever reason I seem to be hitting the limit at 16, rather than 18 as @abesto said. But I'm not sure how else to deal with this.

[abesto]

FWIW, for now I managed to work around this relatively painlessly by splitting up the component tuples, and calling the de/serializer for each (DRY via macros): save load

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Feel free to comment if this is still relevant.

[WaDelma]

bump

[ytaras]

I've created draft of derivation macro as an exercise for learning Rust macros. Probably there's a lot of bugs, but feel free to copy and use it.
https://gist.github.com/ytaras/042c40adc8e29f30302d709df7e1d067