Way to change gameVersion (GPsyonixBuildID) if there is an error

[LEX0RE]

Hey,

With the update coming each 2 weeks or so, would it be possible to be able to change add maybe a fallback by ourself to the gameVersion ? I just found out that the Game Log file just give us the current version and that could be taken as a fallback by ourself if needed to not need to wait for an update of all the package chain.

That exemple of log file is most of the time in "Rocket League/TAGame/Logs/Launch.log"

Ex of Log line:

Log: GPsyonixBuildID 260506.26700.517210
Init: Version: 260506.26700.517210

With that, if you default gameVersion don't work (with a give request error), we could fallback to another one instead of need to quickly update all dependency.

At the end, its more for us to have a way to make the update if anything happen

[ktiedt]

The first concern I see with this approach would be with a version update, its not uncommon for there to be new data structures or types in some aspect of the API that become breaking changes as well — this could lead to un-intended API results or failed API response parsing… On its face, it sounds like a win, but I suspect it could create more problems than it potentially avoids.

…

-Karl Tiedt

On Thu, May 28, 2026 at 10:04 Alexandre Gélinas ***@***.***> wrote: *LEX0RE* created an issue (dank/rlapi#10) <#10> Hey, With the update coming each 2 weeks or so, would it be possible to be able to change add maybe a fallback by ourself to the gameVersion ? I just found out that the Game Log file just give us the current version and that could be taken as a fallback by ourself if needed to not need to wait for an update of all the package chain. Ex of Log line: Log: GPsyonixBuildID 260506.26700.517210 Init: Version: 260506.26700.517210 With that, if you default gameVersion don't work (with a give request error), we could fallback to another one instead of need to quickly update all dependency — Reply to this email directly, view it on GitHub <#10?email_source=notifications&email_token=AAAXXWVG7OJV33ASYWPAYAD45BIP7A5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBVGQYTINJZGU2TTJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXXWX6RBVOVU4RGK37XRT45BIP7AVCNFSM6AAAAACZRAT7CGVHI2DSMVQWIX3LMV43ASLTON2WKOZUGU2DCNBVHE2TKOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[LEX0RE]

You got a good point here, it's up to you at this time I would say. I don't really know if the breaking change could make unintentionnal thing for user like ban or stuff like that, so yeah. I leave that to your decision

[dank]

The log on its own won't work because the feature set (PrimeUpdate_) string needs to be updated as well.

It's also annoying to automate because you need to run the game with a proper D3D handle for this to be printed in the logs from my testing.

But I actually have a work stream underway that solves all that with static binary analysis through a CI pipeline. This would be fully automated, triggered by a game update from EGS, and the new version pushed within a few minutes of the update.

There's also a grace period on the API of ~24hr where it still accepts the old version, so the cadence isn't that important.

I'm hoping to have that out before the next update, 96514bb was phase 0.5 of that.

I also agree it would be useful to have an option to manually override these config so I'll add an interface for that too.