CLASS_ROCK and commsMessage: in 1.71.1

[Commander McLane]

In 1.71.1 entities with scan_class CLASS_ROCK (and also with CLASS_CARGO) can't send commsMessage: through their AI. The method doesn't do anything. It doesn't even produce anything in the log.

I know positively that the AI-method commsMessage: did work for entities with CLASS_ROCK in previous versions, because I used it a lot for in-game AI-debugging.

I don't know whether it was deliberately disabled or it is a bug.

N.B.: It does work in 1.71.1 for rocks that are stations, like Salvage Gangs, and for entities with CLASS_CARGO, if they have a pilot defined in characters.plist and the key unpiloted is set to FALSE. It doesn't work in other cases.

[another_commander]

Unpiloted entities cannot send commsMessages. This is deliberate and related to a bug fix that was assigning crews to things like boulders and alloys.

When fixing the bug, I kind of anticipated a possible need for unpiloted ships to send commsMessages (like in the imaginary scenario of an abandoned ship carrying a recorded message). In the game's code there is a dormant commsMessageByUnpiloted method, which has not been included, because no one has officially approved its inclusion yet.

From PlayerEntityLegacyScriptEngine.m:

Code: Select all

#if 0		// Disabled until approved for inclusion.
// This method does the same as -commsMessage, (which in fact calls), the difference being that scripts can use this
// method to have unpiloted ship entities sending comms messages.
- (void) commsMessageByUnpiloted:(NSString *)valueString
{
	[self commsMessage:valueString];
}
#endif

If it is OK, to include this, I could check and verify that it still works and maybe have it in for 1.72.

[Eric Walch]

Unpiloted entities cannot send commsMessages. This is deliberate and related to a bug fix that was assigning crews to things like boulders and alloys.

It makes sense that boulders and alloys don't have pilots in them. But also buoys shouldn't have pilots. So when it is changed, also remove the pilot from the buoy and let them also used the "commsMessageByUnpiloted:" to broadcast a warning when attacked.

[Commander McLane]

I would vote for that.

First, because I am scripting something like this right now: A defunct ship (hence scan_class CLASS_CARGO), which nevertheless has to send a message to the player. Although I've worked around it by giving it a pilot.

But second, because it was very handy for debugging AIs, to let any entity send a message that indicates not only the state it is in, but also the AI message it has just got. It's a convenient (perhaps the only?) way to find out whether the AI actually has found the object it is scanning for, and received the TARGET_FOUND message.

[JensAyton]

When fixing the bug, I kind of anticipated a possible need for unpiloted ships to send commsMessages (like in the imaginary scenario of an abandoned ship carrying a recorded message). In the game's code there is a dormant commsMessageByUnpiloted method, which has not been included, because no one has officially approved its inclusion yet.

Oh yeah. This method is hereby rubber-stamped… but I think the implementation is broken. Surely you need a method in ShipEntityAI that bypasses the check? This will only work in scripts.

[another_commander]

Yes, you are right. The way it is now works only in scripts. I'll see what I can do to get it to work on the AI side, too.

Edit: It's done. From version 1.72 on, the AI method commsMessageByUnpiloted: <Your message here> will be available for ships, regardless of their crew state.