Problem Povray Planets

[CommRLock78]

I've been taking a look at system redux and povray planet code, and it looks like adding additional moons and planets are going to be more involved than I initially thought.

If either isGasGiant or solarGasGiant are set to true for the planet entity, then PF will not try and land on it (detailed here on the wiki). But it needs to be set, ideally by the OXP which makes the planet a gas giant, but if there is some way to distinguish them then I can also put it into the PF script. But doing it at source is of course much preferred (and should be simpler).

You will get a warning though that you are trying to land on a gas giant - if that isn't wanted then just set PFNoLandQuiet to true instead. Then the planet effectively is completely and silently ignored by PF. Any landing attempt there will just result in the same splat that would occur if PF wasn't installed at all.

I actually don't mind being told that it isn't possible .

[cim]

Plus there's also the old question of gas giants as main planets anyway. The system station is supposed to be in orbit around the main planet of the system

I wonder if some of the "known for [...] shyness" worlds would specify a gas giant as their primary planet and direct all trade traffic there, in an attempt to keep casual visitors away from their real homeworld. Planets with diseases might be a candidate for this, too, though in that case it might well be Galcop rather than the system authorities making that decision.

Certainly actual habitation of the gas giant (beyond a couple of specialist high-atmosphere installations) should be extremely rare. Quite possible, if you're adding moons anyway, that a gas giant with several moons gets designated the primary just because it's easier to track and put a station in orbit around than the actual moons.

[Cody]

... if you're adding moons anyway, that a gas giant with several moons gets designated the primary...

That's what is needed... habitable moons (large or small) in gas-giant systems.

[CommRLock78]

... if you're adding moons anyway, that a gas giant with several moons gets designated the primary...

That's what is needed... habitable moons (large or small) in gas-giant systems.

<Agrees> While I absolutely positively love all the new eyecandy provided by POVray planets (in conjunction with Distant Suns) I miss my dynamic systems with moons and multiple planets!
Edit: BTW, I don't think it would take more than a couple dozen textures for the moons that could be re-used. I wouldn't have a problem with a bit of recycling, especially when it comes to "secondary" bodies.

[Diziet Sma]

Now that I'm making those suggestions, I would also like to say that I miss having moons and multiple planets in systems. Since I'm doing this now, I haven't had a chance to look at some code (namely DS system redux) to see how hard it would be to dovetail some additional planets and moons in each system via another OXP. What are your thoughts on moons/additional planets Submersible? Is it something you've considered or are working on? I don't want to step on toes, but this could be a good place for me to start OXPing.

I like the sound of that!

<waves box of cookies under CommRLock78's nose>

[Cmd. Cheyd]

I have mentioned it before, and have tried not to for a long time... But... You should look at the code behind DH-Systems. A lot of what has been discussed in this thread was addressed in there.

And before someone says that gas giants as mains were too prevenlent, I will again state that is only because gas giant textures are easy so I finished them long before I got around to other textures, so when I released it without all the others done, they had an un-planned higher appearance rate.

[CommRLock78]

Okay, I've had more than just a look at the code - in fact, I think I might have gotten some the exact compatibility that I was looking for (although very 'quick and dirty').
Using Version 2.0.8 of DHS, this is the changelog of things I've done:

Code: Select all

---------------
SystemRedux2.js
---------------
set lines 22 & 59 to false


-----------------------
Deep_Horizon_Systems.js
-----------------------
255-257 commented out
481-516 commented out

Deep Horizons Systems now provides extra planets and moons that is compatible with all Famous Planets 2.7 (Test release), POVray Planets (FP edition), and Distance Suns . So far no console errors and everything seems to working great

[submersible]

Deep Horizons Systems now provides extra planets and moons that is compatible with all Famous Planets 2.7 (Test release), POVray Planets (FP edition), and Distance Suns . So far no console errors and everything seems to working great

Erm yes - I'd say more hackability than compatibility and surely not what Cmdr Cheyd had in mind. I'd like to try doing this with an update to the Povray Planets base OXP and using the actual DH API to effect the changes.

[CommRLock78]

Deep Horizons Systems now provides extra planets and moons that is compatible with all Famous Planets 2.7 (Test release), POVray Planets (FP edition), and Distance Suns . So far no console errors and everything seems to working great

Erm yes - I'd say more hackability than compatibility and surely not what Cmdr Cheyd had in mind. I'd like to try doing this with an update to the Povray Planets base OXP and using the actual DH API to effect the changes.

Whether or not it was what Cmd Cheyd had in mind, these OXPs work together now - that's all I was saying . Though, if you work out a way to make it work through the PP base OXP, that would probably be preferable.

[Cmd. Cheyd]

Submersible is correct, it's not what I had in mind, but so long as the altered version is not distributed - I'm good with it.

API is supplied specifically to allow other OXP's to control the behavior of DH-S. It's not hard to figure out from the code, but I really should get around to get around to writing the documentation sometime... Meh.

If I ever bother finishing the rewrite, it would actually become even easier. I was going to allow alternative OXPs to register their artwork into DH-S for use in texturing decisions along with some other features.

[Wildeblood]

Erm yes - I'd say more hackability than compatibility and surely not what Cmdr Cheyd had in mind...

Whether or not it was what Cmd Cheyd had in mind, these OXPs work together now - that's all I was saying ...

And there's the real problem on display from submersible: too much emphasis on "Isn't this code clever?" and not enough thought given to "Will this actually work for players?"

Submersible is correct, it's not what I had in mind, but so long as the altered version is not distributed - I'm good with it.

Just for clarification, what exactly will happen if it's "distributed"?

API is supplied specifically to allow other OXP's to control the behavior of DH-S. It's not hard to figure out from the code, but I really should get around to get around to writing the documentation sometime... Meh.

It's not an API unless it's documented. The usual terminology for an undocumented API is trojan or trapdoor. Fortunately, a trapdoor into an OXP script can't harm a player's computer, but the repeated references to a "DH API" are just so much pretentious nonsense.

I'd like to try doing this with an update to the Povray Planets base OXP and using the actual DH API to effect the changes.

What you refer to as the "base" Povray Planets OXP is of course in reality a completely unnecessary, extra script which serves no useful purpose, but attempts to resolve the problems caused by other people's sledgehammer javascripts by piling on yet more javascript. Only madness lies down that route.

The way to solve DH Systems taking a sledgehammer to the system info is for Cmd. Cheyd to update it with the one line bug fix it needs:

Code: Select all

if (!system.info.texture) {...}

That's all that is needed: before you presume to set a texture on the main planet, check that it hasn't already been set.

[Diziet Sma]

The usual terminology for an undocumented API is trojan or trapdoor.

According to Micro$oft, the correct term is Undocumented Feature.

[Wildeblood]

According to Micro$oft, the correct term is Undocumented Feature.

You must have been reading my mind while I composed the first draft. I thought I did rather well at removing all the more offensive references such as "Micro$oft", while still letting the tone of general frustration shine through.

[CommRLock78]

Erm yes - I'd say more hackability than compatibility and surely not what Cmdr Cheyd had in mind...

Whether or not it was what Cmd Cheyd had in mind, these OXPs work together now - that's all I was saying ...

And there's the real problem on display from submersible: too much emphasis on "Isn't this code clever?" and not enough thought given to "Will this actually work for players?"

I most definitely thought about other players - specifically players who are using Distant Suns, Povray Planets, and DHS. The last several posts I made on this thread I was considering re-establishing more comprehensive solar systems by way of a new OXP, but after Cmd. Cheyd gave his input and looking at the code to DHS, I realized it would be infinitely easier to re-craft the wheel rather than re-invent it .

API is supplied specifically to allow other OXP's to control the behavior of DH-S. It's not hard to figure out from the code, but I really should get around to get around to writing the documentation sometime... Meh.

It's not an API unless it's documented. The usual terminology for an undocumented API is trojan or trapdoor. Fortunately, a trapdoor into an OXP script can't harm a player's computer, but the repeated references to a "DH API" are just so much pretentious nonsense.

Learning a bit more about API, it looks like Wildeblood is absolutely right, documentation is a integral part of an API.

I'd like to try doing this with an update to the Povray Planets base OXP and using the actual DH API to effect the changes.

What you refer to as the "base" Povray Planets OXP is of course in reality a completely unnecessary, extra script which serves no useful purpose, but attempts to resolve the problems caused by other people's sledgehammer javascripts by piling on yet more javascript. Only madness lies down that route.

The way to solve DH Systems taking a sledgehammer to the system info is for Cmd. Cheyd to update it with the one line bug fix it needs:

Code: Select all

if (!system.info.texture) {...}

That's all that is needed: before you presume to set a texture on the main planet, check that it hasn't already been set.

I'm fairly certain that DHS does in fact check this (I haven't seen this code per se, but at the same time I haven't seen a mis-textured planet from POVray planets. The main issue with DHS was it sledgehammering Distant Suns (you may recall I was having trouble with sun color).

[CommRLock78]

I couldn't help posting this one... too funny!



Edit: From G5
# 43. Bexein (54,248), {80,95,98,117,160,172,245,250} within 7.0 LY. Radius 3638 km.