So... I was looking at this while avoiding my own problems for a bit. I don't see any problems with the way you're spawning NPCs. It might be possible that they're timing out and their $BaseCue is getting cancelled, but they're not properly getting despawned for some reason because they're on player-owned stations?
If true, it may be why player stations weren't populated at release. It would have been a low-priority bug with everything else needing attention. Just not spawning the problematic NPCs could have been a quick and dirty fix.
Anyway... I don't ~fully~ understand every aspect of conversations and NPC handling, but it's the part of the game that I've spent the most time looking at so far and some of what I've learned may be useful here.
For non-default conversations to work properly, you basically need two things:
1) The NPC needs the custom conversation handler attribute pointed out by Prefectus
This is set in MD script with the expression
set_comm_handler
or tested in logic expressions with
$actor.customhandler (true/false)
2) The NPC needs to be tied to the relevant NPC_*** script with a cue devoted to managing it that gets pointed to by the actor's $BaseCue parameter.
In the save game, the cue managing the actor will look something like this within the NPC_*** script's saved data:
Code: Select all
<cue id="18021" state="complete" time="10.0111">
<vars>
<value name="$actor" type="component" value="[0x1883a]"/>
<value name="$count" type="integer"/>
<value name="$fee" type="integer" value="98805"/>
</vars>
<cue id="18022" base="1451" state="complete" time="10.0111">
<cue id="18148" base="1452" state="complete" time="10.0111">
<vars>
<value name="$Actor" type="component" value="[0x1883a]"/>
<value name="$BaseCue" type="cue" value="18021"/>
<value name="$KillOnSectorChange" type="integer" value="1"/>
<value name="$MaxDistance" type="length" value="100000"/>
<value name="$MinDistance" type="length" value="20000"/>
<value name="$TimeoutMax" type="time" value="1200"/>
<value name="$TimeoutMin" type="time" value="600"/>
</vars>
<cue id="18205" base="5700" state="waiting"/>
<cue id="18206" base="5701" state="waiting"/>
<cue id="18207" base="5702" state="active" time="10.0111"/>
<cue id="18208" base="5703" state="waiting"/>
</cue>
</cue>
<cue id="18023" base="1455" state="waiting"/>
<cue id="18024" base="1456" state="waiting"/>
<cue id="18025" base="1457" state="waiting"/>
<cue id="18026" base="1458" state="waiting"/>
<cue id="18027" base="1459" state="waiting"/>
<cue id="18028" base="1460" state="waiting"/>
<cue id="18029" base="1461" state="waiting"/>
<cue id="18030" base="1464" state="waiting"/>
<cue id="18031" base="1465" state="waiting"/>
</cue>
Some key lines to notice:
<value name="$actor" type="component" value="[0x1883a]"/>
the value here is the NPC's ID number
<value name="$BaseCue" type="cue" value="18021"/>
the value here points up at the ID of the entire cue handling this actor, so when it gets cancelled at actor timeout the actor's connection to the NPC_*** script gets severed.
These are configured in the first few cues of the
\md\NPC_***.xml files, which are all set up to be signaled automatically any time the
create_platform_actor expression is used. Poking around, you'll notice they point over to
md\GenericMissions.xml which handles (among other things, obviously) the despawning and cleanup of old generic NPCs when they timeout.
So.... revisiting my initial statement, I'm wondering if
md.GenericMissions.PlatformActor is cancelling the
$BaseCue when the NPC times out (one of it's clean-up operations), but is having trouble reliably deleting the NPC itself on player-owned stations for whatever reason?
If this is the case, then it would explain the accumulation of NPCs with bad comm handlers over time as they fail to properly despawn, and why the problem doesn't appear in fresh test stations.
Hey ho we work with what we have.
Last test changed the npc generation to zone change and player zone only but showed the same issue in older save games. I'm at a loss tbh.