[MegaThread] Outstanding issues, fixes and planned improvements

[lili7h]

This thread is for tracking extant or outstanding items which I believe should be broken down and worked on to improve the quality of MAC prior to open beta release

---

Client Backend

• SourceBans/steamhistory.net integration
• auto-updater/auto-poller for reminding users of a new release being available
• Pesky ephemeral bugs:
  • Team assignments sometimes not working
  • New players sometimes not appearing in the UI (as above, likely G15 output parsing failures)
  • Being able to display errors and warnings in the UI (SSE for console output)
  • Surpress output into the console a la TF2BD
• Desired features:
  • Send messages to the player using party chat
  • Absorb additional messages from console to enrich SSE stream
  • A robust and dev-friendly framework for adding additional data sources for enriching player records

Client Frontend

• Display received SSE messagees
• More customisation for layout, colours, schemes (allow font customisation, colour scheme changes for accessibility)
• Get accessibility code scanning with A11y for React
• Pesky bugs
  • Hard-coded timeouts on backend querying causes ephemeral timeouts on delayed networks (i.e. forwarding the client backend via ssh or across large enough networks)
  • Long enough player notes go off screen (no text wrap on display modal)
  • Still no ability to edit player notes from the player history
  • Changing MAC API port in backend will not modify the existing built frontend. Need to find a way to have this self heal transparently

---

Progress

Add fields here or modify existing fields as tasks are picked up and completed

SteamHistory integration

• [x] A preferences item in the client preferences to toggle SourceBan lookups (using steamhistory's API)
• [x] A dispatcher that asynchronously batches and sends API requests for groups of players to the proxied steamhistory.net endpoint that masterbase will host
• [ ] A processer group to read in the response results and append data to the PlayerRecords
• [ ] A cache kind of like the steam user cache to cache SourceBan results in (I think more than 3 hours is fine, since SourceBans is slower, maybe a day? 7 days?) (this is for improving performance)
• [ ] A modification to the API spec to allow the backend to ship this data back to the frontend. The hacky way is to ship it in the customData field for Player Records. Realistically these additions are what the customData field was designed for

And for the frontend, we would need:

• [ ] Modifications to the player objects to house SourceBans information
• [ ] Modifications to the API response handlers to extract SourceBans information from the customData field
• [ ] Modifications to the player information modal to display the SourceBans information

Decisions that need to be made:

• [ ] A concrete specification on how to provide the SourceBans information to the front end. I.e. what format does it appear in the customData field? It has to be JSON, and has to be consistent and well-documented.

Additional SSE messages

• [ ] Additional console regex's for extracting player killbinds
• [ ] Additional console regex's for events that preface joining or leaving servers
• [ ] Additional console regex's for events that preface starting or ending queues
• [ ] Additional console regex's for events that preface leaving or joining parties

[JoshuaVandaele]

Instead of Party Chat to send messages to the player, have Closed Captions been considered?

They can be enabled with closecaption 1; cc_subtitles 1 and a custom lang can be created in the "custom" folder and set to be used with a command such as cc_lang "megaanticheat". Those custom captions can then pushed with cc_emit nameofcaptionkey. This would avoid filling party chat with irrelevant information when they are usually used by players. You can even color the text however you like.

Here's a neat little guide about custom captions.

[megascatterbomb]

That would be a very interesting option. I personally have closed captions disabled; can this be implemented without the stock captions spamming "That heavy is a spy!"?

[JoshuaVandaele]

The stock captions basically do not work for anything other than the developer commentary

Edit: After checking, only the developer commentary is captioned in the entire game

[lili7h]

one thing to consider would be how custom huds affect the display of messages, as well as the default settings.

if CC are turned off by default, whats the best UX for bringing the feature to the user? The less things a user has to manually toggle or flip to install the app, the better.

additionally, how does this affect useability? Closed Captions fade away and are not recallable, what if the information you want to present should be referencable at multiple periods? If something is important enough to notify the user of, is it important enough to also give them persistent access to it?

These are all questions that should be considered.

additionally, would adding a set of closed captions make the cc_random command stop crashing the game? that would be nice

[Bash-09]

I also wonder about if closed captions would be possible to change at runtime or if we would be stuck with a preset list of captions we setup before the game launches. I would guess the cc_lang command would reload the file at runtime, but will that apply in the middle of a game? And hopefully it doesn't cause any disruption to the player when that happens. Some testing would be required.

[JoshuaVandaele]

if CC are turned off by default, whats the best UX for bringing the feature to the user? The less things a user has to manually toggle or flip to install the app, the better.

I think simply toggling them on using rcon is fine

additionally, how does this affect useability? Closed Captions fade away and are not recallable, what if the information you want to present should be referencable at multiple periods? If something is important enough to notify the user of, is it important enough to also give them persistent access to it?

The chat has the same issue, notably with community servers being able to clear the chat using sourcemod plugins, or simply because of spam. I think this kind of information should be made visible in the web interface

additionally, would adding a set of closed captions make the cc_random command stop crashing the game? that would be nice

¯\_(ツ)_/¯

[Bash-09]

Some investigation from Seercat on discord makes the CC approach seem quite promising:

I had a look into TF2 captions stuff based on the recent discussion on GitHub: yes, you can reload captions files at runtime (cc_flush). no, it doesn't seem to cause lag spikes (at least for me). we'd probably want to write our own captions compiler, though, because captioncompiler.exe (or an equivalent binary) doesn't seem to get shipped on Linux. It wouldn't be too hard, there's already one in JS we could look at.

[JoshuaVandaele]

For future reference, the JS one you might be referencing to is this one by p0358, it is also mentioned on the official valvesoftware developer page which leads me to believe it isn't a hacky implementation

[MaxOhNoo]

There are caption mods for all voicelines.

[Tiagoquix]

That would be a very interesting option. I personally have closed captions disabled; can this be implemented without the stock captions spamming "That heavy is a spy!"?

Yes. You do a closecaption file with just what you want (in this case, custom ones), and set cc_captiontrace 0 to avoid spam in the developer console. TF2 accepts custom captions AFAIK, so you can set anything like "MegaAntiCheat_TestPhrase" "This is a test." and it should work. I'm not sure it would support something such as %s1 (to replace with player name) though.