Skip to content

Add a workflow to bake blueprint properties of props #6752

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 50 commits into from
May 3, 2025

Conversation

Garanas
Copy link
Member

@Garanas Garanas commented Apr 27, 2025

Description of the proposed changes

Introduces a workflow to make it easier to bake prop blueprints. This workflow uses the BrewWikiGen tool made by @The-Balthazar. We entirely ignore the wiki part of the tool, and instead just use it to bake in properties into blueprints.

With this workflow it now becomes possible to mass-process blueprints. I'll try and think through a proposal for the exact procedure the following days.

Some advantages are:

  • Reduce loading time.
  • Reduce post processing during run time.
  • Blueprints reflect the 'truth' better.

Testing done on the proposed changes

See also this commit of a fork of the fa repository, that is a result of this workflow run.

Additional context

This allows us to bake in properties of blueprints.

The capability to do the baking so conveniently is entirely new. It was previously either out of reach (before the creation of the tool by Balthazar), or difficult to setup (using the tool of Balthazar).

With this new capability there's also a new type of question: what properties should we bake in, and what properties are better to (also) be applied during runtime? The advantage of post processing at run time is that it's also applied to all mods.

This is a difficult question! Some values are critical for the functionality of FAForever, and others are too sensitive that I strongly believe they should always be overwritten at runtime. As a few (quick) examples:

  • AI.GuardScanRadius of unit blueprint: extremely sensitive to the performance of the simulation.
  • Weapon.TargetCheckInterval of unit blueprint: extremely sensitive to the performance of the simulation.
  • Defense.ThreatXYZ of unit blueprint: sensitive to the performance of AIs, as balance changes these should change accordingly.
  • Display.Mesh.LODs of unit and prop blueprint: sensitive to the rendering performance of the game.
  • ExtractWreckageBlueprint of general post processing: Introduction of wreck blueprints.
  • ExtractBuildMeshBlueprint of general post processing: Introduction of build blueprints.
  • ExtractCloakMeshBlueprint of general post processing: introduction of cloak blueprints.

And a few examples that may be interesting to bake in:

  • HandleUnitWithBuildPresets of general post processing: Creation of SACU presets.

Features for future pull requests

  • Add support for unit blueprints.
  • Add support for projectile blueprints.
  • Add support for beam blueprints.
  • Add support for emitter blueprints.
  • Bake all blueprints when deploying to deploy/faf, deploy/fafbeta or deploy/fafdevelop.

Checklist

  • Changes are annotated, including comments where useful
  • Changes are documented in the changelog for the next game version

@Garanas Garanas marked this pull request as draft April 27, 2025 10:34
@Garanas Garanas marked this pull request as ready for review April 29, 2025 07:30
Copy link
Contributor

@lL1l1 lL1l1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I familiarized myself with workflows and brew wiki gen just now, so maybe it's not the best but I took a look.

@Garanas
Copy link
Member Author

Garanas commented Apr 29, 2025

@lL1l1 I've spent an hour or two. It now creates a pull request if you trigger the workflow manually. this allows you to review it. It creates a commit if you trigger it from another workflow, which would be done when deploying.

As an example of a pull request:

edit: there are small changes in here to test the workflow. I'll remove those when we're ready for a merge.

@Garanas
Copy link
Member Author

Garanas commented May 1, 2025

Adjusted the test workflow to only test the syntax of files that we ship. It now tests 6863 files instead of 7030 files. The largest difference (78 Lua files) is the engine folder. The other remaining 89 Lua files are scattered among the other folders that we do not ship.

All of the above is nonsense - I forgot there are layout files in the textures folder. The syntax check script also ignores the files in the engine folder by default. The difference is now 7, which makes more sense 😄 !

Copy link
Contributor

@lL1l1 lL1l1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just have to remove the testing changes in blueprints-props.lua and this can be merged.

Also the commit description should note that it fixes the sparse checkout for the lua syntax test as well.

@Garanas Garanas added the area: baking of blueprints related to baking properties into blueprints via workflows label May 3, 2025
@Garanas Garanas merged commit 7c412db into FAForever:develop May 3, 2025
5 checks passed
@Garanas Garanas mentioned this pull request May 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: baking of blueprints related to baking properties into blueprints via workflows
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants