old project, recoded now and uses dynamic states
Inject to the game, preferably before level loading since capturing some names is done at this stage.
Although not a MUST...
I am not responsible for any potential bans caused by injection, dirty screens and etc...
- Edit whole VisualEnvironment + force its states
- Edit WorldRenderSettings
- Capture entities on runtime (you better load all resources for this to work correctly)
- Edit every effect
- Play any effect from assets
- Tries to capture original values (not perfect after all)
- Config per map
- for sure editing lights is hard because some are only textures marked into static entity (judging by dump of worldent creation)
- textures, this engine only allows to null them or replace those which were loaded in current bundle. While replacing is possible, it really is only experimental rather than any useful. I myself don't know how can you load it dynamically in frosbite.
For lights I couldnt find really easier way to detect their references You can edit every pointed light on run
each state has a "name", but to ref the name there are some ways, I basically do: if we can get it from refdata in entity itself -> get its blueprint from there if not -> grab it from data and loop resource mngr comparing addr of pointer. Could have just do all in partition loader, tho it's impossible to run this tool mid-round then
Editing state goes in several possible ways:
- edit visual environment globally, the active one in manager (bad artifacts, or something doesnt apply as should)
- edit each state - best, because the game adds/remove some states at runtime. Some of them are static. Which all makes sense
- capture lerps, since this is quite okay solution because templates produce different function signatures, it's possible to capture all and edit accordingly. Tho this was last way I wanted to do it.
- Edit resource on load, also not bad, but not dynamic, would have to dump all possible main instances to then realisticly change them later on.
In conclusion getting states from resource manager is the best + editing it globally
Component handling uses macros (VE_COMPONENTS) to reduce repetition across
serialization, rendering, and state management. This trades some readability for
a single source of truth, add a component once, it propagates everywhere.
A "proper" OOP approach would require more boilerplate than it eliminates. Probably support for fb3 going to be added in some time, and after final cleanup of code.
video below
