WittleWolfie
commented
2 years ago The nature of the API means that it can change between versions:
- The Configurator & Builder methods are automatically generated based on game code
- Manual overrides are used to improve specific API methods
The result is that the API changes if:
- Manual overrides are updated to enforce parameter requirements
- The underlying game code changes
- Large scale improvements are made, e.g. Adding Blueprint<> class for flexibility when referencing blueprints
The change from 2.0.3 to 2.0.4 was a bugfix so I apologize, but there's no way to ensure the API is stable moving forward. This is a big part of why the library is distributed as a DLL to merge; you can affix to a specific version. If it were distributed as TTT-Core that wouldn't be possible. Technically I could make the API stable by always replacing the existing API but it would explode in size.
The ordering of parameters is alphabetical to provide some determinism, but changes to the parameters may affect ordering.
I strongly encourage the use of named parameters to avoid most issues this can cause. It improves readability and minimizes the chance an implicit cast causes bugs:
AddAbilityEffectStickyTouch(touchDeliveryAbility: delivery)This prevents issues caused by parameter re-ordering as well as updates which take an optional parameter and make it required. For example, I will probably add an override in the next release to make touchDeliveryAbility required. The above code sample will compile in the current version and the next, even with that API change.
Updating from 2.0.3 to 2.0.4 made me refactor a ton of things because the paramater order of a bunch of methods appears to have randomly changed. An API is a contract, more or less. x.x.y to x.x.y+1 upgrade in an API should not break things. Ever.
AddCraftInfoComponent uses that didn't name arguments because the merge behavior params got dropped into the middle, for instance.
The merge behaviors being dropped into slots 2+3 seems to be happening a lot - in AddAbilityEffectRunAction too.
AddAbilityEffectStickyTouch put the merges in front of the sticky touch abiliy and ... why does that even have a merge behavior? It's a single reference, it's replace or don't replace.