plannets.oxp - is it still working?

[CaptKev]

okay, this post is quite old, but I guess there is a small bug in the formula. I'm not an JS Expert, but I read it as:

p = (p + p - s) * m
shouldn't it be
p = p + (p - s) *m

I noticed the same bug in the farsun.oxp. It would mean a change of the angle of the ecliptic.

Ebi

Welcome Ebi

That will teach me for stealing other peoples code.

If your running version 1.71 you shouldn't need this code anymore, it was just a crap way of texturing the planet until Kaks added the setTexture function.

[Ebi]

Welcome Ebi

That will teach me for stealing other peoples code.

If your running version 1.71 you shouldn't need this code anymore, it was just a crap way of texturing the planet until Kaks added the setTexture function.

Thank you for the welcome!

Ohoh, sorry for being such a smartass, CaptKev, Sir. Actually not a perfect start in the forum of this great game! Just to "relativize" this again: I read the abbreviation "pwm" as header of a position vector, do you know what it means?

[CaptKev]

Welcome Ebi

That will teach me for stealing other peoples code.

If your running version 1.71 you shouldn't need this code anymore, it was just a crap way of texturing the planet until Kaks added the setTexture function.

Thank you for the welcome!

Ohoh, sorry for being such a smartass, CaptKev, Sir. Actually not a perfect start in the forum of this great game! Just to "relativize" this again: I read the abbreviation "pwm" as header of a position vector, do you know what it means?

There's nothing wrong with your start!

planet+witchpoint+metres, see the methods-page of the wiki.

[Ebi]

Hi CaptKev,

using different coordinate systems is really clever! I've read in wikipedia that normally due to the formation of a planet system the orbits of the planets are almost coplanar. You can see it in the solar system and it's simulated by some games (for instance "Frontier"). This can also quite easy be simulated by using the "spu" rather than the "pwm" coordinate system. If you use the vectors [spu x 0 z] all panets are in the plane formed by the triangle witchpoint, sun, and main planet. Using x = cos(a), y = sin(a) puts them somewhere on the orbit of the main planet. And multiplying the vector with a scalar moves the planet in units |main planet-sun| nearer to or farther from the sun. On my computer I was playing with your planetinfo.plist of the system-redux-oxp and have changed the vectors of panet 1 to 4. If you do that you can fly to the witchpoint, point the ship to the center of the main planet, and rotate it to get the sun in the space compass at 3 o'clock. If you then yaw to the left or right all planets should be lined up at the horizont.

I'm using the farsun-oxp and still need to figure out if in a "spu" vector the unit is measure before or after apply the sun shifting.

[CaptKev]

Sounds interesting, what values are you using for the four extra planets?

If it's okay with you I might use them in the next release of System Redux.

[Lestradae]

Hey, very interesting ...

I'm using the farsun-oxp and still need to figure out if in a "spu" vector the unit is measure before or after apply the sun shifting.

After.

I might use them in the next release of System Redux.

CaptKev & Ebi, wouldn`t that be the perfect opportunity to implement something like the solar systems oxp that I suggested some time ago?

If I get that right, it would be possible to create planets of any kind & size that even move in their orbits around the sun by just implementing a formula into system redux?

I mean, if you just do that, and give the planets some meaningful orbital distance like 0.3, 0.7, 1 (main), 1.5, 2.5, 4, etc., and add an orbital and ground station each that have npc_traffic, plus the deep space pirate oxp (just add deep space traders & police & such, too) and that`s it, actually ...

I have only one word to say: Please



L

[DaddyHoggy]

The problem with all these fantastic ideas is that if you visit any of the other stations of the new worlds do your deals, trade, etc. you then have to leave and fly to the main station (or leave the system and fly to the main station of that system) to save the game - the chances of dying without having your hard work saved goes up dramatically.

Somebody - i.e. one of the programming gods amongst us is going to have to be brave and make a fundamental change to the way the game works i.e. you can save at non-main stations or ships and somehow (providing you don't remove that generating oxp - which is true for Commanders who remove the ship oxp of the ship they're flying and can't reload) lock that particular carrier/rock hermit/non-main-station/con-store/hoopy-casino/etc into position so its regenerated with the saved game reload.

This will also get over the oddity that even the most hardened-blood-thirsty-Ace-of-Spades Pirate player must bimble into a main station to trade/save game.

I know we have to suspend disbelief to play this game but it would be nice if it was consistent within itself - There needs to be a place for fugitives to go (sensibly) and to be able to save their games!

So endeth the sermon.

[TGHC]

There needs to be a place for fugitives to go (sensibly) and to be able to save their games!

Hmm I think it goes with the territory, if you want to play a high risk strategy, then you must take on the potential consequences. Anyway there's always the escape pod unless it get's damaged. (unscrupulous and morally deficient commanders will use it deliberately sometimes to "cleanse" themselves)

[Lestradae]

The problem ... is that if you visit any of the other stations of the new worlds do your deals, trade, etc. you then have to leave and fly to the main station ... to save the game ... one of the programming gods amongst us is going to have to be brave and make a fundamental change to the way the game works i.e. you can save at non-main stations or ships and ... lock that particular carrier/rock hermit/non-main-station/con-store/hoopy-casino/etc into position so its regenerated with the saved game reload.

Actually, what would have to be done if I`m not completely mistaken would be to save the current system`s information with the save game file. This information must be available anyways in the game! Next reload, same station, same ships on their way in the same system etc. ...

Quite obviously, this would also mean that you can only change your oxp list in a significant way if docked at the main station.

This would be an enormous expansion to the game imo. Is there any reason for the programmers that this couldn`t be implemented quick & simple? (<-- perhaps me being naive, there)

Cheers

L

[LittleBear]

It isn't stored in the save file ATM, but I'd have thought it could be if one of the Devs wanted to do this. I personally would like the option to save at a none main station. When you save at the main station and then later re-load everthing that was in the system is lost and re-generated when you launch. OXPs remain consitancy by re-generating any special ships that were present on a reload on launching, but checking for the number of ships of the type required and then if it returns zero adding it. Eg in Random Hits if you are fighting a victim by the station, dock save and launch he'll be by the station same as he was before. If you save and re-load then he's re-generated somewhere in the system.

The only data that would need to be saved therefore would be the type and location of the station / carrier where the game was saved. That would make saving at an non-main station just as consistent as saving at the main station.

[another_commander]

...
Is there any reason for the programmers that this couldn`t be implemented quick & simple? (<-- perhaps me being naive, there)

Yes. Time. Also, "quick and simple" must be the understatement of the year.

[Lestradae]

"quick and simple" must be the understatement of the year

That`s for sure me being naive there, then.

[Ebi]

Currently I use the following vectors:

position = "spu 0 0 7";
position = "spu 3 0 0";
position = "spu 0 0 -9";
position = "spu -5 0 0";

And as multiplier in farsun I use 10. You see, this shifts planet3 into a parallel ooniverse:) These vectors are just for testing, so the angle between them is 90 degree. I wanted to see where the planets are positioned. The sun is too small, that's more obvious if you use smaller multipliers. I tried to correct its radius, but as documented it's read only. It also makes a difference for "u" in which order you install farsun and System-Redux.

I've recently read about the vector functions offered by the Oolite JS interpreter. I guess, since it's possible to calculate the crossproduct a JS script could probably calculate the positions of the planets on circular orbits as function of the game time.

Maybe the number of planets can be derived from the name of the system. In C it could be done the following way:

Code: Select all

for (unsigned i = strlen (sysnam), sys_info = 1; i > 0; --i)
  sys_info *=  sysnam[i-1]; 

I'm pretty sure that can be done in JS as well (which is new for me).

[Frame]

Currently I use the following vectors:

position = "spu 0 0 7";
position = "spu 3 0 0";
position = "spu 0 0 -9";
position = "spu -5 0 0";

And as multiplier in farsun I use 10. You see, this shifts planet3 into a parallel ooniverse:) These vectors are just for testing, so the angle between them is 90 degree. I wanted to see where the planets are positioned. The sun is too small, that's more obvious if you use smaller multipliers. I tried to correct its radius, but as documented it's read only. It also makes a difference for "u" in which order you install farsun and System-Redux.

I've recently read about the vector functions offered by the Oolite JS interpreter. I guess, since it's possible to calculate the crossproduct a JS script could probably calculate the positions of the planets on circular orbits as function of the game time.

Maybe the number of planets can be derived from the name of the system. In C it could be done the following way:

Code: Select all

for (unsigned i = strlen (sysnam), sys_info = 1; i > 0; --i)
  sys_info *=  sysnam[i-1]; 

I'm pretty sure that can be done in JS as well (which is new for me).

it could be done almost the same way in a javascript... however i´m unsure wheter you can multiply a string in a javascript or if the charat method works in oolite. Some documented java methods used in other java applications do not seem to work

however it does compile when i start oolite and generates no errors or warnings...

Code: Select all

let i = 0;
let sname = system.name
let namelength=sname.length();
let sys_info =1;
for(i =namelength;i>0;i--);
let sys_info *= sname.charat[i-1]

[Commander McLane]

If I get that right, it would be possible to create planets of any kind & size that even move in their orbits

No, suns, planets, moons and the sky will never move in Oolite. At least not while you are in the system. Perhaps (and this is a very perhaps) you could develop a very sophisticated formula that creates planets at different positions, depending on your shipclock when you jump into the system, which could create the illusion of "orbiting" over time. Question is how resource-hungry this would be (a lot of calculations on every system creation), and whether you would really notice the effect in the first place. For instance, you have visited system X half a year (in-game time) or three-and-a-half days (your playing time) ago. Now you return to the same system. Do you actually remember how the planets were positioned back then? So would you even notice that they are positioned differently now? I doubt. And if you would do a lot of back-and-fourth travel between two systems, thereby actually remembering their lay-out, the changes would be too minuscule to notice.

Anyway there's always the escape pod unless it get's damaged. (unscrupulous and morally deficient commanders will use it deliberately sometimes to "cleanse" themselves)

Not if you're using Anarchies.oxp ...

Finally: Probably this is me being naïve here but I always thought System_Redux would have placed additional planets (and moons) in coplanar positions only, anyway. And not just randomly somewhere. I mean, if you want to have multi-planet systems, that's simply the way they have to look. (Give and take a wider range of "orbits" for moons, as we can see also from our own solar system. The Earth's moon's orbit is pretty much ecliptic, but Jupiter and Saturn have moons also completely out of the plane.)

You also have to have an eye on the rotational directions of the planets, because they tend to rotate along the plane as well (again with notable exceptions: Uranus).

In my opinion any OXP that would try to simulate solar systems in Oolite (as opposed to: adding random eye-candy) would have to meet these conditions in order to be acceptable.