User:Commander McLane

Youth and early TV-existence

Commander McLane can look back to a long and successfull career in a German TV-series of the sixties, which brought him something like a cult-status among German SF-addicts. Serving in the Space Patrol ('Raumpatrouille') as captain of the fast cruiser 'Orion', he mastered many an adventure, technically sometimes way ahead of the crew of the USS Enterprise, whose escapades were aired at roughly the same time. The series was especially famous for the use of ordinary household items, like plastic beakers, electric irons, etc., as props on the ship's bridge.

Rebirth in the Ooniverse

Commander McLane came into being again at 2084004 under the pseudonym of 'Jameson', but quickly was restored to his original name. His famous ship, the 'Orion', however, had been lost in the maelstrom of time and was replaced with an ordinary Cobra III. So his quest for becoming famous again and regaining a decent ship started. Now, at currently 2085323, about three and a half years later, he is a proud member of the Imperial Courier Owner's Club and can again look back on an impressive career with a killcount that just passed the 18000-mark and a comfortable financial cushion of over fourteen million credits in the bank. Currently located in Galaxy 8, he has two major objectives. He is having fun with a lot of assassinations, while at the same time trying to sell large amounts of precious metals for as high a price as possible. For the future beyond these pastimes—considering his financial and reputational background—he may be reflecting either one of two major options, namely an early retirement, continuing to fly his Imperial Courier only for leisure reasons, or starting another quest for Raxxla.

For the time being, however, his progress in any of his career activities is slowed down, mainly due to other activities that require a lot of his time and will be described in the next section.

Contributions to the commOonity

Commander McLane is also known as one of the major contributers of the Oolite Bulletin Boards and takes even a little pride in having been able to contribute some of his thoughts to the community. Among these are externalviews.oxp, that fixed some issues with the custom views of the ships of the original set and was included in Oolite itself since version 1.70 (making it obsolete as an OXP), and Anarchies.oxp (now in version 2.5).

He is working on some other OXPs, which are still very much work-in-progress, but one day hopefully will see the light of the world under the names of ghosts-from-the-past.oxp and equilibrium.oxp. Another work of his has been released as his first mission OXP under the name of Cataclysm.oxp. Other than that, he has spent some thoughts on variations of the economy in the game which ultimately lead to BlOomberg Markets OXP, and on the lack of an in-flight-communication system in Oolite, which has led to the small interstellar_help.oxp, and is toyed with by other scripters closer to the code as well. Furthermore it is giving him great pleasure to meet other well-known commanders out there in the Ooniverse, and (sometimes) to prematurely end their careers. Tidbits of his scripting can also be found scattered around in the Ooniverse, in other peoples' OXPs. He also may be persuaded to develop small fixes for issues which pop up in other players games, like creating a more even distribution of police ships, making Q-bombs behave like it is written in the book, or enabling players to keep track of their reputation.

Other interests of his include, but are not limited to, bug-squashing activities in recent versions of Oolite, requesting ever more methods, keys and commands for scripting, and more complicated quests like Understanding commodities.plist or the more occult features of quaternions.

A list of available OXPs made by him would have to include:

• Anarchies.oxp
• Asteroids3D.oxp
• Auto Eject.oxp
• Cataclysm.oxp
• Display Reputation.oxp
• Dock Assist System.oxp
• Fireworks.oxp
• Flying Dutchman.oxp
• Generation Ships.oxp (overhauling Draco_Caeles' ground breaking OXP)
• Interstellar Help.oxp
• Killit.oxp
• NPC-shields.oxp
• Offender traders.oxp
• Personalities.oxp
• Railgun.oxp
• Randomshipnames.oxp
• Sell Equipment.oxp
• Stationrotation.oxp
• Status Quo Q-bomb.oxp
• Thargoid carrier.oxp (overhauling Selezen's OXP)
• Total Patrol.oxp
• Wormhole restoration.oxp

And now for something a little different

• Commander McLane and the infamous Biargeian edible poet to Soylent green conversion scandle

Musings

Commander McLane seems to have had a major influence on the early development of Oolite. Partly through his programming (some of his OXPs were incorporated into the Vanilla game code), but also partly through his explanations of knotty issues (eg that the GalSec stations are provided by GalCop and that the individual systems contribute financially, explaining the disparities in police/pirate presence - this then provided the logic for new OXPs based on this).

For an example of his insights see this:

Lestradae had suggested producing a Megalomaniac Solar Systems OXP adding in planets, moons and planetary landings (back in 2007 - back before orbiting planets and before planetary landings - both were introduced in 2008)

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

Hi, Lestradae,

I agree with you: this is a megalomaniac idea (not only somewhat)! :wink: And you may hit reality pretty soon pretty hard. :x

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 awfully 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. :wink: (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 hindrance, 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! :D

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. :wink: 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 (Editor's Note: Commodities.plist is now deprecated).

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:

http://img253.imageshack.us/img253/2141/ghostsplanetaxp3.png

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:

http://img253.imageshack.us/img253/3695/ghostsplanetbbo0.png

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 :wink:). 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 :wink:), it's surely going to be a gorgeous OXP.

So good luck with it! :D