Yeah, demolish() is left over from when that was an option, but should have still worked, in theory.
SalvageEntity performSalvage - which should be getting called during normal salvage? - will spawn a debris field and fade out/remove the entity.
Does your entity have the "salvageable" tag?
Basically the things you're doing sound like they should work and that they don't work makes it seem like there's something going wrong in the details that are not in your post, if that makes sense.
It does make sense that I'm doing something wrong, it just doesn't make sense as to what has gone wrong.
Here is the relevant section from custom_entities for the station, which has always had the 'salvageable' tag:
"hmi_station_nightmare":{
"defaultName":"Kiel Research Station", # used if name=null in addCustomEntity()
"defaultRadius":45, # used if radius<0 in addCustomEntity()
"nameInText":"Kiel research station",
"shortName":"station",
"customDescriptionId":"station_research_remnant",
"interactionImage":"graphics/illustrations/orbital_construction.jpg",
"icon":"graphics/icons/station0.png",
"iconWidth":20,
"iconHeight":20,
"sprite":"graphics/stations/station_side00.png",
"spriteWidth":40,
"spriteHeight":40,
"renderShadow":true,
"useLightColor":true,
"showInCampaign":true,
"showIconOnMap":true,
"showNameOnMap":false,
"scaleNameWithZoom":false,
"scaleIconWithZoom":true,
"tags":["has_interaction_dialog", "salvageable"],
"layers":[STATIONS], # what layer(s) to render in. See CampaignEngineLayers.java for possible values
},
Adding SalvageEntity performSalvage to genLootNightmare demolishes the station as it should, but it opens up two salvage windows simultaneously, only one of which you can access. Adding SalvageEntity demolish closes the salvage window as soon as it opens and forms the debris field. I'm unsure if I should somehow add a demolish function to genLootNightmare to run after the entity has been salvaged? After the genNightmareLoot is executed, there's nothing else showing up in the log.
Hmm - the "bizarre reason" should also be detailed in the log, no? If a rule that you're expecting isn't being searched for, that means that its trigger is not the trigger that was fired.
In your DefenderDataOverride, did you set probDefenders? It defaults to 0. I guess you must have, since the constructors all require it, but I'd make sure you're not passing in 0 for that. That'd be one reason for TriggerAutomatedDefenses not being fired.
Here is the entry in salvage_entity_gen_data, which has always had probDefenders at 1:
hmi_station_nightmare,1,1000,DISCOVERABLE,2200,1000,3000,,,,hmi_nightmare,1,1,200,500,8,,,
In the log, it says that the entity is missing $hasDefenders, so it goes straight to sal_explore.
EDIT: Found the problem! I forgot to add the boss ship variant to default_roles. So when the game tried to find defenders, it couldn't, as there were no ships to select. This caused the entity to lose $hasDefenders, and thus why it was never called. Checking this by changing the faction from the dummy hmi_nightmare faction to remnant caused Remnants to spawn as the defending fleet.
Again, the reasons for that should be in the log. If multiple rules match the trigger and conditions, and have the same number of conditions, then one will be picked randomly. You can add a " score:100" (or some other number) to individual conditions to disambiguate in cases like this.
According to the log, it checks if the tag "hmi_nightmarestationtag" exists. Which it then thinks it does and uses the tag-specific salvage option, regardless if the tag is present on the entity or not. I'm unsure if it was changing the format from tag == $hmi_nightmarestationtag to $tag:hmi_nightmarestationtag fixed the problem, or removing hmi_nightmarestationtag from data/campaignid/hmi_tags.json did the trick.
Thank you so much for the help so far.