Escorts following through player wormhole

[Eric Walch]

the player ship now creates a wormhole and I just tested it: normal pirates will just follow you when jumping to a nearby system.

However, they will leave their escorts behind in the process.

Two problems:

(1) The PLAYER WITCHSPACE message in pirateAI nowhere triggers a wormholeEscorts. I think it should be

Code: Select all

        "PLAYER WITCHSPACE" =         (
            enterTargetWormhole,
            wormholeEscorts
        );

or something like that.

(2) That wouldn't even be enough. wormholeEscorts sends an ENTER WORMHOLE to the escorts. They do receive that while in normal escort mode (stage FLYING_ESCORT). However, during a fight the escorts have interceptAI, and there is no ENTER WORMHOLE message in that AI. It would at least be needed in the AI's ATTACK_SHIP state, and should probably also contain an exitAI, so that in the new system the escort is correctly re-attached to its mother.

You are right that we need an additional wormholeEscorts at your indicated location (2x)

the interceptAI needs more modifications to let escorts follow. The following interceptAI was just tested as working:

Code: Select all

{
	GLOBAL =
	{
		ENTER = (switchLightsOn, "setStateTo: ATTACK_SHIP");
	};
	"ATTACK_SHIP" =
	{
		ENTER = (performAttack);
		"ENERGY_LOW" = ("setStateTo: FLEE");
  		 ATTACKED = (setTargetToPrimaryAggressor, "setStateTo: ATTACK_SHIP"); 
  		 "ESCORT_ATTACKED" = (setTargetToPrimaryAggressor, groupAttackTarget); 
		"INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: FLEE");
		"TARGET_DESTROYED" = (performIdle, switchLightsOff, exitAI);
		"TARGET_LOST" = (performIdle, switchLightsOff, exitAI);
		"PLAYER WITCHSPACE" = ("setStateTo: PLAYER_WITCHSPACE");
		"ENTER WORMHOLE" = (performIdle, switchLightsOff, "exitAIWithMessage: ENTER WORMHOLE");
	};
	FLEE =
	{
		ENTER = (deployEscorts, "setDesiredRangeTo: 25600", performFlee);
		"ENERGY_FULL" = ("setStateTo: ATTACK_SHIP");
		"TARGET_LOST" = (performIdle, switchLightsOff, exitAI);
		"TARGET_DESTROYED" = (performIdle, switchLightsOff, exitAI);
		"REACHED_SAFETY" = (performIdle, switchLightsOff, exitAI); 
		"INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: FLEE");
		"PLAYER WITCHSPACE" = ("setStateTo: PLAYER_WITCHSPACE");
		"ENTER WORMHOLE" = (performIdle, switchLightsOff, "exitAIWithMessage: ENTER WORMHOLE");
	};
	"PLAYER_WITCHSPACE" =
	{
		"ENTER WORMHOLE" = (performIdle, switchLightsOff, exitAI, enterTargetWormhole);
	};
}

When the mother would generate a wormhole herself, a "ENTER WORMHOLE" would be enough, but when the mother reacts on a "PLAYER WITCHSPACE", we have two situations: the escorts already had the "PLAYER WITCHSPACE" themselves or they still will get it. Both situations need a bit different reaction what is incorporated in above AI. In the case of the player leaving the system, everything is time critical as ships are being removed from the current system in this frame. There is no time to delay actions to the next update, everything must be set correct at the end of this frame. Now test it a bit longer to see if it bugs other behaviour.

It can happen that the escorts are closer to the wormhole and thus exit sooner. Escorts are very impatient and when mom does not arrove soon enough they are on the look for a new master.

[Switeck]

Maybe an exited witchspace check for Escorts and have them pause a bit before looking for their mom?

[Eric Walch]

Maybe an exited witchspace check for Escorts and have them pause a bit before looking for their mom?

Something like that. I probably include the line:

Code: Select all

"EXITED WITCHSPACE" = ("setStateTo: EXIT_WORMHOLE");

And add a new state "EXIT_WORMHOLE" to deal with this.
"EXITED WITCHSPACE" is only send to ships leaving wormholes. (not to confuse with the similar "EXITED_WITCHSPACE" message that is send to all ships arriving with a witchspace bubble).

All ships fly at maximum speed to the player wormhole. And because escorts usually have a higher max speed than the mother, they almost always arrive sooner than the mother herself. A complicating fact is that escorts groups are released before jumping. So, they have to reassemble at the other side. I don't think this will be a major problem, unless the player immediately makes a second jump.

I think this situation was never tested at all. Tested was always escorts following through their mothers wormhole.

[Switeck]

Might be worthwhile to kill a couple birds with 1 stone.
The GLOBAL section seems appropriate to check for both "EXITED WITCHSPACE" and "LAUNCHED OKAY". These are probably mutually exclusive conditions unless they can both apply to ships that just arrived via a carrier.

You have made me aware that there's some sort of subtle nuances between "EXITED WITCHSPACE" and "EXITED_WITCHSPACE"...which means I am thoroughly confused now how that applies to other multi-word messages. Does the "_" or " " always do something different for each?

Let's see if I can get this right:
Any ship spawned near the witchspace beacon, either by a script or the system populator (probably a replacement result of another ship leaving elsewhere) will get "EXITED WITCHSPACE". But those same ships will *NOT* get an "EXITED_WITCHSPACE" message because they didn't arrive via a witchspace bubble from somewhere else, since they were only created in-system and have no history of ever being anywhere else. (All an artifact of being a player-centric game.)
Ships following through the player's wormhole from a previous system would get both "EXITED WITCHSPACE" and "EXITED_WITCHSPACE" messages?

[Eric Walch]

Might be worthwhile to kill a couple birds with 1 stone.
The GLOBAL section seems appropriate to check for both "EXITED WITCHSPACE" and "LAUNCHED OKAY".

The GLOBAL state usually starts with jumping to a new state, so any initial messages must be examined in that state, not in GLOBAL.

You have made me aware that there's some sort of subtle nuances between "EXITED WITCHSPACE" and "EXITED_WITCHSPACE"...which means I am thoroughly confused now how that applies to other multi-word messages. Does the "_" or " " always do something different for each?
...
Ships following through the player's wormhole from a previous system would get both "EXITED WITCHSPACE" and "EXITED_WITCHSPACE" messages?

This difference already existed in Oolite 1.65. And it is possible a bug that both are different. But, currently I am pleased that we can differentiate the two situations. The first message is generated by the code that ejects ships from wormholes, while the second is generated by the code that generates the witchspace bubbles. And since 1.74 have all ships that are spawned near the whitchpoint such bubbles, independent on the used code. So, yes, npc ships arriving trough wormholes have both messages since 1.74 (although a name of "EXITING_WORMHOLE" for the first would have been clearer).

[Kaks]

Hmm, it does feel like an API bug to me...


FWIW, I'd alias 'EXITED WITCHSPACE' to 'WILL_EXIT_WITCHSPACE', to make it consistent with the corresponding ship js event and label the still supported (for backward compatibility) 'EXITED WITCHSPACE' as deprecated.

If we do that we could then have the following on the wiki: "this applies only to ships that are tunnelling in-system via a wormhole - ships added to the system via script within scanner radius to the witchpoint will generate 'EXITED_WITCHSPACE', but without a corresponding 'WILL_EXIT_WITCHSPACE'. Ships added via script away from the witchpoint won't generate any witchspace related event or AI message. ".

[Eric Walch]

FWIW, I'd alias 'EXITED WITCHSPACE' to 'WILL_EXIT_WITCHSPACE', to make it consistent with the corresponding ship js event and label the still supported (for backward compatibility) 'EXITED WITCHSPACE' as deprecated.

Probably a good idea. Current native AI scripts only use 'EXITED WITCHSPACE'. But I was lying: Ships leaving wormholes don't generate the 'EXITED_WITCHSPACE' message. I was just seeing in the log what I wanted to see and not what was really written. The log shows:

Code: Select all

[ai.message.receive] AI.m:455: AI escortAI.plist for Scorpius Escort 336 in state 'BEGIN_BUSINESS' receives message 'EXITED WITCHSPACE'. Context: unspecified, stack depth: 0
[ai.message.receive] AI.m:455: AI escortAI.plist for Scorpius Escort 336 in state 'EXIT_WORMHOLE' receives message 'ENTERED_WITCHSPACE'. Context: handling deferred message, stack depth: 0

I was blinded by the word _WITCHSPACE and did not notice it started with ENTERED. This message is still pending from the moment the ship entered witchspace. But without a 'EXITED_WITCHSPACE' message in the log, it mend that the witchspace leaving effects were skipped. And I must say that I never saw them. I thought it was because I never turned fast enough.

I now changed the code so that "disgorgeShips" does call the "witchspaceLeavingEffects". I immediately noticed the witchspace bubbles of the ships following through my wormhole. This bug was probably never noticed because it was in the past hard to meet ships that really were in the process of disgorging from a wormhole.

After this change, the message 'EXITED_WITCHSPACE' is generated. It is generated as normal message before the 'EXITED WITCHSPACE' is generated. The later however is a reactToMessage, so that the AI always handles it first. So changing it to a 'WILL_EXIT_WITCHSPACE' still is the correct order as the AI sees it.

[Commander McLane]

Code: Select all

[ai.message.receive] AI.m:455: AI escortAI.plist for Scorpius Escort 336 in state 'BEGIN_BUSINESS' receives message 'EXITED WITCHSPACE'. Context: unspecified, stack depth: 0
[ai.message.receive] AI.m:455: AI escortAI.plist for Scorpius Escort 336 in state 'EXIT_WORMHOLE' receives message 'ENTERED_WITCHSPACE'. Context: handling deferred message, stack depth: 0

I was blinded by the word _WITCHSPACE and did not notice it started with ENTERED. This message is still pending from the moment the ship entered witchspace.

I was wondering about this as well. Why is the ENTERED_WITCHSPACE still pending after the ship has exited? And what is it good for? Because it's still pending it may slow down the restarting AI for one UPDATE cycle, because it has to go away first, before the next pending message is received. And I don't know any AI which reacts to an ENTERED_WITCHSPACE message in its GLOBAL or the next following state.

[Eric Walch]

I was wondering about this as well. Why is the ENTERED_WITCHSPACE still pending after the ship has exited? And what is it good for?

It is completely useless. I assume Giles added it long ago without a real use in mind. To be useful, it should have been a 'reactToMessage' because there is no update following for the ship in the current system. At the same time a JS event is send, so a ship-script still can react to the jump. That means the message will only be present in ships that arrived from other systems. It is also a way of detection that a ship is entering from a real wormhole. But than we always have had the 'EXITED WITCHSPACE'.
The only message in use is the 'EXITED WITCHSPACE' and that is a reactToMessage, which is immediately reacted upon.

[Commander McLane]

I was wondering about this as well. Why is the ENTERED_WITCHSPACE still pending after the ship has exited? And what is it good for?

It is completely useless.

Good to know. For my tweaked thargoidAI I'm doing

Code: Select all

        "EXITED WITCHSPACE" =         (
            "dropMessages: ENTERED_WITCHSPACE",
            "setStateTo: TRAVEL_TO_START_POSITION"
        );

in order to get rid of it as soon as possible.

[Eric Walch]

Code: Select all

            "dropMessages: ENTERED_WITCHSPACE",

in order to get rid of it as soon as possible.

Not really needed to drop it when you have no code that could react on it.

I just committed my fixes. (r4523).
- ships leaving a wormhole now also use the witchspace leaving effects.
- pirate escorts now correctly follow the master trough a player wormhole. (For other wormholes there was never a problem).
- regrouping is sometimes a problem because the mother often enters as last one. Specially when mom sends attack instructions before regrouping is complete and than the escorts start escorting instead of attacking.
- to prevent above problem, I now added a "ACCEPTED_ESCORT" message, that enables the engagement of escorts that started escorting when mom was already in fight.

[Switeck]

"this applies only to ships that are tunnelling in-system via a wormhole - ships added to the system via script within scanner radius to the witchpoint will generate 'EXITED_WITCHSPACE', but without a corresponding 'WILL_EXIT_WITCHSPACE'. Ships added via script away from the witchpoint won't generate any witchspace related event or AI message. ".

I believe I was seeing exiting hyperspace "rings" around the new railgun OXP when firing it in interstellar space, obviously near 0,0,0.

I have experimented heavily with which ships count as "EXITED_WITCHSPACE" as a result of my "Switeck mod" OXP. Various old methods do not trigger it, which was what I was using to place new trader role (route1traderAI.plist) NPC ships near the Witchpoint Beacon...expecting them to choose a new AI.plist script after exiting witchspace. At first I was very disappointed that my AI.plist file was completely broken...then I got really confused -- because as time went on, more and more newly arriving traders did change roles based on my AI.plist file.

[Commander McLane]

"this applies only to ships that are tunnelling in-system via a wormhole - ships added to the system via script within scanner radius to the witchpoint will generate 'EXITED_WITCHSPACE', but without a corresponding 'WILL_EXIT_WITCHSPACE'. Ships added via script away from the witchpoint won't generate any witchspace related event or AI message. ".

I believe I was seeing exiting hyperspace "rings" around the new railgun OXP when firing it in interstellar space, obviously near 0,0,0.

The same thing will probably happen if you fire them close to the witchpoint.

Obviously this is wrong. I'll have to think about an alternative spawning method for the projectiles. Thanks for the report.