feat: query for info only from ticks that satisfy specific prop states conditions

[dankotov]

bar the translation of user input into PropInfo vector

[LaihoE]

looks good so far, check discord for some more info

[dankotov]

@LaihoE tested to work with basic condition like

let wanted_props = vec!["X".to_string()];
let mut wanted_prop_states: AHashMap<String, Variant> = AHashMap::new();
wanted_prop_states.insert(
    "CCSGameRulesProxy.CCSGameRules.m_bBombPlanted".to_string(),
    Variant::Bool(false),
);

let huf = create_huffman_lookup_table();
let settings = ParserInputs {
    wanted_players: vec![],
    real_name_to_og_name: AHashMap::default(),
    wanted_player_props: wanted_props.clone(),
    wanted_events: vec![],
    wanted_other_props: vec![],
    parse_ents: true,
    wanted_ticks: vec![],
    parse_projectiles: true,
    only_header: false,
    count_props: false,
    only_convars: false,
    huffman_lookup_table: &huf,
    order_by_steamid: false,
    wanted_prop_states: wanted_prop_states,
};
let mut ds = Parser::new(settings, ParsingMode::Normal);
let file = File::open(path_to_demo).unwrap();
let mmap = unsafe { MmapOptions::new().map(&file).unwrap() };
let _output = ds.parse_demo(&mmap).unwrap();

[LaihoE]

Sorry for the late reply.

Yes prop_controller is some horrible code that needs to be refactored. And very much true that the if statements were already getting quite ridiculous, and now double the amount is maybe a little too much. If you want to try to simplify it then that would be great.

As for "is_player_prop" it is used in game events for something. I think it is to know where to look for the value (from the perspective of the player or something i don't quite remember) but maybe this could also be implemented in some other way.

[dankotov]

@LaihoE no worries on the late reply

Yeah, I can refactor those if statements. I just have a few more questions to better understand the set_custom_propinfos function.

If I interpret it correctly, it sets PropInfo for A) Buttons B) Ticks, SteamID, Name C) Props that are of type PropType::Custom. The reason for it setting those separately is because those props have specific unique ids. The A and B part I think are fine, the wealth of the code is caused by C. I see that there is a TYPEHM map in maps.rs which maps prop string names to corresponding PropType. My initial idea was to retrieve all keys from that map, for which the value is PropType::Custom, and iterate over the keys, and doing the if check for each key. However, I noticed that not all prop names referenced in the if statements were present in TYPEHM, for example velocity_X/Y/Z or weapon_skin(_id). Is that by design? Or were they just missed accidentally? If I could add the missing prop names to TYPEHM I think this refactor would be elegant and quick.

As for the is_player_prop, at the moment, I believe, whether a prop is a player prop is derived by which parser input array it was put into by the end user - wanted_player_props or wanted_other_props. Is there a reason why we dont hardcode (using some kind of a map, perhaps just a name to boolean) to whether a prop is a player prop or not?

[LaihoE]

You can just add all the A) Buttons B) Ticks, SteamID, Name C) as PropType::Custom 👍

You are probably right about the is_player_prop. I don't really remember much about its role.

[LaihoE]

Are we ready to merge?

[dankotov]

Not yet. Need to add 1 more Rust test case and JS bindings.

[dankotov]

^ Had to remove other wanted states as querying for prop states while parsing event(s) not yet implemented and "other" props do not work when parsing ticks.

Will probably implement querying for prop states while parsing event(s) in another PR down the line.

[LaihoE]

LGTM. Will create a new release soon.