mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-15 20:22:07 +00:00
bf6f81a9b5
On the tin, doing it like this means we can reduce our overall line fingerprint whenever we have to add two or more traits from the same source on the same target. Especially helps when we get to the 4+ range of traits, a breath of fresh air even. Doesn't mean we have to do for loops, as that's already handled within the define as well. I replaced some of the checks with `length()` checks, let me know if I should switch it over to something else (maybe `islist()`)? We stack_trace whenever we're not passed a list reference on purpose, and sometimes var/lists are null by default (or just empty, making this redundant). ## Why It's Good For The Game I commonly feel the urge to write "use `AddTraits()`" or something in reviews, then am sad when I remember it doesn't exist. I will no longer be sad. Can ensure a lot more trait safety as well by using static lists- when both ADD_TRAIT_LIST and REMOVE_TRAIT_LIST re-use the same list, you are confident (from a static point of view) that everything that you want to be adding/removing works. I may have missed a few things where this could be used, but both macros implemented in this PR still use the same framework that was being used in the last four years- so stuff won't break if left untouched. Just a nifty new tool for developers. also fixed up some code in the area, numerous bugs were found and exploded