`EntityExtraData` of incorrect type when ambiguous

[redruin1]

Suppose we have a blueprint with a single lamp with a circuit condition:

0eNptUMtqwzAQ/Jc9yyFOolDpUMh3lGJke9su6GGktakx+vdKDsSXHmeY1+4GvZ1xiuQZ9AY0BJ9Af2yQ6NsbWzlvHIKG5Iy1jTVugiyA/Ii/oNv8KQA9ExM+fTtYOz+7HmMRiH/8AqaQiiX4ml9j7teTFLCCblp5OclSUIZwDLbr8ccsFGJVDhSHmbhDb3qLI2iOM4oXXSzjK/WLYuLuuILXqa5YKPJcmGPWrmge8OxMbOonzhW4yUTDtRreIed6KjG6Ao+fCVgwpr1T3i/qppR8a69KnW85/wEk0HVl

I would expect the following:

for entity in blueprint.entities {
    match entity.name.as_str() {
        "small-lamp" => {
            if let Some(data) = &entity.extra_data {
                println!("{:?}", data)
            }
        },
        _ => ()
    }
}

to produce a struct of type EntityExtraData::Lamp, but it actually produces:

AgriculturalTower { control_behavior: AgriculturalTowerControlBehavior { read_contents: false, common: CommonControlBehavior { circuit_enabled: true, circuit_condition: Some(Constant { comparator: Greater, first_signal: Some(Virtual { name: Some(VirtualSignalID("signal-check")), quality: None }), constant: 0 }), connect_to_logistic_network: false, logistic_condition: None } } }

I think it's picking the first valid one that it could be, which happens to be the first agri tower struct. If I'm doing this wrong, lemme know.

[fgardt]

Yeah there is just not enough information to properly discern between variants in some situations.

I think it's picking the first valid one that it could be, which happens to be the first agri tower struct. If I'm doing this wrong, lemme know.

Yes that is exactly what is happening. The fact that a lot of fields end up being Options makes this worse because there are only a few fields that would uniquely identify any given variant.

Is that the exact BP string for the given printed output? Because if so then something deserialized incorrectly for the virtual signal (BP string is virtual signal signal-A while the printed output is signal-check).

Thinking about it there could be a helper function to convert different EntityExtraData variants between each other so you could at least correct it to the expected form manually (or even in a smart way by using type info from a prototype dump).

[redruin1]

Is that the exact BP string for the given printed output?

No, this is a manufactured example; the issue arose when working on something quite a bit more complex (somebody is doing another attempt at converting verilog to combinators), so I boiled it down to what seemed to be the minre.

Thinking about it there could be a helper function to convert different EntityExtraData variants between each other so you could at least correct it to the expected form manually (or even in a smart way by using type info from a prototype dump).

This would be the solution I think. It may be possible for blueprint to get really smart here and use the prototype dump + entity name to figure out exactly what variant it should use, but what would be really convenient right now (and probably quite a bit easier to implement) would be a mechanism to "cast" the AgriculturalTower data to the Lamp variant since I assert that this must be the correct form.

I don't know enough about Rust to suggest ways on how to actually go about this though... implement the TryInto trait for each variant of ExtraEntityData, maybe using a macro to reduce boilerplate?