Add 'abs' coordinate system to the legacy addShip methods?

[Kaks]

I'm using javascript to do some scripting - oxp coming real soon now!

One problem I had was: I knew where I wanted to place some ships, in absoulute coordinates, but couldn't figure out how they would translate to the legacy methods. I ended up calling legacy_addShip to create the ships at witchpoint, then putting them in their right place one by one.

If the developers were to add an 'abs' coordinate system to the legacy methods, all my ships position problems would be over.
Ah, the joys of simply typing

system.legacy_addShipsWithinRadius('pirate', 3,'abs',player.position,16000);

I don't know much about obj-c, and a lot less about how Oolite works, but hopefully all this would need is to bypass all transforms if the coordinates system is 'abs'.

Cheers,

Kaks

[Commander McLane]

At least it would be very handy to know which transformations are used from the internal coordinate system to let's say pwm. Could you find that out?

As far as my research went, the internal system's origin seems to be the witchpoint and it's z-axis seems to be along the wpm's z-axis, only pointing in the other direction (away from the planet). So the first part of the transformation would be: internal system ^= -wpm. But there is a second part. The x- and y-axes get rotated. There seems to be an angle of about 32 degrees (or perhaps 90-32; or 90+32; or 180-32; or 180+32; or 270-32; or 270+32; or 360-32; I don't actually know which one) between the internal system and the wpm-system. But nobody knows the exact angle. And nobody seems to know the reason for these transformations. Why isn't the internal coordinate system connected to the witchpoint-planet-sun plane? A lot of questions, no answers.

[Kaks]

Well, I had a bit of a look at the obj-c code but it's pretty difficult to follow. What seems to be happening, is this: the three important entities - witchpoint, planet, sun, are placed semi-randomly within a 'box' of space. The triangle formed by these 3 objects defines the base plane for the 'pws' system, which is at a random angle compared to the 'real' base plane.

Looks like the present 'pws' coordinate system came about to make it easy to script stuff with the old script.plist system. You can quickly place objects around each of the main points without having to worry about their 'real' position.

Luckily, in javascript using the real position isn't really a problem. You can do a lot of calculations based on player.position without having to worry about what the three numbers inside player.position actually are!

I thought about calculating pws for hotrods.oxp, but I couldn't think of a way to get to the witchpoint object.

Without that, we'll never be able to get to the pws coordinates...

[Commander McLane]

The triangle formed by these 3 objects defines the base plane for the 'pws' system, which is at a random angle compared to the 'real' base plane.

I doubt that it is really random, as it seems to be very consistently these odd 32 degrees I mentioned.

Looks like the present 'pws' coordinate system came about to make it easy to script stuff with the old script.plist system. You can quickly place objects around each of the main points without having to worry about their 'real' position.

Yes, of course. And I hope you are aware that there are a total of 24 different coordinate systems for scripting purposes? It's pwm, wpm, psm, spm, wsm, swm, pwp, wpp, psp, spp, wsp, swp, pws, wps, pss, sps, wss, sws, pwu, wpu, psu, spu, wsu and swu (although not all combinations are equally useful). See the Methods-page of the wiki for explanations.

I thought about calculating pws for hotrods.oxp, but I couldn't think of a way to get to the witchpoint object.

Without that, we'll never be able to get to the pws coordinates...

As per the explanation above, you don't need a pws-coordinate in order to get close to the witchpoint. Choose any coordinate system that starts with "w", and you're already there.

[JensAyton]

As Kaks indicates, the JavaScript Vector class provides ways to calculate positions of things relative to other things without caring about actual numerical co-ordinates. As such, my plan for the coming-eventually non-legacy addShips() method is to take absolute co-ordinates, and to provide functions for converting to and from the named co-ordinate systems.

[Kaks]

Arhuman:
Good to know! In a fit of lazyness, I was hoping that introducing 'abs' would completely remove the need to convert back and forth form internal coordinates to 'pwu', 'spm', etc.!

Commander McLane:
Yes, I did see the Methods page, but no, I still don't quite understand how to get the witchpoint coordinates in absolute positioning terms.... wait!

It's a bit messsy but.... Ok, I just realized there's a ship with role 'buoy-witchpoint' set precisely at wpm 0 0 0.

Still, we can't be sure that there's only one 'buoy-witchpoint' in the system - other OXPs might spawn a false witchpoint for whatever reason...

The only really sure way to get the really real witchpoint buoy is to create a ship with a unique role( a copy of a metal shard with role 'wbuoy-bestfriend') with that you could do:

Code: Select all

system.legacy_addShipsAtPrecisely('wbuoy-bestfriend',1,'wpm',[0,0,0]);
let tmp=system.shipsWithRole('wbuoy-bestfriend')[0];
let wpoint=system.shipsWithRole('buoy-witchpoint',tmp)[0]; 
//todo: remove tmp!

now that have all the 3 main points in space - sun and planet are easier to get, we can start doing the calculations to convert abs to 'pwm' etc... however, 3D maths is not exactly for the faint hearted...

Speaking as a faint hearted person...

[Commander McLane]

I know of no OXP that creates a false witchpoint buoy. And why should it do that? And why should you care?

Anyway: The witchpoint, which is one of the three fixpoints in the system (as are planet and sun) is therefore also one of the possible origins. To be precise: it's the origin of all systems whose abbreviations start with "w" (for "witchpoint". So wpm 0 0 0 (z-axis points toward the center of the planet, distances are measured in meters) is exactly the witchpoint, as much is wsp 0 0 0 (z-axis points toward the center of the sun, distances are measured in planetary radii).

[Kaks]

You're right. No-one has made an oxp that adds a witchpoint buoy. I suppose that the years of software maintenance have taken their toll!
<_<
>_>
Ok, I'll skip the 'paranoid mode' bits.

Why should I care about the witchpoint position? Because in the internal coordinates system, used by the engine and javascript alike, the fixpoints are not fixed, and to translate from absolute to wpm I need the absolute coordinates of those 3 fixpoints.

pwm 0 0 0 = wpu 0 0 1 = spu 0 0 1 = abs ? ? ?

Neither planet, nor sun, nor witchpoint are ever in absolute position (0,0,0).

Ok I've just made a mini oxp to make it slightly clearer: pwstest.zip

What it does: whenever you leave a station or jump into a new system, it will display the 3 fixpoints in absolute coordinates, it also writes them to the log. This is what I got from the first 3 systems:

Code: Select all

2008-01-28 15:06:54.171 oolite[5924] [script.pws.test]: Lave: W (-8700, -6700, -2500) P (0, 0, 617400) S (-782892, -340254, 919514)
2008-01-28 15:07:28.734 oolite[5924] [script.pws.test]: Leesti: W (-4900, -3500, 4400) P (0, 0, 401050) S (-403002, -35200.1, 734814)
2008-01-28 15:08:50.343 oolite[5924] [script.pws.test]: Diso: W (2500, 3600, -6600) P (0, 0, 677050) S (1.08895e+006, 404170, 541212)

Drats! Commander McLane, I was hoping for someone else to solve the problem for me, but it looks like I'm already a third of the way there, thanks to your searching questions! Curses!


It all seemed so easy when I saw this snippet of information inside the wiki

// in witchspace (== no sun) coordinates are absolute irrespective of the system used

I thought it might be relatively painless for either ahruman, another_commander, or dajit, to change the relevant code from something like

Code: Select all

if (witchspace) 

to something like

Code: Select all

if(witchspace || coordinatesString=='abs')

'Course, nothing in life comes easy. I suppose I should have stuck to the day job!

[Commander McLane]

Code: Select all

2008-01-28 15:06:54.171 oolite[5924] [script.pws.test]: Lave: W (-8700, -6700, -2500) P (0, 0, 617400) S (-782892, -340254, 919514)
2008-01-28 15:07:28.734 oolite[5924] [script.pws.test]: Leesti: W (-4900, -3500, 4400) P (0, 0, 401050) S (-403002, -35200.1, 734814)
2008-01-28 15:08:50.343 oolite[5924] [script.pws.test]: Diso: W (2500, 3600, -6600) P (0, 0, 677050) S (1.08895e+006, 404170, 541212)

Mind you, it seems I am not too far off with my speculations! And just to clarify this: I have never ever looked into the code of the game, I don't even have it! All my conclusions are from observing coordinates while I am moving through the Ooniverse. And I think I did it pretty well. Because I predicted the outcome of your test quite close, didn't I?

So what do your three systems in common: (1) The witchpoint is close to the absolut origin. Not exactly at it, but very close. And that's actually what I observed (you will find that in older posts of mine): The z-axis of wpm or pwm is just a little bit off the absolut z-axis. (2) The absolut z-axis points toward the center of the planet. In all cases the planet is located at 0 0 n, with n being a random number determined by the seed.

And that's exactly what I told you before.

Now the only thing that's left to do for you is to find whether there is a rule that determines the offset of the z-axis, and of course determine the rotation-angle for the x- and y-axes, and then you've got all you need for a transformation formula from absolut coordinates into pwm (and vice versa). And it is this transformation which is needed most of the time, because in-flight coordinates are displayed as pwm, so this is what a scripter reads in order to find out where he is, and place an object there.

[aegidian]

The rationale for not providing an absolute position among the coordinate systems was that since the positions of planets and suns are pseudo randomly generated, it'd be more convenient to use those as the deciding positions for a coordinate system as most scripts would like to place objects relative to those fixed points.

There's no reason not to include such a system if it's in demand, and it would be a short coding job - go do it!

[Commander McLane]

The rationale for not providing an absolute position among the coordinate systems was that since the positions of planets and suns are pseudo randomly generated, it'd be more convenient to use those as the deciding positions for a coordinate system as most scripts would like to place objects relative to those fixed points.

There is one notable exception to this rule: If you want to place a new planet somewhere in the system and a station and/or ships closeby (see Tianve.oxp as an example), you are thrown back to trial and error, as the planet is placed within the internal system and everything else within one of the scripting systems. I noticed that problem, when I for ghost_of_the_past.oxp (WIP) created two new planets far out in the system and wanted to spawn a ship exactly between them. Not easy, requires a lot of flying, coordinate-reading and calculating.

There's no reason not to include such a system if it's in demand, and it would be a short coding job - go do it!

For the case mentioned this would be really helpful, so I'm happy to push whoever volunteers to do it.

[Kaks]

Commander McLane, any one of my old maths professors would have loved to have you as a student...

@Aegidian: <Ah-ten-shun>Sah!

[Commander McLane]

Commander McLane, any one of my old maths professors would have loved to have you as a student...

Loooong time ago I did do Maths in my Abitur as a Leistungskurs (sorry to all who went through an English-style education system; this isn't really translatable). ... And my wife has her PhD (actually Dr. rer. nat.) in Theoretical Physics .

[Hoopy]

I did a Physics masters degree (a good portion of which was cosmology)and I do sometimes find I have to contain myself when thinking about aspects of Oolite.

Just keep repeating, it's a game not a simulation - that's why it's so much fun!

Although sometimes i think it might be fun to add something like Epimetheus and Janus (but greatly speeded up so you could watch it over a minute or so instead of 4 years!)

http://www.planetary.org/news/2006/0120 ... ce_of.html

[Kaks]

Hmm, physics! :D

Anyways, I've got a working abs2pwm function inside hotrods.oxp now, just to see if it could be done. In the end, the math wasn't as hairy as I half remembered...

It'll do for a temporary solution, before an absolute coordinates ship creation method is coded in...

Cheers,

Kaks.