APPROACHING_SURFACE check is wrong.

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

Post Reply
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

APPROACHING_SURFACE check is wrong.

Post by Eric Walch »

Currently there is a bug in calculating the APPROACHING_SURFACE in ShipEntity.m

Code: Select all

	// check planet
	Vector p1 = the_planet->position;
	double cr = the_planet->collision_radius;
	double cr2 = cr * cr;
	OOAegisStatus result = AEGIS_NONE;
	p1.x -= position.x;	p1.y -= position.y;	p1.z -= position.z;
	double d2 = p1.x*p1.x + p1.y*p1.y + p1.z*p1.z;
	
	// check if nearing surface
	BOOL wasNearPlanetSurface = isNearPlanetSurface;
	isNearPlanetSurface = (d2 - cr2 < 3600000.0);
	if ((!wasNearPlanetSurface)&&(isNearPlanetSurface))
		[shipAI reactToMessage:@"APPROACHING_SURFACE"];
	if ((wasNearPlanetSurface)&&(!isNearPlanetSurface))
		[shipAI reactToMessage:@"LEAVING_SURFACE"];
At first look one reads "3600000" and some squares. The root from this value is 1897. It looks a nice distance from the surface. Probably Giles also thought so. But on experimenting with landing shuttles they crashed before passing this border. Looked very strange so I looked better at it. Average radius of a planet is 5000 km or 5,000,000 meter.
d2= square(player to planet center)
c2= square(surface to planet center)

But to set an border even at 100 meter one get:
d2 - c2 = (5,000,100)^2 - (5,000,000)^2 = 1,000,010,000 That is much more than the value of Giles. He is actually setting the border at about 1 meter above the surface and that is within the collision radius of most ships.

I think a border at 500 meter above the surface is close enough and would give a value of: 5,000,250,000 (instead the current value of 3,600,000)

I encountered this bug while playing with the "fallingShuttleAI" script. It never triggered this message. But I also send in a better version of the fallingShuttleAI before 1.70 came out. I think it should be placed in 1.71. Today I uploaded "UPS-Courier.OXP 1.3.4" Within this package I also included a "bigfix OXP". Play with it and see it will be better for the shuttles.

-----
In this package I also included an improved version of the standard "escortAI". The current one has two ways by which escorts can get uncontrolled after an second attack at their mother. Both can be corrected with improved AI routines.

1) When a mothership uses the command fightOrFleeHostile it will internally use the command deployEscorts. This last one gives the target of the mother to the escorts and than uses a setAITo: intercept.plist on all escorts. When ready the escorts fall back to their escort.AI. But when the mother is attacked again by a new aggressor and is using the command fightOrFleeHostile again while the escorts are still in an interceptAI, they get an interceptAI on top of the old one. When they return from this AI they fall back in the first interceptAI with no target and will do nothing there. I think both states need a line:

"RESTARTED"=(exitAI);

This will set them back one more level.

2) Back to the hostile escorts. With such an escort near a station a second attack was programmed to happen. So it did. The attacker was killed, but I found two escorts hanging around doing nothing. They were in the "BEGIN_BUSINESS" state of the escortAI. This was caused by a second bug. For some reason escorts that were flying in a "FLYING_ESCORT" state are put in the "BEGIN_BUSINESS" after returning from a successful attack. This "BEGIN_BUSINESS" has no "UPDATE" option and so it will do nothing with escorts returning in this state. This state needs an update command and also should switch states to "FLYING_ESCORT" when it does.

----
And when someone wants to see what can be done with JS in shipscripts should spawn the ships: "ups_parcel_test1", "ups_parcel_test2", "ups_parcel_test3", "ups_parcel_test4". But don't save after this as one will set new mission variables. And don't add them twice as the reference bug in 1.70 makes that the script does not work after the second spawning.
User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

Post by Hoopy »

does that planet surface calculation affect everything? I had a target in trident down that just raced off and crashed into the surface before i could finish him off. Might he has 'thought' he was well clear of the surface?
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

@Hoopy: yep, that would do it!

@Eric: I'm trying to remember an easy formula that gives the actual distance from the square of the positions, so we can be a bit more precise. Drats, I used to know all that stuff! sorry, momentarily brain dead - a simple sqrt(d2) seems to do the trick. Will test a bit more! ;)
Last edited by Kaks on Thu Feb 21, 2008 2:49 pm, edited 2 times in total.
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

Post by Hoopy »

what formula do you want? the distance between 2 3D vectors?
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

Just wanted to avoid using sqrt, to keep that section of the code running as fast as possible. But I did realize that it would have been too much of a hassle, and went for sqrt after all... :D
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

Post by Hoopy »

you can always just square both sides.

eg if radius of planet is r and distance from planet centre is sqrt( x*x + y*y + z*z)

to see if you're inside the planet compare do
r*r < ( x*x + y*y + z*z )

no sqrt required :)
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

we need the ship ai to notice when it's at some distance from the planet, so it gets a chance to correct course. Ok, the brain cells have just woken up: to check for a distance of 500m from the surface, the test I was looking for is:

Code: Select all

(d2 < cr2+250000+1000*cr)


(a +b)*(a +b) = a*a +b*b +2*a*b !
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

Post by Hoopy »

all makes sense :)
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

Hoopy wrote:
does that planet surface calculation affect everything? I had a target in trident down that just raced off and crashed into the surface before i could finish him off. Might he has 'thought' he was well clear of the surface?
Currently I have only seeing this used by the fallingShuttleAI. But there it does not work. But anything with role "shuttle" can never crash. Other ships using this AI however will crash. Now the border is about at 1 meter above the surface. Its useless there. Raising it a few hundreds meters will create a border the scripts could really use. Than the AI can send a message before the ship crashes.

Changing the formula is not necessary, only the reference value should be raised much.
User avatar
Ark
---- E L I T E ----
---- E L I T E ----
Posts: 664
Joined: Sun Dec 09, 2007 8:22 am
Location: Athens Greece

Post by Ark »

I am wondering if this is related with a strange bug I have noticed.
The mass locked functions strange when you are close (but not so close) to the planet.
To make myself more clear sometimes when I fly towards the station I cannot use the j key. In all those cases I am near the planet but not so close for this to be justified (The attitude bar is full and of course there is nothing in my radar)
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6683
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander »

Eric Walch wrote:
Changing the formula is not necessary, only the reference value should be raised much.
If the formula works correctly, I would rather have that. A high constant value carries the assumption of a constant planet radius (5000km in your example), which is not always the case. With the formula instead, you get a constant reference safety margin of 500m regardless of the radius.
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

another_commander wrote:
If the formula works correctly, I would rather have that. A high constant value carries the assumption of a constant planet radius (5000km in your example), which is not always the case. With the formula instead, you get a constant reference safety margin of 500m regardless of the radius.
Yep, that's the reason I came up with the formula in the first place. With a constant number, the safety margin for an 8000km planet would be 300m, and for a 3500km planet it would be 700m.

In other words, the ai would start avoiding the small planet at almost twice the distance of the big one...

I've double checked, and the formula is indeed working as expected, and practically at the same speed as using a constant value. Thanks for the hard work on killing that bug, Commodore!
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
User avatar
TGHC
---- E L I T E ----
---- E L I T E ----
Posts: 2157
Joined: Mon Jan 31, 2005 4:16 pm
Location: Berkshire, UK

Post by TGHC »

On a similar vein, today I launched from a station and saw three ships line up immediately in front of the navigation beacon, the third ship bumping into the back of the second. I stopped chuckling and was then surprised to see them launch one after the other straight into the ad board and disintegrate. I scooped up the free gratis debris, whilst reflecting that Riedquat ale and witchspace are not good bedfellows!
The Grey Haired Commander has spoken!
OK so I'm a PC user - "you know whats scary? Out of billions of sperm I was the fastest"
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

TGHC wrote:
On a similar vein, today I launched from a station and saw three ships line up immediately in front of the navigation beacon, the third ship bumping into the back of the second. I stopped chuckling and was then surprised to see them launch one after the other straight into the ad board and disintegrate. I scooped up the free gratis debris, whilst reflecting that Riedquat ale and witchspace are not good bedfellows!
I think it is based on the same bug that makes escorts not following their mother. Normally a escort is programmed to fly about 8000 meters straight on and than stop. Just in front of the buoy. But also normally the escorts finding their mother by that time and follow her, long before they reach the buoy. So I think when the other is solved, this will also not happen again.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Kaks wrote:
Just wanted to avoid using sqrt, to keep that section of the code running as fast as possible. But I did realize that it would have been too much of a hassle, and went for sqrt after all... :D
In theory, fast_magnitude(p1) would be what you want (although working in squares is better). In practice, that’s currently the same as magnitude(), which calls sqrtf(). I’ve fixed it up locally to use a semi-fast solution on OS X PowerPC. The fast fast implementation didn’t work on Windows, but should be good enough for this application on other x86 platforms (it was disabled completely because it was being used for laser aiming, which turned out to be non-good). See OOFastInvSqrtf() in OOFastArithmetic.h.

I’ve also cleaned up the code to use fancy-schmancy inline functions like vector_subtract() and magnitude2(). :-)

Edit: Since I’m poking about in this method, I’ll add some script notifications to go with the AI notifications; see Progress thread.
Post Reply