Limit abs coordinates to scripting?

[Kaks]

his station is located at the back of enrece in "abs" coordinates.

Code: Select all

system.legacy_addShipsAtPrecisely("cataclysm_enrece_station", 1, "abs", [-99221.3, -20562.3, 453026])

Strange he used this coordinates. As it is in planetary orbit the planetary radius based "pwp" system would have been more logic to me.

Wait, that means that on win/linux his enrece station is not where he wants it. I suppose I'll try to have screenshots taken in mac & win/linux to see the actual difference...


Going back (almost) to my initial question, what should we do?

I don't think we can keep planet generation as it is now, but shall we change that before or after 1.73?

Shall we leave the abs system available for spawn locations (with warnings for OXP makers)?

Or shall we disallow it from spawn locations, to avoid the kind of positioning problems we had with LA 1.0 if we have to move the planets yet again?

[Thargoid]

I may well be missing something here, but is there a way to differentiate an "absolute absolute" positioning (as in [x y z]) from an "absolute relative" one (as in system.mainStation.position.add([x y z]))?

The former will obviously cause us problems (a la LA 1.0) but the latter is fine, presuming that the entity that you're spawning relative too also moves with the planets etc (or indeed is one of them).

If the latter type isn't possible, then it's essentially removing "abs" completely and that will be a real PITA given that entity.position reads out in absolute terms, and also to be quite honest trying to work in pwm or variants for anything at a specific place is (at least for me) significantly more of a pain, other than adding things on route one with pwu or variants.

Personally I would say the major part of the issue is out of the way now, as we know that it exists and people can code accordingly. Although of course there is the argument that you get a different game experience then from platform to platform simply as the flight from the witchpoint to the station will be of differing duration, and so the number of encounters etc will presumably change.

[Kaks]

I may well be missing something here, but is there a way to differentiate an "absolute absolute" positioning (as in [x y z]) from an "absolute relative" one (as in system.mainStation.position.add([x y z]))?

err... does not compute. position.add creates a 3D vector which is in fact an absolute absolute [x y z] entity.

Technically, it's fairly easy to distinguish between spawn positions and everything else, though.
Using absolute spawn positons is the only thing that can generate problems, since they never take into account the actual planet, station, sun, witchpoint positions.
All the breakage happened because all the 'fixed' objects aren't actually fixed, we just assumed they were.

As an aside, one idea as yet unexplored could be to always place either the sun (or main planet) at abs coordinates (0,0,0). If we do that, we might be breaking quite a few other things, though!

but the latter is fine, presuming that the entity that you're spawning relative too also moves with the planets etc (or indeed is one of them).

Indeed it is. It's also the only meaningful way to assign positions dynamically. Of course, in theory we could totally remove 'abs' & use new functions to convert to & from coordinate systems - something like Vector.toPWM() & Vector.fromPWM(). Adding those functions would generate unnecessary extra work for for the engine though, since internally all coordinates are always in 'abs'.

the flight from the witchpoint to the station will be of differing duration, and so the number of encounters etc will presumably change.

That's what I managed to correct with my patch above, but it's still a bit rough around the edges. I can work further on it, if we're all reasonably happy about making that kind of change before 1.73!

[Thargoid]

err... does not compute. position.add creates a 3D vector which is in fact an absolute absolute [x y z] entity.

OK, so maybe I should have called it "relative absolute" rather than the other way around. I meant an absolute offset relative to an object, rather than relative to an absolute position ([0 0 0]).

Your original question had the option of removing "abs" from scripting completely (and I presume just leaving pwm and variants) which is not a nice prospect, at least for me. Either that or some new variants on .position would be needed to save too much cross-conversion to locate everything.

[Kaks]

Err, I seem to remember just wanting to remove abs from spawning, and keep abs for all scripting purposes! If you tell me where I say otherwise, I'll edit that post to actually say what I mean.


By the way, I know exactly what you're talking about when you say not having 'abs' in scripting is not a nice prospect: notice what a certain young cadet said in this thread!

PS: the oxp in question was hotrods, which should be updated in the not too distant future!

[Thargoid]

Fairy snuff. Like I said I wasn't sure if I'd missed something, and it seems that your reference to spawnShips being towards shipdata.plist was that very point. It was when the discussion broadened to include the script usage in LA and Cataclysm, as both of those use system.legacy_addShips... with abs and set co-ords.

My wondering initially above was at those situations, where it's the same command just using either set co-ords or an entities properties.

[Kaks]

It all gets a bit messy after a while! Especially when you consider that the entity properties are indeed expressed in set co-ords!

Anyway, it does look as if we're the only two people even remotely interested about planets positions and the use of 'abs'. I suppose I could interpret it as a tacit 'go ahead'...

I've got a pretty busy couple of evenings, but I'm planning a coding session for Wednesday, hopefully by then we'll have a bit more feedback from the board on this whole subject!


Cheers,

Kaks.

[_ds_]

Anyway, it does look as if we're the only two people even remotely interested about planets positions and the use of 'abs'. I suppose I could interpret it as a tacit 'go ahead'…

I'm not arguing.

[Svengali]

Sounds like a plan, Kaks. And if it leads to the same result on all platforms - hey, scripts in oxps can be easily changed.

[_ds_]

Sounds like a plan, Kaks. And if it leads to the same result on all platforms - hey, scripts in oxps can be easily changed.

Let's just say that with that, I get the same results on i386 and amd64.

[Kaks]

Let's just say that with that, I get the same results on i386 and amd64.

I think I know what you mean! I've gone ahead, and I'm almost done cleaning up that rough code! Barring any major snafu, starting from 1.73 we'll have the same abs coordinates for 'fixed' points across all platforms, & there's going to be a warning if an OXP uses abs from inside shipdata.plists.