My question is: what's stopping you from exposing the vast majority of simple getter/setter methods that are present in implementing classes but are not present in the API? ButtonAPI's being just an example, there are plenty of cases like this - had a comment on getTurretGunSpriteName(), where the method was right there in the class but it required indirect reflection to get to use it - said method being added by you in upcoming patch too.
Mainly time and a reason to do it. Exposing everything that could be reasonably exposed via the API would be a very substantial undertaking, and a lot of older stuff specifically wasn't written with it in mind. Stuff gets added to the API, generally speaking when:
1) I need to use it from code that's outside of core, or
2) Someone asks for it
So, given that second one - just added these and a few more to ButtonAPI

(There are some cases where the methods are unsuitable for external use for whatever reason, but that I think is fairly rare. But e.g. exposing specific things from within core code that aren't exposed at all may be another matter, a rats nest of dependencies that has to all be exposed in some way...)
what layer does a BaseEveryFrameCombatPlugin's renderInUICoords() method render on?
or is it all of them? having some wierdness with colours that could be explained by this; the alpha of anything I render seems to be set to full
edit : did a test w/ a sprite & it seems like the alpha is just getting thrown away, is there any way for me to fix this on my end? attached a screenshot below.
Above all of them, and below the rest of the UI. No idea what's going on with the sprite - did you set its blend mode to something weird? This has nothing to do with where it's being rendered, I don't think; looks to me like some kind of error on your end more than likely!
What is the correct usage of CombatEngineAPI.spawnProjectile(ShipAPI ship, WeaponAPI weapon, String weaponId, String projSpecId, Vector2f point, float angle, Vector2f shipVelocity);?
Every time I have tried to use it, it crashes with a nullpointerexception in the constructor of either MovingRay or BallisticProjectile. For example calling this method with non-null variables, and with the strings "lightdualac" and "lightdualac_shot" will cause a crash. This makes it impossible to spawn projectiles that are indirectly spawned via MIRV missiles, e.g. the "sabot_warhead2" projectile. Can this be clarified please?
Hmm - it's used a bunch of times in the API for things like mines, some Omega weapons, etc. Also, data.scripts.plugins.TestCombatPlugin calls this to spray a bunch of lightmg shots, and I recall this working.
how do you get if a planetary market has a com relay, via code?
Is it like this? sector.getEntityById(Entities.COMM_RELAY) / sector.getEntityById(Entities.COMM_RELAY_MAKESHIFT)
I am unsure
You can do:
market.hasCondition(Conditions.COMM_RELAY)
It's a hidden condition that doesn't show up and the comm relay script iirc manages it under the hood.
I need to get tags of specific IntelInfoPlugins. How do I get a hold of SectorMapAPI instance in order to call Set<String> getIntelTags(SectorMapAPI map)? Searched through, all the usages are only extensions of caller methods, nothing returns SectorMapAPI.
I'm pretty sure you can just pass in null for the map; intel plugins are supposed to handle that. The vanilla ones do (unless I messed up); I just added a comment to the javadoc to make this expectation clear. Worst case you could do this in a try/catch block, *shudder*.
Oh God... In the process of writing this I looked into the BaseIntelPlugin and realized that what I thought to be a completely legit mechanism of making the intel visible/hidden (as implied by the javadoc comment) is actually not a functioning feature at all. I guess I can't set intel items to be hidden/shown after all:
Oh wow, my apologies

Ah, this is a bug, actually - in the dev version, this code already has:
return TutorialMissionIntel.isTutorialInProgress() || hidden != null;
So looks like it came up or was reported and I fixed it up at some point.