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

[Kaks]

Thank goodness for that! As I read the post above I started worrying I'd missed something...

These good news also mean you can also do

Code: Select all

shipToTrack=system.addShipsToRoute('trader',1,0,'wp') 

and shipToTrack will always have an EXITED_WITCHSPACE ship in it!

[Switeck]

I'm still working on this! ...slowly.
I've given up on pirates using "checkGroupOddsVersusTarget", simply because it's too primitive and unreliable.
So I had to junk a lot of complex pirateAI code.

I'm also borrowing ideas from Commander McLane's Total Patrol OXP to have Viper police ships sometimes patrol other routes and/or finally dock with the main station.
The odds of Vipers doing anything other than the main shipping route (witchpoint beacon and planet) will be rather low, as I don't want to thin them out too much. My mod isn't adding extra Vipers using a script, so I can't have very many "hiding" on the alternate routes or the main route will seem almost devoid of them. So maybe 10% on alternate routes seems about right.

...Well that's what I'll be trying to do over the next couple days, I can't say it'll all work yet.

Ok, a couple days have passed...
I think it'll be easier to have police Vipers switch randomly between route1patrolAI.plist and route2patrolAI.plist, but predominately using route1patrolAI.plist ...and also have a chance of docking instead of switching.

This will ALL be done near the planet, so that means there's no chance of Vipers going between witchpoint beacon and sun. My guess is this will also make Vipers seem (very) slightly more plentiful very near the planet.

...MORE days pass... (now Dec 18th!)
Much to my dismay, adding in a scanForLoot check to route1patrolAI.plist causes Vipers to go stupid once they near the witchpoint beacon.
I may be doing it wrong, so I'll hold off on my very messy code till I do a couple more checks.

[Switeck]

Ok, these problems are beyond me.

Police Vipers simply do not scoop up escape pods, despite my best efforts to get them to do so. Bounty hunters using the same route1patrolAI.plist *DO* scoop up escape pods...and cargo canisters as well.

Vipers are sometimes "going stupid" once they near the witchpoint beacon. This seems to be caused by them choosing a different destination point after each "OUTBOUND_LOOT" check.

Here's the relevant parts of route1patrolAI.plist that I changed in my attempt to add scanForLoot to police Vipers so they'd scoop escape pods:

Code: Select all

	"HEAD_FOR_WITCHPOINT" =
	{
		ENTER = (setCourseToWitchpoint, checkCourseToDestination);
		"COURSE_OK" = ("commsMessage: Heading for Witchpoint!", setSpeedToCruiseSpeed, performFlyToRangeFromDestination);
		"WAYPOINT_SET" = ("setAITo: gotoWaypointAI.plist");
		"DOCKING_REQUESTED" = ("setAITo: receiveDockingAI.plist");
		"DESIRED_RANGE_ACHIEVED" = ("commsMessage: Heading to Planet", "setStateTo: HEAD_FOR_PLANET");
		"ACCEPT_DISTRESS_CALL" = (setTargetToFoundTarget, deployEscorts, groupAttackTarget);
		"OFFENCE_COMMITTED" = (setTargetToFoundTarget, "markTargetForOffence: 7", deployEscorts, groupAttackTarget);
		"TARGET_FOUND" = (setTargetToFoundTarget, deployEscorts, groupAttackTarget);
		"NOTHING_FOUND" = ("setStateTo: OUTBOUND_LOOT"); // ADDED!
		"INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, deployEscorts, groupAttackTarget);
		ATTACKED = (setTargetToPrimaryAggressor, groupAttackTarget);
		"GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setAITo: interceptAI.plist");
		RESTARTED = (checkAegis);
		UPDATE = (setCourseToWitchpoint, checkCourseToDestination, scanForOffenders, "pauseAI: 10.0");
	};
	"OUTBOUND_LOOT" =
	{
		"GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setAITo: interceptAI.plist");
		"DOCKING_REQUESTED" = ("setSpeedFactorTo: 0.0", "setAITo: receivingDockingAI.plist");
		ATTACKED = (setTargetToPrimaryAggressor, groupAttackTarget);
		"INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, deployEscorts, groupAttackTarget);
		"TARGET_FOUND" = ("commsMessage: Scooping Escape pod!", setTargetToFoundTarget, "setAITo: collectLootAI.plist");
		"NOTHING_FOUND" = ("setStateTo: HEAD_FOR_WITCHPOINT"); // Changed!
		UPDATE = (scanForLoot, "pauseAI: 10.0");
	};

[JensAyton]

Vipers don’t have fuel scoops by default.

[Switeck]

Vipers don’t have fuel scoops by default.

Ah...yeah. Seems shipdata.plist confirms that too.
At least that's a simple "fix" if I care to do so.
(Think I should? Maybe 1 out of 4-10 get fuel scoops? Bleh, then I'd have to give them a low cargo capacity...because that also defaults to none!)
...Ok, I've decided against that -- since the originals didn't have that. I'm not going to grant Vipers a fuel scoop then some cargo space just so they can scoop escape pods.

Vipers don't even seem to have a defined fuel capacity or fuel injection, which seems silly considering so many ships would be able to flee from it because of that weakness.
Viper Interceptors do have fuel injection, but I thought they were rather rare outside of high TL Corporate States?
Stranger still, Viper Pursuit ships...which sound like they'd probably have fuel injectors to fulfill the pursuit role, never do either.
(As for fuel injectors, Viper Pursuit ships probably should have them...but probably only 7.0 fuel capacity not 15.0 like Viper Interceptors have!)

On to the other point...the tough part.
An AI can use scanForLoot or scanForOffenders, but not both at the same time. Having the AI also do a patrol seems problematic, since the "NOTHING_FOUND" jumps out of the "COURSE_OK" and "DESIRED_RANGE_ACHIEVED" checks...meaning when that section is restarted the AI ship will probably be given a slightly different destination.

[Commander McLane]

Don't know why you added the switches between the HEAD_FOR and the _LOOT state?

The generic AI doesn't have that switch, and for a reason. It only switches to the _LOOT state under special circumstances, and only to handle an AI restart better.

If you want the ships to scan for different kinds of things, I still think a JS solution is the best way to go, not an AI solution.

For your problem at the witchpoint: you just have to think it through. The ship is close to the witchpoint. After ten seconds it switches to the OUTBOUND_LOOT state. Ten seconds later it switches back to HEAD_FOR_WITCHPOINT, where in the ENTER part it sets a course to the witchpoint (although it is already there). So it will receive two messages: DESIRED_RANGE_ACHIEVED and NOTHING_FOUND. NOw it depends which one is handled first. If it's the NOTHING_FOUND message, the ship will again switch to OUTBOUND_LOOT (which doesn't change course) and back to HEAD_FOR_WITCHPOINT (which again sets a course to the witchpoint). Rinse, repeat.

It is also possible that you made c&p mistake. For instance the HEAD_FOR_PLANET state could accidentally switch to OUTBOUND_LOOT (instead of INBOUND_LOOT), or INBOUND_LOOT could accidentally switch to HEAD_FOR_WITCHPOINT (instead of HEAD_FOR PLANET).

[Switeck]

Don't know why you added the switches between the HEAD_FOR and the _LOOT state?

What/which switches?

[Smivs]

I think that's the "setStateTo..." part which switches from one state (HEAD_FOR_WITCHPOINT) to another (OUTBOUND_LOOT).

[Switeck]

What's the difference then between this:
UPDATE = (scanForLoot, "pauseAI: 10.0");

and this:
UPDATE = ("pauseAI: 10.0", scanForLoot);

...I'm a little unsure how the state engine handles pauses, either delaying other actions or repeat of the same action. (Such as 2 instances of UPDATE can be running at once?)

[Smivs]

What's the difference then between this:
UPDATE = (scanForLoot, "pauseAI: 10.0");

and this:
UPDATE = ("pauseAI: 10.0", scanForLoot);

...I'm a little unsure how the state engine handles pauses, either delaying other actions or repeat of the same action. (Such as 2 instances of UPDATE can be running at once?)

I'm probably not the best person to help here...my understanding of AIs is extremely limited. My guess is that in the first one, it's scanning for loot then pausing, and in the second scanning for loot after a pause. I don't know what would happen in the first case if it actually finds any loot, but I do know that often the scanForLoot is nothing to do with loot but acts as a sort of re-set. McLane did explain this to me once, but I still don't really get it.
This is part of a message he sent when we discussed this (he was helping me with my Contractor AI at the time, which was based on the route1PatrolAI)

That structure is very clever but one only start to understand it when knowing exact how the AI works. Giles added it with 1.65. The reason is that in 1.65 Giles added a second "setAITo: " command to that state. (gotoWayPointAI and interceptAI) However, both need a different reaction when returning. A simple "RESTARTED" was not enough. So, the only function of "setStateTo: OUTBOUND_LOOT" is to force the AI into a different state so it will return there when returning from the interceptAI. groupAttackTarget sets the ship into an interceptAI through the related GROUP_ATTACK_TARGET reactToMessage.

I actually found it strange that it only would scan for loot after a missile attack and not just after a plain attack. Its already hardcoded that scanclass police can only find pods with slaves in it so police will never go for any cargo. And most police have no scoop or cargobay in the first place.

I hope this is some help, or at least gives some insight.

[JensAyton]

What's the difference then between this:
UPDATE = (scanForLoot, "pauseAI: 10.0");

and this:
UPDATE = ("pauseAI: 10.0", scanForLoot);

Nothing, unless the NOTHING_FOUND/TARGET_FOUND/HOLD_FULL handlers call pauseAI:. All pauseAI: does is specify when the next UPDATE event is sent (along with any queued events). It doesn’t pause the current handler.

[Commander McLane]

McLane did explain this to me once

To be fair and give credit where credit is due, the explanation is not from me, but was given to me by Eric. I just copied it wholesale for you.

That structure is very clever but one only start to understand it when knowing exact how the AI works. Giles added it with 1.65. The reason is that in 1.65 Giles added a second "setAITo: " command to that state. (gotoWayPointAI and interceptAI) However, both need a different reaction when returning. A simple "RESTARTED" was not enough. So, the only function of "setStateTo: OUTBOUND_LOOT" is to force the AI into a different state so it will return there when returning from the interceptAI. groupAttackTarget sets the ship into an interceptAI through the related GROUP_ATTACK_TARGET reactToMessage.

I actually found it strange that it only would scan for loot after a missile attack and not just after a plain attack. Its already hardcoded that scanclass police can only find pods with slaves in it so police will never go for any cargo. And most police have no scoop or cargobay in the first place.

EDIT: fixed typo

[Smivs]

Apologies to Eric, I just quickly copied that part of the message without re-reading the whole thing. Credit where it is due.

[Switeck]

Ok I finally uploaded v0.3 of this mod here:
http://www.mediafire.com/?4hdf24rqr7pru02
...and it has a LOT of changes which I've only hinted about here!

Go back to the 1st post of this message thread for more details.

[Switeck]

...Sadly, there's always something I miss.
Pirates and scavengers stop, sit, and spin sometimes when they're hit while fleeing. I can release a fix for it, but I've got to do a little more testing before then.

This FLEE section works from what I can tell:
"ENERGY_LOW" = ("rollD: 5");
ATTACKED = (setTargetToPrimaryAggressor, "rollD: 2");
"ROLL_1" = (performTumble, "setSpeedFactorTo: 7.0", "setDesiredRangeTo: 27000", performFlee, "pauseAI: 2.0");

Yet this FLEE section doesn't!:
"ENERGY_LOW" = ("rollD: 5", "pauseAI: 3.0");
ATTACKED = (setTargetToPrimaryAggressor, "setDesiredRangeTo: 27000", performFlee, "rollD: 2", "pauseAI: 1.0");
"ROLL_1" = ("setSpeedFactorTo: 7.0", performTumble, "pauseAI: 2.0");

So if you want a fix now, edit pirateAI.plist and scavengerAI.plist files.
route1scavengerAI.plist will need to be edited as well, but it has a slightly more complex FLEE section.

I also saw some unwanted way-outside-their-patrol-route behavior from Police Vipers and bounty hunters. I don't yet know what caused it, but fortunately it seems rare.