Oolite Bulletins

Posted: **Wed Apr 20, 2011 8:07 am**

Just saying that I'm very happy to see you guys making this effort.

Eliminating the friendly-fire-problems without having to retort to complicated checks in AI+script would be a major step forward, even if it catches 'only' most cases.

Posted: **Wed Apr 20, 2011 8:17 am**

Commander McLane wrote:
Just saying that I'm very happy to see you guys making this effort.

Eliminating the friendly-fire-problems without having to retort to complicated checks in AI+script would be a major step forward, even if it catches 'only' most cases.

But it does probably mean that you have to rewrite part of your cataclysme end-game. There a captured thargoid ship helps killing the thargoid invasion.

Or am I misremembering that the captured ship helps in the battle?

Posted: **Wed Apr 20, 2011 8:49 am**

Eric Walch wrote:
Commander McLane wrote:
Just saying that I'm very happy to see you guys making this effort.

Eliminating the friendly-fire-problems without having to retort to complicated checks in AI+script would be a major step forward, even if it catches 'only' most cases.
But it does probably mean that you have to rewrite part of your cataclysme end-game. There a captured thargoid ship helps killing the thargoid invasion.
Or am I misremembering that the captured ship helps in the battle?

It does help, but it's a reverse-engineered Thargoid ship, not a captured one (that blew up in an earlier stage; perhaps you rescued the engineer who was tinkering with it at the time

). Therefore it doesn't have Thargoid scan class and will happily work together with other non-Thargoids.

And I have to re-write Cataclysm anyway some day. It doesn't work anymore at least since 1.74. It's just such an overwhelming task, given the size of the script.

Posted: **Wed Apr 20, 2011 9:45 am**

Eric Walch wrote:
another_commander wrote:
Edit: Actually, I think it's probably best to put the friendly check inside -setTargetToPrimargyAggressor. addTarget is used in the code also for things other than combat targets.
I also think that adding it in setTargetToPrimargyAggressor is the best location. This command already has a random component in it when used from within a combat situation, that makes that it is not always setting a target and current AI code should already be prepared for that. And it still leaves the option to deliberately start a thargoid-thargoid war by using other commands for targeting. (setTargetToFoundTarget or by using JS for setting a target)

I am not sure if we need the police check, as this is already dealt at other places in the code. But, doing it all in one place is probably clearer for the future.

I'm all for consolidating the random check AND friendly fire check in 1 place, setTargetToPrimargyAggressor.

I do think it might be useful to OXP designers if they could set and change via scripts how likely a particular ship is to "go postal" on its allies if they hit it.

Pirates are only loosely allied and would probably attack each other at the drop of a hat. There really shouldn't be a unified pirate side to begin with -- each pirate group may have NO love for other pirate groups. Or they may be mostly or all allied because they're really a revolutionary/insurgency force in-system.
Police would never counter-attack each other from friendly fire.
Traders almost never would. If anything, they'd probably have a frustration level that rises with each hit from an "ally". Sort of like a morale check. Failing a morale check can cause them to flee (most likely) or attack back (if really frustrated.)

Thargoids...well, that's depending on whether they're a hive mind or highly individual or all focused on the same goals for other reasons.

Posted: **Wed Apr 20, 2011 10:16 am**

I assume that the check would have to be flexible anyway.

Equal scanClass, for instance, would only be a friendly-fire-criterion for Thargoids and possibly for CLASS_POLICE and CLASS_MILITARY, but obviously not for CLASS_NEUTRAL, which is shared by everybody else except stations.

Membership in the same group would be another criterion, and a very hard one at that. It would include mother & its escorts, and would also include wolfpacks, but not different wolfpacks with each other.

Posted: **Wed Apr 20, 2011 10:22 am**

I am about to introduce this method in ShipEntity, which will be called by -setTargetToPrimaryAggressor:

Code: Select all

- (BOOL) isFriendlyTo:(ShipEntity *)otherShip
{
	BOOL isFriendly = NO;
	OOShipGroup	*myGroup = [self group];
	OOShipGroup	*otherGroup = [otherShip group];
	
	if ((otherShip == self) || ([self isPolice] && [otherShip isPolice]) || ([self isThargoid] && [otherShip isThargoid]) ||
							(myGroup != nil && otherGroup != nil && (myGroup == otherGroup || [otherGroup leader] == self)) ||
							([self scanClass] == CLASS_MILITARY && [otherShip scanClass] == CLASS_MILITARY))
	{
		isFriendly = YES;
	}
	
	return isFriendly;
}

The code should be quite easy to read and shows the checks that are actually made, leading up to a decision whether a ship is firendly to another or not.

Posted: **Wed Apr 20, 2011 11:22 am**

there should only be a given numbr of times you can friendly-fire something before it gets p155ed-off and logs you as an enemy tho, surely?

Posted: **Wed Apr 20, 2011 12:09 pm**

Killer Wolf wrote:
there should only be a given numbr of times you can friendly-fire something before it gets p155ed-off and logs you as an enemy tho, surely?

I think that it would be best if we let scripters decide that. For now, battles starting up as a result of one single friendly fire shot seems to be a more imminent bug to fix rather than the possibility of repeated accidental shots not triggering a hostile reaction. As an additional clarification, the fix is not applicable to any player actions, since it is called only within -setTargetToPrimaryAggressor, which is a method called by non-player ship AIs.

Posted: **Wed Apr 20, 2011 12:50 pm**

The new code which will hopefully fix friendly fire incidents is now in trunk, r4518. Please test the nightly tomorrow and report back if any problems are encountered.

Posted: **Wed Apr 20, 2011 6:22 pm**

I will certainly be testing it.

Ok, in the trial fix ...I still see Thargoid warships trade a few hits (or misses). But after maybe 2-5 shots, they go back to shooting at me. Good enough IMO.

Posted: **Wed Apr 27, 2011 10:43 pm**

Now for some AI.plist confusion on my part. I'm checking the changes in Oolite's AI files in the latest trunk relative some older ~v1.74.2 AI files.

In escortAI.plist something strikes me as really odd. In the "LOOK_FOR_BUSINESS" section, before I would assume the NPC ship is either an escort or possibly a member of a group there is this line:
"GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setStateTo: FLYING_ESCORT", "setAITo: interceptAI.plist");
How would it ever get that message?

Really leaving that wormhole in a hurry:

Code: Select all

	"EXIT_WORMHOLE" = {
		ENTER = (setDestinationToCurrentLocation, "setDesiredRangeTo: 7500.0", "setSpeedTo: 50", performFlyToRangeFromDestination);

Maybe "setSpeedTo: 0.50" was intended instead?

My other problem with escorts is I'm seeing them hanging around after their mother hyperspaces out instead of trying to enter the wormhole themselves. Is this because the mother ship's AI lacks a wormholeEscorts line in an appropriate place?

For route2sunskimAI.plist, I find it odd that it appears they can be <1 km from a star and can still hyperspace out. Or will they be forced into:
"WITCHSPACE BLOCKED" = (setTargetToFoundTarget, setDestinationWithinTarget, "setDesiredRangeTo: 10000.0", performFlyToRangeFromDestination);
...at least once?

Posted: **Thu Apr 28, 2011 6:12 am**

Switeck wrote:
Really leaving that wormhole in a hurry:
Code: Select all
	"EXIT_WORMHOLE" = {
		ENTER = (setDestinationToCurrentLocation, "setDesiredRangeTo: 7500.0", "setSpeedTo: 50", performFlyToRangeFromDestination);
Maybe "setSpeedTo: 0.50" was intended instead?

There's no hurry. 50 m/s is a reasonably slow speed. 0.5 m/s would be practically not moving at all, and the following ship would crash into the leader. After all, a ship may well be 100 meters long, and the following ship may spawn at the very same place only 2 seconds later. Therefore it's necessary that the leader gets 100 meters away, not only 1 meter. (It's setSpeedTo:, not setSpeed[color=#FF0000]Factor[/color]To

Switeck wrote:
My other problem with escorts is I'm seeing them hanging around after their mother hyperspaces out instead of trying to enter the wormhole themselves. Is this because the mother ship's AI lacks a wormholeEscorts line in an appropriate place?

Seconded. I witnessed the same thing again only yesterday in rev 4524. A mother launched from the main station with four escorts after her, then followed an apparently unrelated trader, and finally the last two escorts. By that time the mother had already jumped out, and the last escorts were orphaned right from the start. But also among the first four escorts only two followed their mother through its wormhole. I can't explain why this happens. The mother was a Monitor, by the way. Perhaps the ship is too fast and reaches jump distance too quickly?

Switeck wrote:
For route2sunskimAI.plist, I find it odd that it appears they can be <1 km from a star and can still hyperspace out. Or will they be forced into:
"WITCHSPACE BLOCKED" = (setTargetToFoundTarget, setDestinationWithinTarget, "setDesiredRangeTo: 10000.0", performFlyToRangeFromDestination);
...at least once?

I guess so, depending on the star's size. Each performHyperSpaceExit first calculates whether there is a blocking mass in the vicinity. If no, the ship receives WITCHSPACE_OKAY, if yes, it receives WITCHSPACE BLOCKED. If the ship doesn't have enough fuel or no motor, it receives WITCHSPACE UNAVAILABLE.

Posted: **Thu Apr 28, 2011 7:02 am**

Commander McLane wrote:
(It's setSpeedTo:, not setSpeed[color=#FF0000]Factor[/color]To

Switeck wrote:
My other problem with escorts is I'm seeing them hanging around after their mother hyperspaces out instead of trying to enter the wormhole themselves. Is this because the mother ship's AI lacks a wormholeEscorts line in an appropriate place?
Seconded. I witnessed the same thing again only yesterday in rev 4524. A mother launched from the main station with four escorts after her, then followed an apparently unrelated trader, and finally the last two escorts. By that time the mother had already jumped out, and the last escorts were orphaned right from the start. But also among the first four escorts only two followed their mother through its wormhole. I can't explain why this happens. The mother was a Monitor, by the way. Perhaps the ship is too fast and reaches jump distance too quickly?

Only if the escorts fail to leave the station before the Monitor creates/hits a wormhole should that be the case.

I was seeing escorts that just prior were in formation with their mother not enter the mother's wormhole...but I'm pretty sure it was due to a bug in my modified AI.plist, apparently due to this:

Code: Select all

	"ENTER_WORMHOLE" = {
		"TARGET_LOST" = ("setStateTo: LOOK_FOR_BUSINESS");

Removing that line seemed to help considerably. I'd added it assuming the target was the wormhole, but apparently not! I am seeing ships disappearing due to hitting dislocated wormholes -- I'm testing at the Witchpoint Beacon with roughly 20-50 ships at a time all trying to go through existing wormholes or make new wormholes of their own.

Oops on the speed above. I had grown used to setSpeedFactorTo and forgotten the absolute setting setSpeedTo

Posted: **Thu Apr 28, 2011 7:29 am**

Switeck wrote:
Only if the escorts fail to leave the station before the Monitor creates/hits a wormhole should that be the case.

It seems to me that in trunk (and I don't know since when; it could be also in 1.75 or 1.74) the interval between launches is longer than it was before. Each ship has already gone a considerable distance before the next ship gets launched. When the mother reaches jump distance (I just witnessed a case where a Boa jumped out at about 12000 meters away from the station), barely four of is escorts have launched. Escorts number five and six would only leave the station after their mother has already left the system.

This wasn't the case in previous versions of Oolite. Ships would launch fairly quickly after each other. A mother with six escorts had already built up their formation before the mother would reach jump distance and jump out.

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.

Posted: **Thu Apr 28, 2011 7:57 am**

Switeck wrote:
Now for some AI.plist confusion on my part. I'm checking the changes in Oolite's AI files in the latest trunk relative some older ~v1.74.2 AI files.

In escortAI.plist something strikes me as really odd. In the "LOOK_FOR_BUSINESS" section, before I would assume the NPC ship is either an escort or possibly a member of a group there is this line:
"GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setStateTo: FLYING_ESCORT", "setAITo: interceptAI.plist");
How would it ever get that message?

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.

Switeck wrote:
Really leaving that wormhole in a hurry:
Code: Select all
	"EXIT_WORMHOLE" = {
		ENTER = (setDestinationToCurrentLocation, "setDesiredRangeTo: 7500.0", "setSpeedTo: 50", performFlyToRangeFromDestination);
Maybe "setSpeedTo: 0.50" was intended instead?

This is already explained by others. I used speed instead of speedFactor so that all escorts reach their desired range in a known time.

Switeck wrote:
My other problem with escorts is I'm seeing them hanging around after their mother hyperspaces out instead of trying to enter the wormhole themselves. Is this because the mother ship's AI lacks a wormholeEscorts line in an appropriate place?

I don't know. I am not aware of any problems in this area. The location of the wormholeEscorts is critical and only works at a very specific moment. On the other hand, I can't see any reason to use it at an other moment than when mom herself jumps out. After that all AI actions of mom is frozen.[/quote]

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.

Oolite Bulletins

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

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes

Re: Switeck_mod_v0.3b OXP - Ai, Economy, and Ship changes