I know there’s a general obligation to keep complexity low in Vassal modules, and that involves some basic principles like not having too many traits, carefully defining GKC targets, and avoiding overly-long ? : constructions in trigger conditions, for example.
But sometimes I seem to go over the complexity budget, but find the features I added too useful to do without, and then I can end up in very time-consuming testing to find out what exactly takes the most time and how to try and make slow functions milliseconds or even whole seconds faster.
So I was wondering if there were any more principles of module design I could apply to alleviate the need for such testing. Things that might be obvious to a real programmer, or someone with detailed knowledge of Vassal’s code, but might not be obvious to someone who has only ever interacted with the Vassal editor UI.
For example, say you have a map-level key command that can trigger all kinds of things on piece move. Say a trigger has a bunch of conditions to ensure it only fires under specific circumstances. Does it matter if you put the “simplest” condition to not trigger “first” in the beanshell line? Does a conditional restriction trait work faster/better under some circumstances?
Any and all tips welcome (other than “use custom code” - I’d like to keep everything inside Vassal). It’s hard for me to speculate about what might be beneficial, because I don’t have a good idea of the scope of what I don’t know…