Module state 

Handling of state of SC2 Replay as it steps through game loops

Events are ordered by their “priority”, this is a guessed priority for now. For example, if a TrackerEvent and a GameEvent, happen at the same game loop, the tracker events take priority (See the const below). This may not be true but seems to work so far. In this version, the game_loop will be multiplied by 10 and added the priority. This means 10 max events types are supported.

Re-exports

pub use unit_cmd::*;

pub use unit_props::*;

Modules

unit_cmd

The unit may have a command triggered. This can be pointing to a target, casting an ability, etc.

unit_props

Structs

SC2EventIterator

The iterator that returns the events as they happen.

SC2EventIteratorItem

SC2ReplayState

The state of the replay as it’s being processed, units are added to owners, control groups are updated, unit position recorded, etc.

SC2Unit

Unit Attributes, this changes through time as the state machine overwrites the values.

SC2UserState

The user state as it’s collected through time.

Enums

SC2EventType

Supported event types.

UnitChangeHint

When a unit changes in the state, certain information is provided back. For example, if the unit dies, it is deleted from the state, but all its information is returned back for reporting purposes.

Constants

ACTIVE_UNITS_GROUP_IDX

The currently selected units is stored as a group outside of the boundaries of the usable groups.

GAME_PRIORITY

TRACKER_PRIORITY

TRACKER_SPEED_RATIO

The game event loops and tracker event loops differ in their units. The true ratio should be identified somehow. There seems to be a ratio and the ratio based on initial calculations seems to be: