Switeck's Shipping v0.5 OXP - Ai, Economy, and Ship changes

[Eric Walch]

I don't know what exactly has changed in the code to make the time between launches considerably longer, but this change certainly affects mothers with many escorts badly.

There have been some changes, but not as big a you describe. After launch, the ships AI was paused for 2 seconds. Only after this delay, the AI got control over the ship and the ship could turn away. For very slow flying ships, like shuttles, this could be to short. e.g. shuttles launching from a dredger ship flew trough the dredger nose construction.

In 1.75 there is a better check for the station geometry and launching ships get only control when two port lengths outside of the bounding box at the side of the port.

For a normal Coriolis and dock, that means the ship has to fly 500 meter before getting control. Ships launch at 50% of max speed, that means that escorts need about 3.3 second to reach that point. That is only 1.3 seconds longer than it used to be. But at least all ships now get control at the same distance from the station.

[Commander McLane]

I have taken the time to sit in front of a station and measure the interval between launches. What I typically observe is this: a ship is launched, flies forward a couple of hundred meters (without control) and another couple of hundred meters (with control) then turns isideways and flies perpendicular to the straight line from the docking bay for another couple of hundred meters. Only then the next ship is launched.

It doesn't matter whether it's independent traders or escorts. I have clocked the intervals between the launches with the stationLaunchedShip handler and issued a couple of S.mainStation.launchShipWithRole("trader"). Here's a small list (I've separated the ship groups):

Code: Select all

Launched Cobra Courier at 56.48422294855118

Launched Boa at 72.02392196655273
Launched Excalibur at 90.05350196361542
Launched Delta Long-Range Escort at 102.07318496704102
Launched Tiger Mark I at 114.0929319858551
Launched Delta Long-Range Escort at 120.10234600305557

Launched Anaconda at 132.12202590703964
Launched Cobra Mark I at 156.16147792339325
Launched Cobra Mark I at 174.19108891487122
Launched Cobra Mark I at 186.197959959507
Launched Cobra Mark I at 198.21196794509888
Launched Cobra Mark I at 216.23298197984695
Launched Cobra Mark I at 228.2470029592514

Launched Cobra Courier at 246.26804798841476

Launched Anaconda Liner at 258.28207594156265
Launched Sidewinder ASW Escort at 282.3068739771843
Launched Sidewinder ASW Escort at 294.3209170103073

Launched Paladin at 306.3449490070343

Launched Cobra Mark III at 318.35896396636963

The pauses between launches are fairly consistent between trials. They seem to have a certain random element (possibly part of it is caused by other activities in the system), but they also clearly seem to depend on the just launched ship. I don't know whether the correlation is with its size, mass, speed, or something else. But clearly the Anaconda and Anaconda Liner cause the longest pauses (24 and 26 seconds respectively). For some reason the Tiger creates the shortest pause (only 6 seconds, and this is true for every Tiger I've seen so far), while most ships create pauses between 12 and about 18 seconds.

For the Anaconda and its escorts it takes a full 96 seconds until the entire group is launched. By that time the Anaconda itself had long jumped out.

I find some of the pauses extremely long. I cannot be certain for previous versions of Oolite, but I would swear that the Tiger's 6 seconds is about what used to be the general pause between launches. In trunk the vast majority of pauses are way longer. And it causes mothers to jump out before their last escorts haven't even been launched. This seems a clear bug to me, and I don't recall this ever happening in Oolite 1.72 or so.

[Eric Walch]

For some reason the Tiger creates the shortest pause (only 6 seconds, and this is true for every Tiger I've seen so far), while most ships create pauses between 12 and about 18 seconds.

6 seconds will be the bare minimum distance as the 'delay_between_launches' is defined at 6 seconds.
I never looked very closely at the delay mechanism, but looking at it, the high values of the 6, 12 and 18 make second intervals are explainable.

As long as there are ships to launch, the launch is evaluated every frame. It waits for the 6 second delay_between_launches. After this period a V-shaped area in front of the bay is scanned, up to 5000 meters distance. When this area is clear, the next ship launches, if not, the delay timer is reset and waits another 6 seconds. That does mean that when a ship takes a second more to launch, the delay_between_launches could stay the same or become 6 seconds longer.

And it causes mothers to jump out before their last escorts haven't even been launched. This seems a clear bug to me, and I don't recall this ever happening in Oolite 1.72 or so

. In 1.72 this definitely happened often. With 1.72 and 1.73, a ship requesting docking permission could be granted a docking slot, before the last escort had launched. That escort had to wait until the new ship had docked, and that was often to long for following mom.

[Commander McLane]

Can the delay timer be shortened, let's say to 3 seconds, or even 2 seconds? This could at least reduce the number of very long pauses.

And it causes mothers to jump out before their last escorts haven't even been launched. This seems a clear bug to me, and I don't recall this ever happening in Oolite 1.72 or so

. In 1.72 this definitely happened often. With 1.72 and 1.73, a ship requesting docking permission could be granted a docking slot, before the last escort had launched. That escort had to wait until the new ship had docked, and that was often to long for following mom.

Okay, but I'm not talking about interrupted launch processes, but about straight launch processes. If an Anaconda and its six escorts launched perfectly in 1.72, they all left the system together. If an Anaconda and its six escorts launch perfectly in trunk, they will never leave the system together. There isn't a snowball's chance in hell that the last (perhaps even the last two) escorts will launch before the mother is gone. It will always fail. And this cannot be right.

[JensAyton]

I agree that the retry interval should be shorter.

Ideally, a ship wouldn’t jump while waiting for its escorts to launch, but that would almost certainly be too big a change for beta.

[Eric Walch]

There isn't a snowball's chance in hell that the last (perhaps even the last two) escorts will launch before the mother is gone. It will always fail. And this cannot be right.

I don't say its right that the last escort misses his mother jump. It is just that I never witnessed this since 1.72. I just rechecked with 1.5.1 and trunk. In both cases the interval between escorts was always 6 seconds and the last escort had almost reached the mother when she jumped. There had already been 3 new launches from other ships.

Apparently with other conditions, the escorts don't clear the station soon enough on your setup and the next launch is postponed another 6 seconds. And that seems to much. I agree with Ahruman that after the first 6 second interval, the next retry should not wait 6 but probably just 2 seconds. I just changed it in my oolite copy to test it.

[Switeck]

I thoroughly tested these AI additions. And it really is needed there. It can get the message there for two reasons.
- While negotiating for new business, it can already have a new owner before the AI switched states. There will be a pending "ESCORTING" message about that were the AI will react on on the next update. However, it is still possible that the new mother immediately issues a groupAttack command after accepting the escort. I added a new AI message for the mother when see accepts an escort. This should also prevent the buggy situation that the mother is attacking while the new escort is just escorting instead of helping.
- An other reason for the getting the message is that the mother looses her references to the escort group when jumping out. But she keeps a reference to the normal group. And when mom is no part of a bigger group herself, this normal group will be identical to the escort group. So, while not having escorts yet, when mom issues a groupAttack, this still might go to the former escorts.

But the only way to understand all this is to switch AI logging on and carefully examine the order of the messages. There are sometimes surprises. e.g. when mom jumps out, the escorts will get a TARGET_LOST message. But when the player immediately follows mom, it can happen that the escort AI is also frozen before the TARGET_LOST is executed. But when negotiating with mom in the new system, this TARGET_LOST message could be still pending and interpreted wrong. Therefor I added a "dropMessages: " instruction. These things become only obvious after AI logging ant trying to understand each logged line.

It takes me quite a long while to make sense of all this...weeks/months even.

The importance of accepting a groupAttack command while the would-be escort (that is already in the same group?) seems to depend on how long they are stuck in the "BEGIN_BUSINESS"/"EXIT_WORMHOLE"/"CLEAR_STATION" sections and whether pending messages are forgotten jumping between sections. (Such as going from "BEGIN_BUSINESS" to "FLYING_ESCORT".) It's ok if the new escort is "stupid" for 1-3 seconds, so long as it then respond to enemy attacks on the mothership or other escorts. Any longer than that and it's terrible. The addition of extra lines to catch conditions that "fall through" the obvious tests almost seems like trying to hack around a very unwieldy and somewhat unreliable AI state engine.

I'm still stumped by my Thargons not working as desired in my AI.plist script. They won't follow the Thargoids around, so they quickly get left behind and go inactive. Thargoids never recover them either, so I might ought to start calling them Thargoid droppings. Her's the current code I'm testing:

Code: Select all

{
	GLOBAL = { ENTER = ("setStateTo: ATTACK_SHIP"); };
	"ATTACK_SHIP" = {
		ENTER = (performAttack);
		"INCOMING_MISSILE" = ("messageMother: INCOMING_MISSILE");
		"TARGET_DESTROYED" = ("setStateTo: CHECK_FOR_CONTROL");
		"TARGET_LOST" = ("setStateTo: CHECK_FOR_CONTROL");
		"NOTHING_FOUND" = ("setStateTo: CHECK_FOR_CONTROL");
		UPDATE = ("pauseAI: 5.0", thargonCheckMother);
	};
	"CHECK_FOR_CONTROL" = {
		ENTER = ("dropMessages: NOTHING_FOUND", performIdle, "setSpeedTo: 0.0", performTumble);
		"TARGET_FOUND" = (setTargetToFoundTarget, setDestinationToTarget, "setDesiredRangeTo: 1000.0", checkCourseToDestination);
		"COURSE_OK" = ("setSpeedFactorTo: 1", performFlyToRangeFromDestination, "pauseAI: 20.0", "rollD: 1");
		"DESIRED_RANGE_ACHIEVED" = ("rollD: 1");
		"ROLL_1" = ("setStateTo: LOOK_FOR_TARGETS");
		"NOTHING_FOUND" = (becomeUncontrolledThargon);
		UPDATE = ("pauseAI: 10.0", thargonCheckMother);
	};
	"LOOK_FOR_TARGETS" = {
		ENTER = (scanForNonThargoid, "pauseAI: 1.0");
		"TARGET_FOUND" = (setTargetToFoundTarget, "setStateTo: ATTACK_SHIP");
		"NOTHING_FOUND" = ("setStateTo: CHECK_FOR_CONTROL");
		UPDATE = ("pauseAI: 10.0", scanForNonThargoid);
	};
}

The use of ROLL_1 is only as a delay of sorts until "DESIRED_RANGE_ACHIEVED" occurs.

[Eric Walch]

Code: Select all

		"DESIRED_RANGE_ACHIEVED" = ("rollD: 1");
		"ROLL_1" = ("setStateTo: LOOK_FOR_TARGETS");

The use of ROLL_1 is only as a delay of sorts until "DESIRED_RANGE_ACHIEVED" occurs.

I don't see what kind of delay you planned. You use a one-sided dice. So it will always generate a 1. And rollD is a reactToMessage that does not wait until the next update. Your code does exactly the same as:

Code: Select all

		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: LOOK_FOR_TARGETS");

When you want a delay, try:

Code: Select all

		"DESIRED_RANGE_ACHIEVED" = ("messageSelf: MY_CUSTOM_MESSAGE", "pauseAI: 2");
		"MY_CUSTOM_MESSAGE" = ("setStateTo: LOOK_FOR_TARGETS");

[Commander McLane]

EDIT: ninja'd by Eric, but I'm still posting because of the time stamps in the log

The use of ROLL_1 is only as a delay of sorts until "DESIRED_RANGE_ACHIEVED" occurs.

That doesn't work. rollD: doesn't delay anything.

As an example I have modified the HEAD_FOR_PLANET state of the normal route1traderAI. Instead of

Code: Select all

        ATTACKED =         (
            "setAITo: traderInterceptAI.plist",
            fightOrFleeHostiles
        );

I have added

Code: Select all

        ATTACKED =         (
            "rollD: 1"
        );
        "ROLL_1" =         (
            "setAITo: traderInterceptAI.plist",
            fightOrFleeHostiles
        );

Then I have spawned a trader, made sure he's in HEAD_FOR_PLANET, and attacked him. Here's the result in the log:

Code: Select all

09:05:21.669 [ai.message.receive]: AI route1traderAI.plist for Cobra Courier 201 in state 'HEAD_FOR_PLANET' receives message 'ATTACKED'. Context: unspecified, stack depth: 0
09:05:21.669 [ai.takeAction]: Cobra Courier 201 to take action rollD: 1
  09:05:21.669 [ai.message.receive]: AI route1traderAI.plist for Cobra Courier 201 in state 'HEAD_FOR_PLANET' receives message 'ROLL_1'. Context: rollD:, stack depth: 1
  09:05:21.669 [ai.takeAction]: Cobra Courier 201 to take action setAITo: traderInterceptAI.plist
    09:05:21.697 [ai.stack.push]: Pushing state machine for <AI 0x11eadd690>{"route1traderAI.plist" in state: "HEAD_FOR_PLANET" for Cobra Courier 201}
    09:05:21.697 [ai.message.receive]: AI traderInterceptAI.plist for Cobra Courier 201 in state 'GLOBAL' receives message 'ENTER'. Context: changing AI, stack depth: 2
  09:05:21.697 [ai.takeAction]: Cobra Courier 201 to take action fightOrFleeHostiles

Look at the time stamps. The ship receives the ATTACKED message and rolls a die the very same millisecond. It then receives the ROLL_1 message the very same millisecond. In other words: there is no delay whatsoever, not even for a single millisecond.

Not only ATTACKED, but also ROLL_n are priority messages which are sent instantaneously, not waiting for the next update time. See [wiki]State_machine[/wiki] for an explanation of the difference between normal and priority messages. And see [wiki]OXP_howto_AI[/wiki] for referencing which messages are priority messages. They appear in boldface, while normal messages are printed in plain face.


P.S.: I only now discovered the [wiki]Messages[/wiki] page via its link on the [wiki]State_machine[/wiki] page. Didn't know that it existed, but I always wanted a complete list of AI messages. However, this page hasn't been updated since 2006 and is therefore clearly out of date. But it could perhaps get updated with all new AI messages, a distinction between normal and priority messages, and—most important—be taken out of the Oolite category page and moved to the Oolite scripting category page. Perhaps it should also be renamed to OXP_howto_AI-AI_messages or something like that, so that it appears right beneath the OXP_howto_AI link on the category page. Or all AI-related pages could get their own subcategory, or something like that.

[Switeck]

Thanks to your help, here's part of what my code evolved to:

Code: Select all

	"CHECK_FOR_CONTROL" = {
		ENTER = ("dropMessages: NOTHING_FOUND", performIdle, "setSpeedTo: 0.0", performTumble, thargonCheckMother);
		"TARGET_FOUND" = (setTargetToFoundTarget, setDestinationToTarget, "setDesiredRangeTo: 1000.0", "setSpeedFactorTo: 1", performFlyToRangeFromDestination, "pauseAI: 20.0");
		"DESIRED_RANGE_ACHIEVED" = ("dropMessages: NOTHING_FOUND", "messageSelf: SHORT_DELAY", "pauseAI: 2");
		"SHORT_DELAY" = ("dropMessages: NOTHING_FOUND", "setStateTo: LOOK_FOR_TARGETS");
		"NOTHING_FOUND" = (becomeUncontrolledThargon);
		UPDATE = ("pauseAI: 10.0", thargonCheckMother);
	};
	"LOOK_FOR_TARGETS" = {
		ENTER = ("dropMessages: TARGET_FOUND", scanForNonThargoid, "pauseAI: 1.0");

The rest of the code is unchanged from above.
Thargons/Tharglets still quit moving, fall behind Thargoids, and become inactive tumbling targets.
I don't know if what I'm trying to do is simply impossible or I'm just proving too stupid to do it.

[maik]

Just updated it in the [wiki]OXP List[/wiki]. Did I assume correctly that it works with Oolite 1.75?

[Commander McLane]

I think it's WIP. But Switeck himself can answer that better.

[Switeck]

It works with v1.75.2 but the released version 0.3 doesn't do as well with some of the AI.plist types as v1.75.2's own updated replacements do. Because it's totally lacking .js scripts, there's little that can "break" in the mod...though I've certainly given many of the files minor tweaks since then.

What has been stopping me from updating it further is the utter frustration I'm having with Thargoids/Thargons, exitingTraderAI, and escortAI. The test versions I'm mucking with right now are failures. I can dumb the Thargons down to levels where they'll work again, but they won't follow Thargoid Warships around. Thargoids themselves work ok, they just lack most forms of direct cooperation that most NPC ships have when put in a group -- their main problem is simply not interacting with Thargons like mothership/escorts normally do.

[Fatleaf]

This maybe something that has been addressed already (sorry if it has) but I'm starting off with the "Broke Adder." I went asteroid shooting and amassed the colossal sum of 7.5cr. the F3 screen says fuel is 6cr but for some reason (unknown to me) I get the "beep" that you get when something is beyond your credit range. I can't buy 6cr worth of fuel with 7.5cr...?!?

[Switeck]

I assume since you have no fuel to start with that 6 credits is enough to max out your Adder's fuel. (7 LY worth)
...But it's probably still assuming fuel costs 2 credits/LY as far as checking whether you have enough credits to buy it.
In short, a core game bug.
You're using v1.75.2?

This describes my exitingTraderAI and escortAI problems:
https://bb.oolite.space/viewtopic.php?f=3&t=9937