kendallroth / cs2-city-stats Goto Github PK

Statistic values should be displayed, either in the tooltip or under/beside the icon (depending on orientation). This may require some tweaking to the values themselves, as some currently apply "caps" for display purposes.

Using vertical orientation for the panel could run into vertical spacing issues on smaller screens. An alternative approach would be to support two columns (via Settings), either for vertical mode only or maybe also for horizontal mode?

Add a keybinding (with settings UI) for toggling stats panel visibility.

The various city warning icons (ie. above buildings, etc) could be added in a second row (toggleable via settings). Warnings would only display if present in city, and would include the icon and the number of occurrences. Ideally clicking on a warning would navigate to the location of the first such event.

See Notification list

Inspired by #2, the panel visibility and position should be persisted within a save game. This will require storing the values in a serializable entity (or component?) in ECS, that could then be automatically persisted to the game save. However, this depends on whether there is actually value to this, as compared to other options...

• Add a setting to toggle whether panel is open or not when loading any save game ✔️ (implemented)
  • Definitely easiest, might also offer enough value to skip the other options?
  • Probably not necessary if choosing either of the other options, although could be then treated as a default for new saves
• Persist panel visibility/position "globally" (ie. across saves) via writing to ModSettings/
  • Most people will probably keep the panel in the same location across their saves
  • Potential (minor) downside would be forcing the same visibility state across saves
• Persist panel visibility/position within individual saves via entity serialization ⚠️ (likely unnecessary)
  • Definitely most complex (due to limited knowledge of ECS), but also most flexible
  • Not sure whether it would provide enough "benefit" to justify the development though???

System docs

krzychu124: for panel position, I suggest storing it on C# side, value binding to read, calling a trigger from UI with new value when position has changed. Serialize in UI system entity component, when deserializing, validate with current screen resolution, reset if out of bounds.
reset will be trivial since it will just overwrite value of the binding that UI is reading
panel visibility can be done similar way

PoliteCanadian: To modify data in a save game, would I simply persist it within a registered entity component ("simply" is probably an oversimplification, but it does make sense that the game entities would be persisted somewhere in each save game 🤦‍♂️ )

krzychu124: when a component or system implements ISerializable interface (sometimes needs a few more) it will be automatically picked up by serialization system and processed as any other savegame data
here example from Traffic mod, the system, besides running a job you can ignore, is saving and restoring a version number when the game is serializing or deserializing the savegame data. It's fairly straightforward.
https://github.com/krzychu124/Traffic/blob/main/Code/Systems/DataMigration/TrafficDataMigrationSystem.cs
so you just need IDefaultSerializable, ISerializable three methods from the bottom of the file and a field or fields to store the data which should be serialize

Add a panel "scaling" option (via Settings) that would allow shrinking/expanding the panel stats (likely uniformly, perhaps via scale in CSS). The setting should have a lower/upper cap to prevent unreasonable scaling.

Currently the suggested game version is 1.0.*, which causes some installers to think it does not work with a specific version. This version should be bumped to 1.1.* to resolve this.

Currently the panel does not persist its visibility or position, which causes it to reset whenever the main game UI is hidden (ie. reloading, escape menu, etc). The panel visibility and position should be persisted and loaded automatically when the mod mounts in the UI.

This probably should come along with a settings UI for resetting position/visibility (in case it disappears).

With the current issues with homelessness, it could be nice to show a homeless count/percentage. However, this data is not currently exposed to the UI, and may not even be calculated behind the scenes? Once implemented, the displayed value will also need to be determined, as a percentage of entire population may not be super beneficial at massive populations (then again, it is a very similar idea to unemployment, and could benefit from #16).

This will require some additional ECS work, particularly with Queries, but may also require a Job (depending on approach).

Note that unemployment does not necessarily indicate homeless (due to temporary unemployment allowance), but might help pare down list of citizens?

There are several mods that are already calculating this, including ByeByeHomeless and CimCensus. However, both of these mods seem a little bit overkill for simply calculating the number of homeless in the city, but they may be the only viable options...

Should be possible to choose what stats to display (all displayed by default). This could be implemented in "Settings," but would take a lot of boilerplate at the benefit of a pre-built UI. Alternatively, could implement an additional/custom UI that stores data in ModsData (handling if not present/invalid).

Some icons do not need to be enabled (or maybe even displayed, although that might be confusing) until they have been unlocked. This could maybe be detected somehow from progression, but maybe using the Infopanel UI data may suffice? The infoviews$ binding exposes a list of infoviews that have a locked property, which could maybe work?

Clicking on an icon should open the corresponding info view (see forum post for original request). It may be beneficial to only open if no other tool is selected (other than default empty tool), although this could maybe be a setting?

The bindings.d.ts file suggests that this might be possible using a combination of the JS bindings.

function toggleInfoviewMenu(): void;
function useInfoviewToggle(infoviewId: string): (() => void) | undefined;

// May be helpful for figuring out what infoview IDs are (contained in `Infoview.id`)
const infoviews$: ValueBinding<Infoview[]>;
const activeInfoview$: ValueBinding<ActiveInfoview | null>;

// Not sure how these differ from the previous functions, nor how the "entity" would be retrieved for them?
function setActiveInfoview(entity: Entity): void;
function clearActiveInfoview(): void;

export interface Infoview {
  entity: Entity;
  id: string;
  icon: string | null;
  locked: boolean;
  uiTag: string;
  group: number;
  requirements: UnlockingRequirements;
}

Currently the panel automatically displays under its button. It would make more sense to display centered along the top of the monitor (unless position is persisted otherwise).

Add the ability to change between horizontal and vertical display modes, for those who wish to anchor vertically at the side of the screen.