plannets.oxp - is it still working?

[elite]

Ok I did a bit of tinkering to the Planetinfo.plist file of the System_Redux.oxp.

I am currently at Lerelace in Galaxy one.

At the moment main planets look like this for me:


After changing the posistion and size of the planet from...
position = "pwm 655444 -3783808 556540";
radius = 18000;
to
position = "pwm 0 0 0";
radius = 3300;

the main planet now looks like this which is much better:


Unfortunately this only works for this planet at Lerelace because it is sized to just slightly overlap the size of the normal main planet.

At least this shows that placing a planet with png textures at the center of the system "pwm 0 0 0" does work.

Now, if only we had an OXP that could read the size of all the planets and then place a png textured planet of the correct size at the center of each system.
That would work.

[CaptKev]

Good work elite, this might be worth looking into.

[elite]

Good work elite, this might be worth looking into.

If I could write OXP's myself I would try it lol.

I am happy with the main planets as they are (kinda got used to them now) but this could be a possible step towards better looking planets for those of us that can't get the procedural planet textures to work.

Maybe even, and a big maybe because of the coding that would need to be changed, just change the main planets for png textured ones instead.
But even I know that would mean doing a major re-write of the main game code.

[Commander McLane]

There also seems to be a problem with your non-textured planets, elite.

The triangular grid is the one used for clouds (I think!). But it shouldn't be visible as a grid.

*****

As for replacing packing all existing main planets into slightly bigger textured ones: Nice and brilliant idea! And I don't see any real problems with that, as far as collision-detection or slow-down are concerned (I don't think that the engine checks for collisions between planets, we don't need to bother).

Of course, as said before, the size of the new planet has to match that of the old one, and this is the real challenge here. The engine of course "knows" the radius of the planet in the current systems, not only has it to create the planet, but its radius is also printed on the F7-screen. Although I'm not sure whether the value given there is the same as the one used by the engine to create the planet. There might be some factor, but you can easily check this out by just comparing the number from the F7-screen with the number from the entity-dump.

Question is: Is the planet radius accessible in JavaScript? Then you could write a script that spawns a textured planet with radius+1 every time when you exit witchspace. If not, then the "only" thing you have to do is to write a planetinfo.plist with 2048 (not 2400!) entries, each time putting in the correct radius by hand.

[Kaks]

Hello! This sounds promising.

Indeed, we can get the planet radius in javascript with system.mainPlanet.radius. There's system.mainPlanet.hasAtmosphere as well, which could be used to select a Mars like texture, though I don't tknow if that's what was used to tell the different procedural textures apart in 1.68(or was it 1.67?).

One other thing you could check for is tech level & agricoltural/industrial. Above a certain tech you could have tiny faintly glowing orange/wite dots on the surface where the cities are. There's already a few glowing textures around, so in theory that wouldn't be a problem.

That glow would have to be just right not be visible on the side of the planet facing the sun, but I'm pretty sure it could be done. Really high tech planets could have a city grid texture on the continents, etc.

I'm hopeless at textures/graphics myself, but I think I can help with the javascript side of things.

Cheers,
Kaks

[elite]

There also seems to be a problem with your non-textured planets, elite.

The triangular grid is the one used for clouds (I think!). But it shouldn't be visible as a grid.

Yes I know hence the reason for png textured planets. The cloud layer grid gets worse as I get closer to the main planet (will take a screenie if anyone really needs to see it).

Well like I said I am crap at writing this sort of stuff and Java so now that the possibillty of textures planets can be seen I'll leave it up to you great scripting guys to give it a go if you have nothing else better to do with your time

[CaptKev]

Indeed, we can get the planet radius in javascript with system.mainPlanet.radius. There's system.mainPlanet.hasAtmosphere as well, which could be used to select a Mars like texture, though I don't tknow if that's what was used to tell the different procedural textures apart in 1.68(or was it 1.67?).

Is there a way of specifying the radius of the planet using JavaScript instead of using a planetinfo.plist?

If not would the addPlanet function in the JavaScript engine be easy to modify to allow something like this?

Code: Select all

radius = system.mainPlanet.radius + 1;
system.addPlanet("my_shiny_new_planet", radius);

[Kaks]

Uh, good point. No, there's no way to define the size of planets inside javascript.

All that can be done atm is to have the same planet repeated n times inside planetinfo.plist, with slightly different names & sizes. If you have them changing by 500 units at the time you could have names like this

earth3000 earth3500 earth4000...

then the code to resurface a planet could simply be

Code: Select all

function replacePlanet(){

let r=system.mainPlanet.radius;
r=Math.ceil(r/500) *500;
system.addPlanet('earth'+r);

}

One thing that would really be fantastic is if the javascript object model gets expanded with a new class to allow panets (& ships) definitions to be created/modified on the fly, before getting sent to the game engine.

I'm not quite sure how that hypothetical Definition class could be implemented though. It might well need a lot of work on the part of the developers.

[CaptKev]

Thanks Kaks I had a horrible feeling the only way would be a large number of entries in the planetinfo.plist.

[CaptKev]

1 down, 1791 to go. This could take quite a long time because system.mainPlanet.radius doesn't correspond to the radius in planetinfo.plist.

Lave:
system.mainPlanet.radius = 41161
radius in planetinfo.plist = 6900

[Kaks]

Hmmm, nice

1 down, 1791 to go.

Phew, not that bad then!

Weird about the radius difference. I'll see if I can find a simple formula to go from shipdata to script radius...

[elite]

Now that is fu#king cool.

[Lestradae]

Wow

Is that ingame in 1.70

Enthusiastic (& a bit hopeful for my pet feature) Greetings

L

[JensAyton]

Hmm… that planet could really do with a shader. ;-)

[TGHC]

Oh boy, I love this game, and you creative guys are awesome.