ShipSystemStatsScript.
Added CombatEntityAPI MutableShipStatsAPI.getEntity(). You can cast it to ShipAPI in that particular case (sometimes, it may be a MissileAPI).
And thank you for putting in so much effort on the modding side of things. I've been modding for 12 years, and Starfarer is (by far!) the most enjoyable of all the games I've ever modded.
Thank you, it's my pleasure
Oh, and if you're noting things that need attention, ShipAPI's getPhaseCloak() still returns a placeholder Object.
Changed to ShipSystemAPI. That's what it already returned, just hadn't changed the method signature.
Hmm, is the problem with getBaseDamage() due to the MutableStats? If so, would a getDamage() method suffer the same difficulties? Sorry to bother you about this, but I'm trying to write helper classes that calculate the threat generated by nearby enemies, and damage is fairly important to the equation.
Oh and on getDamage(), I'd rather just see the current true damage; that's very complex because of flux bonuses, character bonuses, system bonuses, bonuses for your bonuses, etc.
Yeah, that's part of the problem. But all that doesn't get figured out until a projectile is actually created. Which you can get access to once they're flying, which can be a bit late for certain things.
Added WeaponAPI.isFiring(), btw. That may come in handy for determining how much of a threat something is.
Let me just expose something that's used internally. It's not taking skills or damage bonuses into account, but are the baseline weapon stats, in a more immediately useful form:
public static interface DerivedWeaponStatsAPI {
float getBurstFireDuration();
float getSustainedDps();
float getEmpPerSecond();
float getDamageOver30Sec();
float getDps();
float getBurstDamage();
float getFluxPerDam();
float getRoF();
float getFluxPerSecond();
float getSustainedFluxPerSecond();
}
.
Also added WeaponAPI.getDerivedStats().
I hope that the "can I fire at this" team-check's all in one place; it should be straightforward to do "not my team, but not team 100" to keep AI from shooting NEUTRAL stuff and "team 100 does not fire". Request that team 666 be designated HOSTILE, lol.
It's not, actually. Which could pose a bit of a problem
I want to be able to see stuff that's going on in the strategic map a little less clunkily. My diplomatic system, for example, just goes off of changes over time and is potentially exploitable (for example, you can attack X, drop Relations .1, then attack Y and Z before the next update and avoid the "you just attacked an ally" condition I wrote). Having a callback when a battle ends on the strategic map would be a huge benefit there, as well as allowing for a bunch of other stuff to be made possible such as writing some basic strategic-level AI. Right now it's very clunky getting information about what's going on, but it's gotta be there already, because the engine's clearly acting on it.
Yeah, I understand. I just don't want to go expanding the campaign API until a few versions from now.
Now then, I should really go back to working on some design docs - been doing nothing but posting here since this morning. Well, and fixing/adding things in response, so I guess that counts as "real work"