Deep Horizon - Systems (Thread Renamed)

pagroove · Post by **pagroove** » Wed Sep 16, 2009 3:45 pm

Rich_Industrial_5 Gas Giant - Population is orbital[/quote]

Excellent, Just like Zarece in Famous Planets

Cmd. Cheyd · Post by **Cmd. Cheyd** » Wed Sep 16, 2009 3:58 pm

Yep. Zarece was the first, but not the only.

Website · Post by **Cody** » Wed Sep 16, 2009 4:03 pm

Cmd. Cheyd.

I'm looking forward to seeing v2.0.

If you want ideas, one rich agricultural could be a temperate “prairie” world. No seas, just rivers, lakes and vast open lands.
A giant bread-basket. One main export, and luxuries coming in.

Regards

Cmd. Cheyd · Post by **Cmd. Cheyd** » Wed Sep 16, 2009 4:29 pm

Thanks EV. It's on the list now.

Cmdr Wyvern · Post by **Cmdr Wyvern** » Wed Sep 16, 2009 5:30 pm

We had a planet in ROTK - one of Roh'i's mission stops - that although being a rich, high TL industrial, was very clean and green due to heavily enforced environmental protection laws, which put the bulk of it's industry in orbital factory platforms.

Website · Post by **Cody** » Thu Sep 17, 2009 9:44 pm

More thoughts...

...one of the rich industrials should be an ocean world i.e. Earth-like, and maybe an industrial could be an ice world, like Europa, with hydrocarbon rich oceans under the ice.

Regards

pagroove · Post by **pagroove** » Sat Sep 19, 2009 2:53 pm

Are the original System Redux 1 planets also included in System Redux 2? Throwing them away would be a real shame because there are some gr8 textures in the original set. I would also like a 50% chance to encounter a SysRedux version because in 173.0 the new random planet system is really good and also creates some nice planets. This is just for variety.

Cmd. Cheyd · Post by **Cmd. Cheyd** » Sat Sep 19, 2009 8:05 pm

The 1.0 textures are being recycled, just not for the main planets. They will appear as textures on the add-on planets.

I had not planned on any procedural planets appearing, but I guess I could if enough folks wanted... I'd like to get some additional feedback for / against before I made any changes though.

Svengali · Post by **Svengali** » Sat Sep 19, 2009 8:25 pm

Cmd. Cheyd wrote:
I had not planned on any procedural planets appearing, but I guess I could if enough folks wanted... I'd like to get some additional feedback for / against before I made any changes though.

Uh, yes. Some procedural planets are looking great, but then you'd need a list of systems. So for me it's not necessary (and I'm not going to visit all systems). If I remember right you have already planned a switch for this, so anybody can switch between your textures and procedural planets.

Cmd. Cheyd · Post by **Cmd. Cheyd** » Sat Sep 19, 2009 8:38 pm

Yes, there's a general toggle to turn main planet texturing on/off. I think what pagroove was proposing was having random planets use the procedural.

Two ways I can go about doing that:
1) Current algorithm to determine a planets texture has 5 outputs (1-5). I could make #5 (for example) exit the function and just go back to procedural. It would mean roughly 20% of all planets would be procedural.

2) I could add an precursor algorithm that would determine if a planet was procedural or textured, and at a given percentage. Of the textured planets, they would still have the 5 choices as is currently designed.

pagroove · Post by **pagroove** » Sat Sep 19, 2009 8:49 pm

Cmd. Cheyd wrote:
Yes, there's a general toggle to turn main planet texturing on/off. I think what pagroove was proposing was having random planets use the procedural.

Two ways I can go about doing that:
1) Current algorithm to determine a planets texture has 5 outputs (1-5). I could make #5 (for example) exit the function and just go back to procedural. It would mean roughly 20% of all planets would be procedural.

2) I could add an precursor algorithm that would determine if a planet was procedural or textured, and at a given percentage. Of the textured planets, they would still have the 5 choices as is currently designed.

I simply meant that each time you enter a system the oxp sets (for example) a 50/50 percent chance that either a normal 1.73 planet OR a System Redux texture is used.

Cmd. Cheyd · Post by **Cmd. Cheyd** » Sun Sep 20, 2009 4:09 am

@pa - The way SysRed 2.0 is set up, although the texture is randomly chosen from a pool, every time you enter the system, you will get that same texture. So it's a pseudo-random selection. The same is true for the number of added planets, added moons, and the textures applied to all of them. So, the user experiences a consistent look of the Ooniverse. Every time you hyperspace to Esbeus in G2, it should have 1 planet and 6 moons.

Now, certain things will play havoc with that consistency. If the TL, government of a system is changed, if the max number of planets or moons is altered, or one of a dozen other things I use in the algorithm get shifted, the results will too. But so long as you're not changing those things to a new different EVERY time you play the game (1st game TL is 3, next game TL is 8, 3rd game TL is 2), then you'll have a consistent universe.

I can use either of the two methods above to slip procedural planets into the mix, and yet retain the consistency. Matter of fact, I'm leaning to method 2. I may slip this in as another player-adjustable option. 0 to 30 percent chance of the system using a procedural texture rather than an artisan texture (for lack of better term). I'm just concerned with the number of player-adjustable options I'm setting in this OXP as it is. I was seriously thinking of making it compatible with OXPConfig 2.

We'll have to see. Again, I would like additional feedback for/against before I commit. But if it's player-adjustable, it's much more likely to make it.

Website · Post by **Cody** » Sun Sep 20, 2009 2:56 pm

Weird Moon! This colour enhanced pic of Jupiter's moon Ganymede is better than any fantasy moon.

http://antwrp.gsfc.nasa.gov/apod/image/ ... alileo.jpg

Commander McLane · Post by **Commander McLane** » Thu Sep 24, 2009 4:44 am

Cmd. Cheyd wrote:
If the TL, government of a system is changed, if the max number of planets or moons is altered, or one of a dozen other things I use in the algorithm get shifted, the results will too.

I just would like to make you aware that this may lead to weird results in conjunction with some OXPs. Especially mission OXPs may change the TL, and probably economy and government of a system on the fly, depending on what things happen during the mission. It is highly likely that the player will visit the system in question both before and after the changes are made. So he would meet one planet texture first, and then a completely different texture (which for the player will look like a completely different planet) only a very short while after. I'm afraid that would give an odd feel and look for the game. So, personally and as an OXPer, I would rather like these variables left out of the equation, as far as the planet texture is concerned.

I am aware that you are designing different sets of textures, especially depending on economy, so my small objection sort of defeats the whole purpose of your new System Redux. But still, there is a potential clash between your OXP and every mission OXP out there, and you somehow should deal with that. It seems that in this case CaptKev's approach of simply using a pseudo-random seed lead to more reliability for third-party OXPs.

Cmd. Cheyd · Post by **Cmd. Cheyd** » Thu Sep 24, 2009 6:58 am

@Commander McLane
I understand the concern. Unfortunately, there were limitations (for lack of a better term) within the the 1.0 pseudo-random method that I equally did not care for. Now, I admit - There are parts of the 1.0 code that I am unsure if I fully understood, but based on how I believe it worked - I didn't care for some of the trade-offs it made. One specific example was there were only 256 combinations achieved. Planet #63 in every galaxy would have the same texture, the same number of moons, and the same number of added planets. Another was that the higher-number moons/planets would ONLY appear if the lower-order were added as well. They could not appear independently. While System Redux 1.0 gives a nice variance to the Ooniverse, I wanted to expand on it. The 2.0 script should (I haven't visited all 2048 systems) give a unique make-up to each and every one. That is also the reason I am making 40 main textures, 20 added-planet, and 10 moon textures.

Sadly, if a systems economy is changed, it's a 100% chance that it will alter the main-system texture. This, as you identified, is one of the primary goals I set for 2.0. I wanted textures to reflect the economy of the planet. I believe this allows for a more believable ooniverse.

I had previously added a mechanism within the code to avoid overwriting Famous Planets (if FP is installed). I believe there is a code change that may occur in 1.74 that will allow me to avoid altering any system that was textured by another OXP. So, where possible, I won't mess with someone else's OXP. Additionally, the algorithms I use do allow for a certain 'flexibility' in the input variables, so some changes to certain system elements may not produce changes in moons / textures /etc. However, in order to produce a true pseudo-random result, I have to use certain system-unique properties and there are limited numbers of those to begin with.

I would not consider the scenario you describe to be a 'clash' between my OXP and anyone else's OXP. I do consider it to be an unfortunate interaction or side-effect. I will happily work with any other OXP author to try and minimize these interactions and will do my best to 'code around' any I know of in advance. This could be done by either including said systems in the SysRed exception check list, by the OXP author texturing their planet themselves (once the 1.74 check is in place), and a host of other ways. If you would like to look at the code to help engineer a 'better' set of algorithms, I will happily send you a copy of the script. But I will say, aside from the raw art-work end of this project, the creation of those algorithms (especially the main-planet texture one) was by far the hardest part of this project to date.