Oolite Bulletins

Hi to all Oolite-Commanders!

I have a somewhat (?) megalomaniac idea: The SolarSystems.OXP!

If I can learn enough about how Oolite works to attempt this (with a little help, perhaps, from the experienced programmers & mod-creators here) I would even try my hand at this myself. Oh, and there`s a friend, he might help me, too. He is a programmer, currently unemployed and he loves to create programs and little games for fun - all day long

My megalomanic idea came when I thought about what I wanted to see in Oolite so that it would be absolutely perfect for me, and I noticed that my ideas probably would be possible utilising methods which I have already seen employed in existing OXPs.

The "SolarSystems.oxp" would be the mother of all flavour OXPs, and add plenty of additional opportunities for trading (including meaningful in-system trading), missions and the like into that already great game. (Praise be to the Lords Giles & Ahruman !)

It would create complete solar systems in all the systems in Oolite, with:

1. 4-12 planets per system (~8 average)
2. Cities and stations with names where players and NPC`s can land on the surface (not really, but it would look like that, see below)
3. Meaningful in-system trading (like, outer dwarf planets being really cheap on resources like minerals, gold, etc., but really expensive and profitlike for food & textiles, gas planets really cheap on radioactives but very expensive for luxuries etc.) But, to reach an outer planet should take a real-life 20-30 minutes with witchdrive engines on ...
4. Planets that look like planets. And different. And medium (earthlikes plus the "standard planet" of the system), very large (gas giant) or small (dwarf world).

I have actually wasted a few thoughts on how to do this with existing oxp possibilities and without any changes to the core game. Here are my ideas (and, please, shoot them down in flames or even correct me if something is not possible the way I imagine it, I am guessing here via comparison to mods I have seen).

So, realisation of

@1.: I have seen in the lave.oxp that it is possible to script another planet into a system. And it seems to be possible to put it anywhere - so why not just script a number of planets into any system? If they have no real trajectories - who cares, if at least which planet is 1, 2, 3, or 12 stays constant? So, each system would have to designate a) number of planets, b) their distances to the sun, and c) their types and diameters.

@2.: OK, there are yet not city or even station mods for planets. But. I cant`t help noticing that with the "heat protection" equipment you can effectively reach (and shatter on ) 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.

The wild guesswork I do on this one is if it is at all possible to generate the same asteroid(s) and the same station (s) in exactly the same position in relation to the respective planet in question. But someone is bound to know. Is it possible at all to do this?

(Add-on: If the planet`s turning away under the hill/station just switching the planet`s turning off should be a solution)

@3.: I have seen that the amount that specific trading goods and/or equipment cost in specific stations in the same system can be changed, obviously hardcoded and, I believe I read in one of the new navy - debates, that it`s also possible to make prices specifically higher or lower. So, make food more expensive the further away from the sun you get and make gold, gemstones and minerals cheaper at the same time.

@4.: If its possible to have a texture on a planet at all, its possible to have a more high-res texture. And it would not have to be 2000+ textures. Take 10 textures each for earthlike worlds, gasgiants and dwarfplanets and 30 textures are enough for all the 15000+ new and old planets alike. Without getting too repetitive.

Biggest problem: 15.000 planets? Perhaps 100.000 additional stations & cities? Who should create them, name them, etc.?

My solution: Do it like Braben & Bell did. The same way they generated 2000+ systems with 64kb, and later a galaxy with 200.000.000.000 (!) systems with x planets, cities, stations each in Elites 2 & 3: Use equations! Each system now has a number and a galaxy, and is thereby identified. It would be easy (I studied physics, and I know how to do this if I set my head to it!) to create a formula that takes this designation and generates numerically for each system:

* how many additional planets
* what kind of planets
* which textures are used
* how many/which kind of stations/cities (on that one, the tech level of a system could be used in its equation)
* the prices of trading goods/equipment on each station

And as the equation stays the same, even if the stations and planets and so on are newly generated every time a player jumps into a system, they stay the same, too. Lave would, from the SolarSystem.OXP, say, 5 planets, with a hundred stations, and would stay like that.

The planets could then just be designated "Lave 1", "Lave 2", etc. To make things easier, the standard planet could always be the "XXX 3" - planet, etc. The naming of stations etc. and such would be more difficult, but why not use a similar method like the one Braben & Bell used when they named the systems of the eight galaxies?

So, I hope some of the people who`s help I would need for a SolarSystems.OXP are still with me (readingwise9 and have read through my wishful fantasies.

Oolite has rekindled my joy of playing Elite again after many years and I want to add something really meaningful to its experience - mostly for egotistical reasons. As what I suggest here is the kind of Oolite I would want to play in two years from now (yes, some rests of realism have stayed with me).

The most interesting thing would be, even the OXP-programmer(s) would not know which worlds and stations and places are out there afterwards

Megalomaniac Greetings,

Commander Lestradae

Its an ambitious project, but I think its doable (give world and time enough )! On the textures if you want to have a look at the Assassins OXP, its pretty easy to do. There's a screenie of of a gas giant in game on the Assassins Wiki page. It gives quite a nice Jupitor like effect by swirling round a simple texture (see also the planets in my Avanta). I deliberatley made it too small so when distorted it would look right). But if you make the texture the right size then it appears on the planet just as the image. So you can grab a PNG of mars (say) from the nasa web-site and bung it on a planet and there you go: Mars. There are enough planet pics on the web (if you include non-real planets from star trek etc, so in theory you could do it this way). Although this is the way I did it for Assassins, I was only modding 10 systems (and skulled the wall a few times getting a gas giant in the face as I'd mis-calculated its size or position and hit it on leaving w/s!). But I woudn't reckomend this approach for a mod of the whole Ooniverse.

The trouble is the shear size of the Download file. I only added planets moons and gas giants to 10 systems with Assassins, but each PNG is 24 - 60k. That stacks up if you have 8000 of the darn things!. Also doing this by hand having one by one (one planetentry list for each new world) would drive you completley insane! I could get away with using PNgs in Assassins, but to mod the whole galaxy I think you would have to Procederly generated would be the way to go. Although they're turned off atm the 1.67 procedural planets looked great with detailed costlines etc. If you have a look at Murgh's Disco OXP, this shows how it add a planet without using a texture.

addSystemShips: 0.[shippostion] is valid so I guess you could do the same thing with addMoon / addPlanet. You could also use desriptions.plist combined with a planet number check as PN = 0 set: gasgiant_type1 (then have your co-ordinates set in descriptiptions). etc. 240 different positions would give good variety (and would make it look like every system was different). You can alter the prices of stuff at a scripted station. Adding stations near a planet is also easy (see Assassins). Good luck with it! You can set an OXP station to have different prices for goods in commodities.plist (the HoOpy Casino OXP does this). I don't know how exactly as its not something I've attempted, but Commander McLane put up a long explantion of how it works on BB somewhere so if you have a search for that it should help.

EDIT : Only thing I don't think you could do currently is name the planets. But you could name the Station in orbit. The way of doing a planet landing is neat! Should work, but the "building" would probabley need a space compose beacon to find it.

*** <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!

Commander McLane wrote:

*** <warning> another monster post by the monster poster </warning> ***

Dear Little Bear & Commander McLane,

thanks for your extensive (and actually already very concrete and helpful) answers - wow! As I see that you have and still are creating/ed some of the really big oxps for Oolite your feedback means a lot to me.

I don`t know if I am really going to try this. If I do, I`ll not commit to finish it but, to borrow current NASA jargon, "work as I go". I have no idea if its possible at all.

Perhaps I have found a way to still procedure-generate most of the mentioned ideas if it can`t be done in-game: It should be possible to procedure-generate plists from seeds OUTSIDE the game only ONCE - and then put the generated plist into the game.

My whole idea is pretty whacky and enormous. But it represents all the things that would make Oolite perfect for me. So I coughed up a (at the moment, absolutely fictional) version number table. It contains a sequence that was deduced from your technical remarks in terms of sequence of work.

If I should realise something from that table, I will publish it in the expansions forum and if I lose interest other people can continue from there on. And I will ask holes into you people anyways.

So, now my fabulously crazy versions table for the proposed SolarSystems.oxp follows:

SolarSystems.OXP Development: Proposed Versionnumbers

Every step would be done by procedure-generation and via seeding - only once outside the game and then plists are made from those procedure-generated lists. Why do the same thing twice or a 1000times if you only have to do it once?

0.05 (Concept Study)
Experimental version, adds one procedurally-generated additional planet (say, the innermost closest to the sun) per system, and two stargates between this innermost and the "original" planet for intra-system travel - just for testing the workability of the whole basic idea

0.1 (Planets)
Adds 3-9 planets to all 2048 solar systems (Avg. 7 ~ 14000 new planets)

0.15 (Moons)
Adds 0-3 moons (0-1 for dwarf planets, 0-2 for earthlike planets, 0-3 for gas giants) per planet. Moon radius: Asteroidal (use biggest asteroids?), small spherical or earthlike (only gasgiants). Use moons sparsely.

0.2 (Textured planets)
Adds textures to all old & new planets (10 earthlike, 10 gasgiant, 10 dwarf planet)

0.25 (Textured moons)
Adds textures to all moons (perhaps 5 per moon radius version)

0.3 (Standard named planets)
Adds standard names (Lave 1, Lave 2 etc. with the "original" planet generally labelled "3") to all old & new planets

0.35 (Standard named moons)
Adds standard names (Lave 3a etc.) to all moons

0.4 (Oxp conflicts resolved)
All potential conflicts with mods resolved (by collecting - from friendly informers on the oolite boards - all known systems in which mods might collide with SolarSystems.OXP and removing the additional planets etc. from them)

0.45 (Standard system object conflicts resolved)
All potential conflicts with standard space removed (by utilising the system geometry, I think. No idea if that`s possible at all) Like, planet 1 very near to the sun. Planet 2 on the other side of the sun than the original planet. Planet 4 between the witchjump-point and the original planet 3, but moved 90-150° away in relation to the original planet. Planets 5 to (max) 10 (far) beyond the witchjump-point. So, collision probability with existing objects minimised.

0.5 (Systemwide planetary orbital space stations and stargates)
Orbital space stations added to the new planets (0-5/planet) according to planet type & position & the system tech level and named with the help of appropriate seed names "planet name"`s "seed name" "specific station template names", for example "Lave 4`s Gorbachev Habitat" or "Riedquat 2`s Astromine Gulag" and sprinkle the solar systems with planetnumber/2 stargates to reduce travel time to acceptable

0.55 (Systemwide lunar orbital space stations)
Orbital space stations added to the new moons (0-2/moon) according to moon type & position & the system tech level and named with the help of appropriate seed names "moon name"`s "seed name" "specific station template names", for example "Lave 3a`s Hoopy Casino" or "Riedquat 5b`s Callisto Citadel"

0.6 (Planetary orbital space stations completed)
Planetary orbital space stations designated specific equipment and trading goods structures

0.65 (Lunar orbital space stations completed)
Lunar orbital space stations designated specific equipment and trading goods structures

0.7 (Systemwide planetary surface stations)
Planetary surface stations added to the original and new planets (0-5/planet) according to planet type & position & the system tech level and named with the help of appropriate seed names "planet name"`s "seed name" "specific station template names", for example "Lave 3`s Capitol City" or "Riedquat 1`s Hellhole Mine"

0.75 (Systemwide lunar surface stations)
Lunar surface stations added to the original and new planets (max 1/planet) according to moon type & position & the system tech level and named with the help of appropriate seed names "moon name"`s "seed name" "specific station template names", for example "Lave 1a`s Pirate Settlement" or "Riedquat 6c`s Ecosphere Dome"

0.8 (Planetary surface stations completed)
Planetary stations designated specific equipment and trading goods structures

0.85 (Lunar surface stations completed))
Lunar stations designated specific equipment and trading goods structures

0.9 (Solar system traffic completed)
Trading routes between all new stations, worlds, and stargates, in orbit and on-surface added

0.95 (F4/4 solar system map available in space stations)
Another megalomanic idea to finish it all off. Utilise the up-to-today unused key F4/4 in space stations for the depicition of solar system maps?

1.0 (F4/4 solar system map completed - Final Version!?)
You can see all, say, 7 planets and 6 moons of the Lave system, and all, say, 14 orbital stations (including the original and non-secret oxp ones) and all, say, 7 planetary and 1 lunar station(s). For example. You can do so in all systems, but only in stations by pressing F4/4.

Isn`t it possible to make a, say, asteroid station invulnerable or give it such ridiculous shield recharge rates that it just survives the "permanent collision" if it is stuck into a planet`s surface? Then the explosion problem would be solved ...

Just an afterthought,

Lestradae

I agree totally with you that, if a procedural creation in-game is not possible, a maximally automatized plist-generation is the next best thing.

Still this is a lot of hand-work, of course. It may end up in some abandonded intermediant version. Or take virtually unlimited time to finish. Well, let's see! As I said, I don't want to discourage you.

My biggest concern is still the number of added objects per system, and the impact this may have on slowing down performance. There is e.g. one very populated system in Assassins.oxp, where the game needs about 15 seconds to populate it from LittleBear's script, as soon as you jump into it. For the player this looks like the game freezes, and this is continuously reported here on the board as a supposed bug or problem. So every time LittleBear has to explain that this is normal behaviour, but limited to this unique situation. A similar hickup on every arrival in a system does not seem acceptable to me (and would certainly not be to many players).

Thanks for your thoughts about backward compatibility! Indeed, one way to achieve this is to collect all systems that already have been changed, and exclude them from your OXP. But what about forward compatibility? Any future change in any system by another scripter would require a new version of SolarSystems.oxp, with the new features being removed from the system in question. This seems not very practically to me, to say the least.

The idea of stargates has been proposed a couple of times, and has been rejected so far. So this would need some more discussion. Apart from that I don't even know whether it's possible.

Yes, you can try to give a ground-structure a ridiculously high energy and energy recharge (should be both). I can't guarantee that this would keep it from blowing up, though. I can't even tell from my head whether it could do reverse damage to the planet or moon, although I guess not (planets are another type of entity in the Ooniverse than ship-type objects). But at the very least the continuous collision calculation would eat up processor resources, and we are talking about dozens of continuous collisions here. A continuous slow-down of the game could be the result.

And finally the F4-screen. There have already been several requests for usage of the unused key. So far none of them has been granted. So yours would have to line up with them in the queue.

That's what I see for the moment. Anyway, just start, try out some planet positions in perhaps one system for a start, and see how far you get! I am ready to answer any question I can, but I won't be involved in scripting this (just in case you had something like this in mind). This is your OXP, so you have to do it.

Have fun!

> I agree totally with you that, if a procedural creation in-game is not possible, a maximally automatized plist-generation is the next best thing.

Yes, and maximally automatized plist-generation outside the game would also have advantages for compatibility backwards and forwards with other oxps, I`ll get to that again.

> Still this is a lot of hand-work, of course. It may end up in some abandonded intermediant version.

True. That`s also why I created a "to do" versions list. Perhaps I`ll not even get to version 0.05 and perhaps I`ll get beyond version 1.0. If I even start, the fun would have to be in the journey, not the arrival ... or so I tell myself

> Or take virtually unlimited time to finish.

I don`t want to hear that! *sticksfingersinears* Lalalala ...

> Well, let's see!

Exactly ...

> My biggest concern is still the number of added objects per system, and the impact this may have on slowing down performance. ... A hickup on every arrival in a system does not seem acceptable to me (and would certainly not be to many players).

This is a problem. But Oolite came out of the idea that Elite in its older versions was no longer adequate for today`s hardware. How will or could Oolite look in 5 or 10 years? The hickup might not be there to stay due to tomorrow`s better hardware, and eventually disappear.

I somehow like the idea that Oolite might continue to grow and get updated decades into the future, so that the Oolite 4.50 with its twothousand oxps of 2030 is still interesting even for people who would have been playing it for 20+ years ... ups, megalomania again

> Thanks for your thoughts about backward compatibility! Indeed, one way to achieve this is to collect all systems that already have been changed, and exclude them from your OXP. But what about forward compatibility? Any future change in any system by another scripter would require a new version of SolarSystems.oxp, with the new features being removed from the system in question. This seems not very practically to me, to say the least.

Well, but. If the plists have been procedure generated outside the game, individual systems could be altered by hand to fit together with other oxps from the past. All the new features could actually stay, together with the old oxps.

If, for example, LittleBear decided to tell me exactly where his Assassin`s structures and places are, I or he or someone else could change the SolarSystem.oxp`s settings for those places so that nothing collides. Complete backwards compatibility available!

And if someone wanted to create a new oxp, they could use the features of the SolarSystems.oxp for their own purposes - why not, i.e., use "Riedquat 4`s Darwin Prison" as the place where your missions start, and add a town? And so on.

> The idea of stargates has been proposed a couple of times, and has been rejected so far. So this would need some more discussion. Apart from that I don't even know whether it's possible.

Well, you pointed me to the "boring" problem of inner-system travel if the distances between planets were as up-to-scale as possible in Oolite.

So, the "stargates" would actually be exclusively intra-system gates. And not too many of them - just so that, for example, in a system with 7 planets there would be three or four gates that don`t transport you all the way - but perhaps using one you would be about the distance witchjump-point - original planet to your destination.

You want to get to, say, Lave`s innermost planet, Lave 1. So you use the stargate of Lave 3 (the original planet) to jump into the direction of Lave 1 and come out on the other side of the sun. You don`t have to travel for 10 minutes using up your witchdrive fuel - but its not around the block either. You still have to travel and survive eventual encounters - like, say, pirates lying in wait for whatever comes through that stargate next?

> Yes, you can try to give a ground-structure a ridiculously high energy and energy recharge (should be both). I can't guarantee that this would keep it from blowing up, though. I can't even tell from my head whether it could do reverse damage to the planet or moon, although I guess not (planets are another type of entity in the Ooniverse than ship-type objects). But at the very least the continuous collision calculation would eat up processor resources, and we are talking about dozens of continuous collisions here. A continuous slow-down of the game could be the result.

That`s a problem. But perhaps I cross that bridge when and if I reach it - version 0.70 or work step 14, methinks. Perhaps, when/if I get there, hardware acceleration or an update to Oolite itself will have solved my problem.

Hmmm ... perhaps in the code of Oolite itself, collisions between stations, asteroids and planets could be switched off? Just an idea. Perhaps Ahruman knows if that would be possible at all?

And, uhm, if its desirable to do this is another question. No idea what can of worms that might open. First question is, possible or not?

> And finally the F4-screen. There have already been several requests for usage of the unused key. So far none of them has been granted. So yours would have to line up with them in the queue.

Well, if I really get into the direction of finishing this oxp I might add that in myself. And complete solar systems would, if realised, speak for themselves if it made sense to be added in as a screen. It would not have to be F4/4, anyways. Just a key that only works in stations.

> That's what I see for the moment. Anyway, just start, try out some planet positions in perhaps one system for a start, and see how far you get!

That`s what I already had in mind

> I am ready to answer any question I can, but I won't be involved in scripting this (just in case you had something like this in mind). This is your OXP, so you have to do it.

Thank you very much, I will come back to your generous offer! (Actually often, if I really start this) And for involving other people in this to do some work ... no, nooo, the thought would really, really never cross my mind

> Have fun!

Thanks! Right on, Commander!

Commander Lestradae

Hmmm ... perhaps in the code of Oolite itself, collisions between stations, asteroids and planets could be switched off? Just an idea. Perhaps Ahruman knows if that would be possible at all?

Switching off collision detection would not be a good idea, I think! Why should asteroids fly through stations or planets? Makes no sense.

Well, if I really get into the direction of finishing this oxp I might add that in myself. And complete solar systems would, if realised, speak for themselves if it made sense to be added in as a screen. It would not have to be F4/4, anyways. Just a key that only works in stations.

Adding new key-functions can only be done in the code of the game itself. So you will have to plea with the lead programmer anyway, whoever this will be, when you have reached this stage of development.

By the way: If you use the

-button in your post, things become more readable.

Lestradae wrote:

"Riedquat 4`s Darwin Prison"

We mustn't be talking about the same Riedquat, then... Riedquatian justice is well-known for its summariness.

If you have a look at the spoilers section of the Assassin's readme it lists the names and planet numbers of all the systems modded. I woudn't worry about the slowdown too much. On a very old system like mine Assassins does cause a 15 second hang on leaving witchspace when entering the systems where the "Civil War" and "Thargoid Invasion" missions are running at certain systems, but this is because I'm spawning well over 300 ships in these missions, so even with (say) 30 stations a 1.5 second wait on leaving w/s is not gonna cause a noticable slowdown.

Oh, another thing I had second thoughts about:

Are you sure you want to rename the original planet in each system planet"3"? Usually the planets in Oolite are so close to the sun that I doubt you could reasonably squeeze two more planets in-between. I'd rather think the original planet would in most cases been the innermost.

That's partly due to the fact that not so much the sun, but the witchpoint is something like the system center.

Have a look at Lave.oxp, which changes the Lave system according to the infos given in "The Darkwheel", which is canonic (if there is anything worth to be called canonic, then it's this). It places Lave's moon close to the witchpoint, that's roughly 400,000 meters away from the planet. The sun, on the other hand, is roughly 850,000 or 900,000 meters away from the planet, only twice the moon's distance. In a real planetary system you couldn't even place one planet between Lave and its sun, let alone two of them (one would have to be within the moon's orbit; impossible!).

As I said before: sizes and distances in Oolite are hopelessly screwed up, they can't make sense, how hard you ever try. Nevertheless I guess you want to look your planetary systems as realistically as possible. My advice for achieving that: let the original planet always be the innermost.

@Little Bear:

Thanks for the input, too! I also think that the lag with triple or even quadruple more objects should become manageable in time. Our hardware is getting faster all the time anyways.

@Cmdr. Maegil:

If you think the Riedquatian justice system in the well-known "Darwin Prison" would have lost its EFFICIENCY, look closer at the meaning of the words. This prison works by selection So, don`t worry, only the corrected will leave this prison, and they will never, ever choose to do something that gets them into the correction system again. We have everything under control in the prison!

@Commander McLane:

Yes, to put the original planet at place 3 does, methinks, make sense. First of all, the most habitable planet with perhaps the system`s capitol city / station will probably be the third on average.

Second, I have ideas to hide the absurd distances:

Put planet 1 on the other side of the sun from the original planet, at a distance of roughly 150000 metres from the sun. A hot encounter, and the planet is not visible from the witchpoint and "planet 3" although noticably closer to the sun. Ridiculous dimensioning hidden.

Planet 2: Say, 450000 metres from the sun, but moved clockwise around the ecliptic for 120°. Is closer to the sun, looks reasonably farer away than it is from both planets 1 and 3, again strange distances smoothed over.

Planet 4: Perhaps 1.500.000 metres from the sun, a bit beyond the witchpoint, so already farther away. Could also be put 120 ° from the line original planet - sun in the other direction than planet 2. Again, looks pretty far away etc.

All further planets might get ridiculous distances, such as multiplying the distance from the sun by 2 for each further step, i.e. planet 5 3 million metres further out, planet 6 6 million metres and the rare planet 10 a rough hundred million metres.

There is no way, though, to hide the fact that those worlds will not look like points - but to go that far would mean to mess with the whole game engine and I`ll not even think about that. I`m pretty sure that there`s no way I technically could, even with the help of my friend, anyways.

That`s the way I have it in mind at the moment. Perhaps I change my mind when I see the first test system with this But I believe it should look acceptable ...

Greetings to all of you,

Lestradae

Lestradae wrote:

> But Oolite came out of the idea that Elite in its older versions was no longer adequate for today`s hardware. How will or could Oolite look in 5 or 10 years? The hickup might not be there to stay due to tomorrow`s better hardware, and eventually disappear.

I somehow like the idea that Oolite might continue to grow and get updated decades into the future, so that the Oolite 4.50 with its twothousand oxps of 2030 is still interesting even for people who would have been playing it for 20+ years ... ups, megalomania again

Maybe I misunderstand you, but I dont agree with what I think you mean

I think oolite came out of:

It was written by Giles Williams as a response to the withdrawal of Elite: The New Kind from the internet. Although inspired by the work of Christian Pinder, following David Braben and Ian Bell, the work is an independent interpretation and expansion of the original game.

Oolite is designed as a small game that is easy for users to pick up and expand upon.

I would like to see oolite continue as a game that is basically just elite, a few more ships, missions, fixes to bugs etc. We could all be working on vega strike, or playing any number of space sims with more real physics, better representation of the real world and so on. But we, or at least I am here because I want to play elite. Oolite has many new features, relative to elite, such as purchasing new ships, but it is all very much in the spirit of a simple non-newtonian trading and dogflighting game.

Its true that I enjoy the nice new colors and textures, and that I do not play in one color unfilled vector graphics (the way it *should* be :p ), I do not even play in strict mode. But I do want everything to be in the spirit of elite. I dont even like the starwars ships (well, I do, but they dont fit with the feel of elite, its a different universe).

I think in the future we may need things like sets of oxps -- so that people can choose a set of consistent tested missions and ships that work together. I do worry about trying to set up a new installation, and choosing between hundreds of oxps, each including new ships, missions and system changes. It would be nice to have a manager of some kind, that I could disable and enable, test configurations for conflicts etc.
Maybe we will have some kind of fractal generation of planetary surfaces so we can see mountains and so on. Maybe the often requested MMORPG will be written. But the real game itself, the gameplay, the kinds of activities that can be performed should be very similar.

The last thing I want is for oolite to be brought up to date.

Well, just take Lestradae's suggestion as what it basically is: a megalomaniac idea that most likely never will see realization.

I commented in-depth on his idea, in most cases argueing with the sheer technical difficulty he will be facing. And I think the summed up technical difficulties are enough to derail the whole project. So IMO you don't have to worry.

As far as the basic solar systems-idea is concerned, my approach would be completely different from Lestradae's. First of all I would go with something in the spirit of Tianve.oxp: Not flood all the eight galaxies with multiple planets, but take a very limited area, just a handful of systems, let's say in one of the (hitherto unused!) corners of one of the galaxies, and convert them into the galaxy-famous "Planetary Zoo": For miraculous reasons in this handful of systems there are multiple planets that are beautiful to watch. "Come and enjoy the unique multi-planet worlds in the south-west of Galaxy 6" or something like that, together with an add in Your Ads Here. And second I would confine it to the planets itself, without all this extra-stations-teleporters-and-landing-features stuff.

This would IMO be a pretty addition to the Ooniverse, like the Tianve Pulsar is, without dominating the game and transforming it into something it was never meant to be.