george moromisato wrote:Atarlost wrote:Yes, but (a) this worked in 1.1 and (b) how can you install an armor segment if you don't know what slot to install in?
I believe this worked in 1.1 because of a side-effect: that callers of shpCanInstallArmor
happen to set gArmorSegment before the call. But there is no requirement that all callers do this.
I don't think it ever made sense to call it from a context in which gArmorSegment was undefined. The only reason to call it was to replace an armor segment and that required defining gArmorSegment.
On sustainability I think it's less an issue than you think so long as behavior is preserved.
If both overrides are local they should default through when they don't see the marker that tells them to not just run the version previously defined and both should work just fine unless both markers are present.
If the other override is global their priority is undefined whether through overriding the function or through implementing <CanBeInstalled> and <GlobalCanBeInstalled>.
An event would work for armor because the function only has two outputs, but I'm concerned that an event for devices would make dealing with objCanInstallItem harder because it has multiple possible outputs both for success and failure.