Ship attacking itself ?

[Lone_Wolf]

Relevant OXP versions :
dragon 1.72.2
Target Autolock Plus 1.12

Recently i switched to a Dragon-M with 3 turrets, and i also have autolock installed.

Shortly after a fight sometimes i get the message "Auto-locked onto attacker - Dragon M" on screen.
After a few seconds i get target lost, and status is back to yellow/green .
My own Dragon M is the only 1 present in these cases.

At first i thought autolock did something wrong, but decided to check the code.

Code: Select all

this.shipBeingAttacked = function(attacker)
	{
	if(missionVariables.targetAutolock == "TRUE" && player.ship.equipmentStatus("EQ_SCANNER_SHOW_MISSILE_TARGET") == "EQUIPMENT_OK" && player.ship.target == null && attacker && !attacker.isCloaked && !attacker.hasRole("OXP_stealthShip") && !attacker.hasRole("OXP_noAutolock") && !attacker.hasRole("TAP_noAutolock"))
		{
		player.ship.target = attacker;
		player.consoleMessage("Auto-locked onto attacker - " + attacker.displayName + ".",5);
		}
	}

The plasma clouds from turrets take time before they have completely disappeared, so what i THINK happens is this :
I fly through the remnant of a plasma cloud i fired and get some damage from it.
The shipBeingAttacked event is triggered with me as the attacker, since it was my plasma cloud.

If my reasoning is correct, the bug is in shipBeingAttacked, not in the oxps.
Note : this happened first to me in 1.74.x, but i only flew the dragon a short time then.

[Thargoid]

If that's true then you can overcome it in TAP by adding && !attacker.isPlayer to the if's list. But whilst that would sort it out for TAP, for me it would be better to have some equivalent code in the trunk itself to stop the player locking into him (or her, or it) self as that is somewhat strange behaviour. Although I can see that your scenario could be a route to how it could happen.

[Lone_Wolf]

If that's true then you can overcome it in TAP by adding && !attacker.isPlayer to the if's list. But whilst that would sort it out for TAP, for me it would be better to have some equivalent code in the trunk itself to stop the player locking into him (or her, or it) self as that is somewhat strange behaviour. Although I can see that your scenario could be a route to how it could happen.

That change helped indeed with TAP, and i agree with you that this should be done in the game code.

I expect that this behaviour has been present for a long time, but has gone unnoticed.

[another_commander]

I think I know what's going on. The ship reports being hit by itself whenever one of its subentities is hit. The code that does it is in ShipEntity, appears in more than one places (-fireDirectLaserShot: , -fireSubentityLaserShot:range and -fireLaserShotInDirection:direction to be more precise) and looks like this:

Code: Select all

ShipEntity *victim = [UNIVERSE getFirstShipHitByLaserFromShip:self inView:VIEW_FORWARD offset: make_vector(0,0,0) rangeFound: &hit_at_range];
...
if (victim != nil)
{
	ShipEntity *subent = [victim subEntityTakingDamage];
	if (subent != nil && [victim isFrangible])
	{
		// do 1% bleed-through damage...
		[victim takeEnergyDamage: 0.01 * weapon_damage from:subent becauseOf:self];
		victim = subent;
	}
... 

victim is the ship that gets hit. If one of its subentities is receiving the hit, then the takeEnergyDamage method is executed, with argument the subentity itself. In other words, the ship is reportedly hit by its own subentity, which is wrong. The log produced during testing contains this entry:

23:18:38.562 [player.ship.damage]: Player took damage from <ShipEntity 0xf482070>{"fscoop" position: (0, 0, 0) (subentity)} becauseOf <ShipEntity 0xf9b8738>{"GalCop Viper" position: (6548.52, -357045, -29612.2) scanClass: CLASS_POLICE status: STATUS_IN_FLIGHT}
23:18:38.562 [jstest.shipBeingAttacked]: Player ship being attacked by [PlayerShip "Falcon" position: (7499.49, -357442, -28590.5) scanClass: CLASS_PLAYER status: STATUS_IN_FLIGHT]
23:18:38.562 [jstest.shipTakingDamage]: Player ship taking 0 damage by [Ship "GalCop Viper" position: (6548.52, -357045, -29612.2) scanClass: CLASS_POLICE status: STATUS_IN_FLIGHT] by means of energy damage

I believe the line should be corrected to read:

Code: Select all

[victim takeEnergyDamage: 0.01 * weapon_damage from:self becauseOf:self];

[Eric Walch]

I think I know what's going on. The ship reports being hit by itself whenever one of its subentities is hit. The code that does it is in ShipEntity, appears in more than one places (-fireDirectLaserShot: , -fireSubentityLaserShot:range and -fireLaserShotInDirection:direction to be more precise) and looks like this:

Code: Select all

ShipEntity *victim = [UNIVERSE getFirstShipHitByLaserFromShip:self inView:VIEW_FORWARD offset: make_vector(0,0,0) rangeFound: &hit_at_range];
...
 

I am not sure if that is the problem. Lasers are programmed to fire straight ahead. So, how are they supposed to hit its own subentities?. If they do, it is more a matter of wrong laser placement. But you are right that the code does not check for hitting its own subentitie. It looks more logic to make sure that getFirstShipHitByLaserFromShip never returns his own subent.

[another_commander]

I am not sure if that is the problem. Lasers are programmed to fire straight ahead. So, how are they supposed to hit its own subentities?. If they do, it is more a matter of wrong laser placement.

The ship that fires the lasers does not hit its own subentities. The attacker's lasers hit the subentities of the player and because the wrong object is passed as parameter to the takeEnergyDamage method, it appears as if the subentity is attacking the player, when this is not the case.

[Eric Walch]

The attacker's lasers hit the subentities of the player and because the wrong object is passed as parameter to the takeEnergyDamage method, it appears as if the subentity is attacking the player, when this is not the case.

I now see it. You are right, it should be [color=#FF80FF]self[/color] and not subent at all 3 places you indicated.

[another_commander]

The bug should be fixed in r4510. Please test using tomorrow's nightly build.

[Eric Walch]

I think I know what's going on.

Code: Select all

		[victim takeEnergyDamage: 0.01 * weapon_damage from:subent becauseOf:self];... 

That bug has been there already since 1.65. It was wrong, but I can't see how this bug could lead to the reported problem. The from:subent is never used in a JS handler. Instead always the becauseOf:self is transferred. Only when becauseOf:self is no shipEntity the from:subent is used. I have the feeling there still is a problem lurking somewhere.

[another_commander]

That bug has been there already since 1.65. It was wrong, but I can't see how this bug could lead to the reported problem. The from:subent is never used in a JS handler. Instead always the becauseOf:self is transferred. Only when becauseOf:self is no shipEntity the from:subent is used. I have the feeling there still is a problem lurking somewhere.

This is how things go wrong: The third party ship fires a laser hitting the player and the flow of execution reaches this line:

Code: Select all

[victim takeEnergyDamage: 0.01 * weapon_damage from:subent becauseOf:self];

The subent is passed as the parameter ent in the PlayerEntity version of -takeEnergyDamage:

Code: Select all

- (void) takeEnergyDamage:(double)amount from:(Entity *)ent becauseOf:(Entity *)other

In line 3954 of current trunk, the JS handler executed is

Code: Select all

[self doScriptEvent:OOJSID("shipBeingAttacked") withArgument:ent];

If the subentity has been passed as parameter ent in the takeEnergyDamage method, then this is what is going to be passed to the JS handler as well. And that is where the bug lies. The log lines I pasted in one of the previous posts indicate just that.

[Eric Walch]

Thanks for clarification. I did not search good and mainly looked at shipEntity.m and only briefly in playerEntity.m. Now, looking at both it feels strange that for npc the second (other) argument is used as argument in shipBeingAttacked while for the player the first (ent) argument is used.

But not wrong as effectively in both cases the same parent entity is transferred in all cases.