Plugin system

[dtugend]

Interface features

Core interface features

• version
• enumerate installed plugins
• state of core and other plugins
• Common runtime info. e.g., path to hlae.exe, dlls and csgo.exe.
• System info. e.g., win7 / win10 / linux (if the core could run)
• Update checking (Something like nskinz's one). Both hlae and plugins
• Undo / redo. History list including all operations of plugins. (oof)
• "Macro. Seems like cfgs but it saves operations of (even different) plugins, then loads."

Plugin interface features

• allow communication between plugins

Game interface features

• Execute commands to csgo console
• After executing certain commands, Get feedback msgs from csgo console (related directly to the command)
• Get msgs from csgo console (general)
• Read and modify engine convars
• Get players' info(i.e. steamid) through Index(0~9)
• Get current demo's filepath
• Get current status of mirv_steams / streams' record settings / voice block settings / deathnotice highlight settings etc...
• Game state, e.g., main menu / demo / match (for live).
• Match state, e.g., demo info / mirv_listentities
• e.g., mirv_pgl. Both raw data and drawing tasks.

Modules/Interfaces of an HLAE plugin (?)

• GUI
• DLLs to be run in HLAE.exe process (64bit) (is this really needed?)
• DLLs to be run in game process (32/64bit, depends on game)
• own processes to be launched with certain parameters?

---

References:

• https://github.com/advancedfx/advancedfx/issues/322#issue-609713211
• https://github.com/advancedfx/advancedfx/issues/322#issuecomment-1463760665

---

• https://docs.rs/wasmtime/latest/wasmtime/
• https://github.com/bkaradzic/bgfx
• https://github.com/grpc-ecosystem/grpc-gateway
• https://crates.io/crates/ipc-channel

---

• CppCon 2016: John Lakos “Advanced Levelization Techniques (part 1 of 3)": https://www.youtube.com/watch?v=QjFpKJ8X
• CppCon 2016: John Lakos “Advanced Levelization Techniques (part 2 of 3)": https://www.youtube.com/watch?v=fzFOLsFASjU

Old notes bellow:

The first interfaces are still in draft, but start to take shape:

• https://github.com/advancedfx/advancedfx/tree/main/interfaces/c

The interfaces will not solve the following problems:

• Package sources and management system for installing / managing the plugins - If you have good ideas for that, let us know. (I would like to make use of https://github.com/features/package-registry, we are in the beta of that).

Important things missing:

• System for modules (nodes) that can be represented in a GUI interface (e.g. https://github.com/Nelarius/imnodes)

[dtugend]

• Observer Pattern
  https://www.reddit.com/r/learnprogramming/comments/ldr8gd/elevated_hookable_destructor_ehd_whats_this/

[dtugend]

@DuKeM-CSGO in response to https://github.com/advancedfx/advancedfx/issues/322#issuecomment-1463760665

If possible please elaborate in this issue on what these mean:

• Game State
  • Engine hooks.
• GUI
  • Receive user input from keyboard, mouse and others. e.g., joystick or touchpad. They should be modifiable for the user.

[DuKeM-CSGO]

1. It's up to developers if engine hooks are needed by plugins. e.g., d3d9 hook was used by me for mirv_stream developing.
2. The issue told that the hard code key binding should be modifiable, but obviously not only for mirv_input but any others. If the gui is only an in-game overlay, it needs input from only keyboard and mouse. But when the gui could display on other devices, such as smartphone, it's necessary to adapt new input way. Joystick is for match living I think.

[dtugend]

@DuKeM-CSGO 2. Do you mean the plugins can react to user interface input to the GUI [e.g. to make shrotcuts]? Or are you talking about plugins being able to spawn own overlay windows / windows and handle events targeted at those windows?

[DuKeM-CSGO]

It's the core's duty to create a window, and handle input events at a low level. Plugins would like to use a higher level interface. e.g., the core receives a "drag" event from mouse. Then my plugin's gui reacts to it, changing the value of a slider. Soon the user can do the same "drag" by touchpad, but my plugin doesn't need to know the event is from a different device. It's not a good idea for plugins to use their own input handler. Especially for plugins in other languages, such as python, it's better to use a generic interface.