16
Suggestions / Suggestion: put hullmod incompatibility checks in their own silos
« on: May 07, 2020, 12:42:10 PM »
So, I've just had a devil of a time troubleshooting a problem I had: I wanted to make a set of Logistics hullmods, alternative implementations to the vanilla Augmented Drive Field hullmod. They needed to be incompatible with one another and the vanilla Augmented Drive Field, as well as counting-as Logistics hullmods.
What I discovered, after considerable trial-and-error, was that the way vanilla hullmod incompatibilities are handled, and the way vanilla Logistic hullmods being rejected for the ship already having too many Logistic hullmods, was the same implementation; an @override, specifically something like this:
Thus, when I implemented the hullmod incompatibility checks (so you couldn't detune the engines at the cost of Burn for fuel-efficiency, and then retune them for speed,) it, well, overrode the vanilla "Too Many Logistics Hullmods!" check, and would let me install those hullmods when there were too many Logistics hullmods, which then kicked off another Logistics hullmod the way the shipyard normally does.
So it didn't actually let you build an illegal ship, but it didn't give good feedback about what it was doing.
It would be nice if, instead of this current system, you had something like, I dunno... Pardon my arse-pulled psuedocode here because I'm very much not-a-coder working with things I barely understand, but...
into something like, I dunno,
So it would be significantly less likely for a modder to accidentally override it when attempting to render a hullmod incompatible for another reason.
What I discovered, after considerable trial-and-error, was that the way vanilla hullmod incompatibilities are handled, and the way vanilla Logistic hullmods being rejected for the ship already having too many Logistic hullmods, was the same implementation; an @override, specifically something like this:
Code
@override
public boolean isApplicableToShip(ShipAPI ship) {...};
public String getUnapplicableReason(ShipAPI ship) {...};
Thus, when I implemented the hullmod incompatibility checks (so you couldn't detune the engines at the cost of Burn for fuel-efficiency, and then retune them for speed,) it, well, overrode the vanilla "Too Many Logistics Hullmods!" check, and would let me install those hullmods when there were too many Logistics hullmods, which then kicked off another Logistics hullmod the way the shipyard normally does.
So it didn't actually let you build an illegal ship, but it didn't give good feedback about what it was doing.
It would be nice if, instead of this current system, you had something like, I dunno... Pardon my arse-pulled psuedocode here because I'm very much not-a-coder working with things I barely understand, but...
Code
public class mySuperAwesomeHullMod extends BaseHullMod {...
public boolean conflictsWithHullmods(ShipAPI ship) {
if !ship.getVariant().getHullMods().contains("hullmod 1");
String text = "mySuperAwesomeHullMod conflicts with hullmod 1...";
if !ship.getVariant().getHullMods().contains("hullmod 2");
String text = "mySuperAwesomeHullMod conflicts with hullmod 2...";
if !ship.getVariant().getHullMods().contains("hullmod 3");
String text = "mySuperAwesomeHullMod conflicts with hullmod 3...";
else return null
}
[code]
For extra rigor, it might or might not be desirable to spin-off the "too many Logistics hullmod checking" from the same
[code]
public boolean isApplicableToShip(ShipAPI ship) {...}
into something like, I dunno,
Code
public boolean isTooManyLogisticsHullmods(ShipAPI ship) {...}
So it would be significantly less likely for a modder to accidentally override it when attempting to render a hullmod incompatible for another reason.