*** <warning> another monster post by the monster poster </warning> ***
Hi, Lestradae,
I agree with you: this
is a megalomaniac idea (not only somewhat)!
And you may hit reality pretty soon pretty hard.
The general concept of "one system, one sun, one planet, one station" is an Elite legacy, so there may be people who would reject the idea of having multiple planets in each system. On the other hand this general concept is very much due to the limitations of computer power in the eighties. One could reasonably argue that if B&B had had the power to do it then, they would have done it. And of course there are a couple of OXPs that already put additional planets in some systems. So, why not extend this to the general look of Oolite? Go ahead.
*****
However, I want to raise some general issues with your idea. The first and most important one: additional planets are IMO mainly a cosmetic feature, improving the
look of Oolite. And we should be aware that this is not the
real simulation of a planetary system. First of all planets in a solar system are awefully far away from each other. Just look up to the sky. How many planets of our own solar system to you actually
see? Just some tiny dots, indistinguishable from the stars for the naked eye. Obviously there would be no point in putting up some more dots to Oolite systems. So additional planets would have to be either ridiculously close to the "main" planet or ridiculously big (the latter is the case with the gas giants in Assassins.oxp). You can, however, skip this objection, as the relation of sizes and distances in Oolite is completely screwed up and unrealistic, anyway.
(This was discussed exhaustively several times here on the boards.) So we can set them up in unrealistic positions as eye-candy. Second we will never achieve a real planetary system, as celestial bodies in Oolite can't move. They are fixed at their position once and for all. I agree, however, that this is no big hinderance, as the player usually wouldn't notice the lack of movement.
I am more doubtful, as far as additional
stations (or ground structures) are concerned. This is basically for two reasons: (1) I discussed the distance-problem above. You mention a possible travel time of 20 minutes
with jumpdrive (J-key) (not witchdrive engines (I-key); you would run out of fuel in less than a minute!) between stations in the same system. Who would actually do this? Even if it's only ten or five minutes. Yes, it's nice to travel to the Tianve Pulsar and its station, it's also nice to do this once in a while by another OXP; but in every system? My guess is that these travel times, with no action in-between, would become pretty boring pretty soon. I suppose only someone who had become immortal by a weird accident whose exact circumstances never could be reconstructed again would seriously attempt to visit even just a fraction of all these new docking places. And (2) how many new stations/landing places per system do you have in mind? All these (and of course the planets themselves) are entities that have to be spawned and maintained by the engine. That may become quite a burden for lower end systems. If I got you right you are imagining dozens, if not hundreds of new structures per system! If you're serious with your numbers of 15,000 new planets and 100,000 new stations this means an average of 7 planets and 48 stations per system,
plus the resulting engine-generated travel between them! This may result in a serious performance problem.
So the bottom line here is: New planets, as eye-candy: Yes. Lots of new stations/ground structures: I don't know.
The second, practical issue concerns the "how to". You are hoping for a procedural way, generating planets, stations, ground structures from the seed. (It is the so-called
galaxy-seed, a series of 6 random numbers between 0 and 99, different for each galaxy, which determines the physical appearance of the Ooniverse, not just the
planet- and
galaxy-number.) This is definitively impossible with plist-scripting. I don't know about js-scripting, because I don't have yet a lot of knowledge of JavaScript. IIRC loops are possible, and js-scripting seems to be more powerful in general, allowing you to make use of more system variables and settings than with plist-scripting. Whether you can address and use the galaxy-seed directly via js-scripting I can't tell. And I doubt that you can squeeze enough formula and pseudo-random out of galaxy- and planet-number only. So it may be possible to use a procedural approach in an OXP via JavaScript, but I don't know. If it is
not possible, then you have two options: write the procedures for generating additional planets and stations/ground structures
directly into the code (which you don't want to, if I understand you correctly). Or
do it all by hand, writing a planetinfo.plist with all the additional entities for all the 8*256 planets. This
is a megalomaniac task. Not impossible, but a
huge work! (matt634 has just done it for a mere 14 planets out of 256 in every galaxy, and he is not very keen to even open and look at his planetinfo.plist again!)
Third issue: For either procedural or by-hand approach, you have to take measures to avoid clashes with other OXPs. If it is procedural, you have to somehow exclude those systems from the procedure that are already modified to multi-planet systems. This goes mainly to the systems in Galaxy 7 affected by Assassins.oxp. But there are other examples as well, like the planets affected by Ionics.oxp, or probably even the ones changed by GalacticNavy.oxp. Generally you would have to include a way of turning the procedure off for certain systems. Also in the future there may be OXP-scripters who want to design one of the systems specifically to their needs. For instance there can be the need for a system that contains only one planet. If it is by hand and you are writing a gigantic planetinfo.plist, you have to make sure that it doesn't overwrite existing plists (or that there are no strange effects from your planetinfo.plist be overwritten by others). All of this may be doable, so this is not a straight objection. But it is an issue that has to be kept in mind and somehow dealt with.
These are the general issues I can see for now, that need to be reflected upon.
*****
In the second part some ideas and answers to your specific questions:
@1: As stated above, yes, it is possible (and relatively easy) to script additional planets. It's just a huge work to do it in every system and to avoid clashes with other scripted planets.
One specific hint: Yes, they have no real trajectories. To be precise: They have
no trajectories at all. As I mentioned above, Oolite (as Elite) is not meant to have real planetary systems. All celestial bodies are completely and eternally static. So you don't need "a) number of planets, b) their distances to the sun, and c) their types and diameters", but a) number of planets, b) their
exact positions in absolute coordinates, and c) their types and diameters. And you need a couple of things more, like d) their orientation, e) their rotational velocity, and e) their cloud formation with all the new parameters. For a complete overview on what you can do with planets read the
Planetinfo.plist document in the EliteWiki (new cloud-keys not yet documented!).
As planets are created differently from ships, LittleBear's hint to "addSystemShips: 0.[shipposition]" leads nowhere. For a planet you always need its exact position in space (three coordinates)
according to Oolites internal coordinate system, which is
not identical to any of the known coordinate systems explained in the
Looking for, and adding ships-chapter of the Methods document of the Wiki.
Adding stations or any entities that could serve as landing places on planets , however, is done through the known methods explained in
said document. That means that you have to
transform the internal coordinates of any planet to one of the user-end coordinate systems before you can add a station or anything else close to that planet. As you studied physics, the maths required for this should be relatively trivial, as soon as you have found out the exact relation between the internal coordinate system and let's say wpm. My research so far (which you can follow over various threads here on the board), has brought out that in systems I have tested the origin of the internal coordinate system seems to be roughly (perhaps exactly, but I don't know that) at the witchpoint, with the z-axis pointing away from the planet, so the orientation of the z-axis seems to be just the opposite of wpm. Unfortunately also the x- and y-axes of the internal system don't point in the same direction as in wpm, but are turned around the z-axis by roughly 32 degrees. You will have to find out the exact values, because your positioning of stations (and especially ground structures) will have to be
very exact. But in the end you will just have to turn around (I guess) two axes and probably move along one axis, in order to transform from one system into the other, which is not complicated for a physicist who knows his formulas (or knows where to find them). Then the last thing you have to do is to pray that this transformation is the same for
all systems in Oolite, and you don't have to repeat the exercise for each of the 2048 systems! I
do hope it's the same, but I don't know for sure.
@2: I like this approach to creating dockable structures on a planet's surface!
You missed just one obvious problem: As
you will shatter on the planet's surface as soon as you contact it, so will any asteroid or other entity that you place "exactly ON or halfway INTO a planet's surface"!
Especially the latter is therefore no option. You can, however, try to create a "half-asteroid" (with a flat backside) and try to place it exactly on the surface (probably a fraction of a meter above, just to avoid the collisional stress). At the end of the day it all comes down to Oolite's precision in placing objects, which - as I seem to recall from somewhere, although it's not mentioned in the
Looking for, and adding ships-chapter - is about 0.5 meters, if you are using
addShipsAtPrecisely:. But then I don't know how precisely the planet itself is placed. I think you have to try it out.
Oh, yeah, another problem will be the orientation of your dockable half-asteroid. Its flat backside has to be exactly in line with the surface in order to avoid a collision. The only existing method that allows you to create an entity
and to control its orientation is
spawnShip:, and it has three drawbacks: First it doesn't (at least not always) seem to work as desired (I have huge problems to give an entity in an OXP of mine the correct orientation, it just doesn't face in the direction I have specified). Second it requires an individual, unique shipdata.plist entry for each object whose orientation you want to control, containing
both its position and its orientation. In other words, you can use the same shipdata.plist entry twice (or more often)
only if in each system you want to use it in, its location and orientation is exactly the same. So if you place a planet with a different radius at the same location, you will need another shipdata.plist entry for its half-asteroid, as the existing one would be placed either within the planet or orbiting around it in a distance. If you want to have more than one ground structure on each planet, on more than one planet in each of the 2048 systems, also your shipdata.plist is going to be
huge! And third I don't know whether
spawnShip: works with the same precision as
addShipsAtPrecisely:. Probably not.
@3: You have to distinguish between trading goods (commodities) and equipment. The pricing of both is handled
completely differently.
Availability and price of equipment is governed by two factors: its availability by the TechLevel of a station, which by default is the same as in the system's main station, but can be changed by the
equivalent_tech_level-key in each station's shipdata.plist entry. This means that you can create a variety of clones of stations with different tech levels in your shipdata.plist. Its price is determined by the
equipment_price_factor-key in each station's shipdata.plist entry. So you can set up a two-dimensional array of stations:
equivalent_tech_level from low to high,
equipment_price_factor from low to high, and each combination of values requires one shipdata.plist entry. Sounds like this plist is growing even more.
Availability and price of commodities is governed by yet another plist, commodities.plist. As somebody with skills in mathematics you will like it.
How to handle it is explained in the
Commodities.plist document of the EliteWiki. If you need a little help with getting your head around the formulas, I can offer you an elaborate tutorial, unfolding in the
Understanding commodities.plist-thread here on the board, where I do my best to explain it to the rest of the world.
There is one catch to it: Each entry in commodities.plist (one array of prices and quantities) is tied to the individual
name of the station it shall be used with. That is the
name-key in its shipdata.plist entry. So if you want to have stations with individual choices of commodities and individual pricings, you again need individual shipdata.plist entries for them, with individual
name-keys. Which turns your two-dimensional array of stations into a three-dimensional one, again multiplying the number of entries in your shipdata.plist. (If you want stations with individual names, you have to give each and every one an individual shipdata.plist entry anyway.
And an individual commodities.plist entry as well, if you don't want all of them to just use the default.) However, as also the tech level of a station goes into the calculation of commodity quantities and prices, there will be a variation in the stations in your system according to their tech level, even without bothering with a home-made commodities.plist.
@4: Of course it is possible to have a texture on a planet. And I agree with you that we don't need individual textures for
all planets. The numbers suggested by you: 10 textures each for earth-like, gas-giants and dwarf planets seem reasonable. (For comparison:
Celestia uses only seven different textures for exo-planets.) So, unlike LittleBear, I am not very concerned with the size of the download file (I think he misunderstood you there).
I agree with LittleBear's suggestion that for a start you can use planet-pics from the web. Nasa-pictures come with explicit permission to use them, so you don't get into copyright-issues here, which can be a problem with pictures from other web-sources.
Personally for texturing planets I start with a Nasa-picture and heavily edit it. Want some examples? Here is one earth-like planet and one gas giant from Ghosts_from_the_past.oxp (WIP, unpublished), that can be found in a system in Galaxy 3.
The first was a false-colour picture of Venus, resized, rescaled, copied into itself, which gives an earth-like impression:
The second was an image of Neptune's dark spot, again resized, flattened out and copied into itself, then edited by hand, to give a gas-giant-like impression:
Both are 256*128 pixels in size, which is sufficient for a not-to-detailed planet texture, even for the gas-giant. You just have to take care that the left and right edge fit nicely together, as this is where the whole texture will be glued together around your planet (the gas-giants in Assassins.oxp
could have had more attention to this specific detail, if I may say this here
). Generally the texture should have a power-of-two size, and of course, for obvious reasons, if you wrap them around a ball-shape, their height needs to be half of their width.
As to the question of "who shall do it" and the possibility of a procedural approach I have given my view above. I am afraid at least
a lot of the work is
not doable in a procedural way. So it's down to your time and manpower to create this.
*****
I hope all of this is helpful for you (and not too discouraging). If you get around it (and the time perspective of two years seems not too out-of-scale to me
), it's surely going to be a gorgeous OXP.
So good luck with it!
) the planet`s surface - just that there`s nothing there. And I can`t help noticing that if one took a bigger asteroid from, say, the "asteroid storm" setting and put it exactly ON or halfway INTO a planet`s surface it might reasonably look like a hill or small mountain. And if a basis, like, say a rock hermit or a biosphere with good entrance graphics was then again stuck into the big asteroid so that its entrance pointed mostly upwards it would look like a station - on a planet! And it would be possible to land in it, the same way as in any other station. 
