The images should now be available.

@Draxas:
Magma world is now complete to my satisfaction. I may reduce the size of mineral deposits, but hell. I mean, they're very very rare in the current setup. The differences are in the amount of surface lava present on this (the magma world) than on a shattered world. The difference is subtle, but it's there.
http://cec.wustl.edu/~snh1/cookies/cookies11.png

Mountainous worlds are also implemented. I kinda like this, actually, though I wish there were more obvious peaks and valleys. Though in hindsight, it kind of reminds me of a telluric world. 
http://cec.wustl.edu/~snh1/cookies/cookies7.png

And now, for Junk Worlds. This one took quite a bit of work, but I think it looks like a world covered in rusty machinery and seas of toxic effluvia. I may in fact beef up the mineral deposits to make it even sillier, but that's up to you, really.
http://cec.wustl.edu/~snh1/cookies/cookies6.png

Something that just sort of happened are these two pictures:
http://cec.wustl.edu/~snh1/cookies/cookies10.png
is an early concept of something we developed into this:
http://cec.wustl.edu/~snh1/cookies/cookies8.png
We decided to call it a "Poison World", currently it's got (as you can see) a few radioactive deposits but I'm hoping for mostly commons and corrosives, along with some others if at all possible.

@Lukipela: That is intriguing. Our next real project is to configure our random starmap generator for devices and special solar systems with predetermined planets and such. Once we get our heads around device code we may attempt just that.

(edited for crappy link wrapping)

Oh... wow.

We got a magma world prototype, but Mercury is funny in that if you stick a shattered world or a magma world there, it is a featureless gray ball.

Pending our understanding of production of new graphics there will be artificial worlds and mountian worlds. Not to mention a new lifeform, the Commander Keen inspired Yorps, that will be worth decent data but will crowd you harmlessly and annoyingly.

Re: Mineral requirements for stuff... WOW. That is out of our current reach and goals at the moment. I may just adjust the RU rewards table, silly as it is, for the moment.

One idea we had was something like this: on initial conversation with Melnorme, they say they'll give you technology to build a "garden pod", a self contained cargo bay for the lifeforms you bring back for them, and equip you with one for free. More modules is something we've wanted to do for a while, as well as the possibility of people who will sell you different modules.

Yes, shots have different values for damage and hit points.  If you want I can post a whole list of 'em later.

You know, that's good enough for me. That a Magma World just doesn't have a frickin' Mycon egg case on it. I made something like it but it didn't quite work out.

I think I even have a plan. I will attempt to make several demo worlds and upload screenshots to see if they add up to what you were expecting.

We've had some thoughts about this ourselves. One idea was to rebalance the RU/kiloton of stuff curve, but even then you've just got to improve radioactives and precious even more to make room. For example, if you curve it so that it goes something like:
Common / 3
Corrosive / 4
Basic / 5
Noble / 6
Rare / 7
Precious / 8
Radioactive / 9 or 10

It's still not worth it to pick up commons because it takes lots of fuel to land repeatedly, and it takes fuel to go to different systems, and time to pick up all that stuff, etc. And Urea Worlds have been abolished... those were such a pain in the butt it was foolish. Though Orz space was so silly... it was easy to pick up 800+ precious from one or two systems, which was absurd. It was really cool, but it wasn't like treasure or auric worlds were especially hazardous beyond class 3 weather.

However! In fooling around mining our expanded starmap, we've definately found that 1) we need to make crystal worlds rarer because finding a crystal world with two crystal world moons is really really silly and 2) it's much more tempting to pick up lots of minerals and even more basics simply because that much more fuel can be allotted to picking up those other minerals.

Hell, you know, that table doesn't look too bad. But there's something elegant about commons giving you one RU... ah well. At least this way radioactives are only three times as good as commons and twice as good as bases, as opposed to eight times and three times respectively.

@Death 999 / Draxas: I've thought about that... What's really silly is that there are WATER WORLDS. I mean, crap, just take the lander down in the ocean and scoop some up and go. There would only be deposits of water ice on things like selenic worlds, and there's no real way to just say you can collect as much commons as you like at a water world.

Unless you feel like making water worlds have ridiculous quantities of water deposits, which is in fact entirely doable. I just think it would be annoying to have to dodge water deposits. One thing we did was diversify the mineral deposits on dust, water, and to a lesser extent selenic worlds (yay wikipedia) to make them more worthwhile and reflect vague reality. It's pretty interesting, actually. Tomorrow I hope the crew can assemble and we can get some screenies.

@Draxas: Your idea of an Artificial World intrigues me greatly. Would you mind if it became a reality some day? Magma Worlds (unfortunately) existed and were total lemons (and as such discarded, because there were enough basic covered worlds). I've yet to come up with a way to distinguish a world like a primordial earth from a Shattered World, both in the appearance and in mineral deposits. If you've got any ideas in that regard, fire away.

@Razorback : We'll have to investigate the "more than 10 planets" thing later, because while one chunk of the source code (and the strings for that matter) indicate that support for up to 16 planets was intended, it definately has an override later limiting it to 10. We've bumped that number up above 10 before and it causes crashes. We shall investigate in the future.

Currently, our only new planetary object is 50000 Quaoar, which I chose because it was of a decent size and it wasn't ridiculously far from the sun. Thing about Sedna is that it is so far away to have it just chilling outside pluto would be pretty inaccurate, and I don't feel like coding in another zoom level (and then doing all the art)  in order to accomodate it. Though come to think of it, it would be pretty neat. Because the solar system is pretty enormous. Even then, we may ditch Quaoar because it is far less say-able than Sedna, Xena, or Gabrielle.

We've also beefed out the moons on the "crappy" gas giants of the solar system. Earlier in the thread there's a full list, but since we increased the moon cap to five we may expand the solar system even further.

What I was thinking about when I said more planets was something like this:
http://cec.wustl.edu/~snh1/cookies/cookies5.png

 Argent World : a counterpart to the Auric World, with silver and silver compounds, white-body planet, with the selenic color tab, topographical algorithm surface generation and the same xlat tab as an Auric World. We've gotten them working right except for the Fscking strings, and screenshots will come eventually. There are tons of little tweaks to the planets, including dust worlds worth landing on (based of course on the composition of mars and its atmosphere) as well as buffing the deposits on selenic, infrared, hydrocarbon, telluric, noble, and water worlds to make them competitive with things like Auric worlds (which have thicker precious deposits than noble worlds).

What I'm getting at is that we need more planet TYPES, and any suggestions are welcome.


@Bongo Bill: Now THAT is a pretty sweet idea. Even now, we are investigating the creation and implementation of plot through devices. Your contribution WILL be noted, Sir. Heheheheheh... hidden stars. Maybe in quasispace somewhere? Though making objects you interact with in hyperspace that don't appear on the hyperspace map is odd. It's worth investigating.

Short answer: Not Easy.

Long answer...  I like meep-eep's response to another thread: "Given enough skill and time, anything is possible."  However, UQM's core code is written to be efficient, not to be easy to change.  Either learn C pretty darn well or find someone who already has, and be prepared to spend a lot of time grovelling through the source code.  You're talking about more or less completely re-writing a pretty major subsystem, after all, and it's not one we've even looked at yet.

Good luck, either way.

BYARRRR!!!

What be tha point of our mod? Why d'we keep on postin' 'ere?

Because we care. We care, in fact, enough ta do this.

http://cec.wustl.edu/~snh1/cookies/cookies4.png

"What in tha name of Davey Jones' vacsuit be wrong with those thar planets?!  And WHUT THA SWEET DEVIL IS WITH THE MENUS?!" We hear yer plaintive cries.

As to tha first part, well, the First Mate noticed that tha surface temperature of Venus was significantly lower than tha meltin' point of cannonballs. He also figured that tha idea of a Greenhouse World from tha old SC2 PC manual was a pretty durn decent one and reasoned that thar ought ter be a way ta make sure such an "increase o' surface temper-churr based on at-mo-sfeer-ick den-city" (errr... or summat like dat) wurr possible. And ARR! Before ye ye see tha proof! GARR!

And, err, to tha other bit... Mind now - tha strangeness with tha menus is temporary, or so tha Captain assures me. (In fact, with the rather incredibly prompt and generous assistance of Meep-Eep in solving our newbish problems we've already fixed MOST of the problems, arr)

O' course, should we be unable to fix tha leak our vessel of a mod has sprung, there shall be a MUTINNNNY!!

Other projects in progress:
Starmap randomizer: We've refined it to have weights of dwarfs, giants, and supergiants, as well as star classes. Currently we've adopted a model that slightly more realistically portrays the real universe, with something like 33% of stars being red and 6% being blue or something. We may even do away with blue dwarves, seeing as I don't think they actually exist. I know blue white stars exist in dwarf class, but hell.  Green stars probably shouldn't be quite that green, either, even if it is kinda pretty.

Next up we're going to tackle plot item randomization in the starmap randomizer. This is only scary because we'd like to ensure that the plot items are spaced sanely, so you don't end up with Sol chilling out in the middle of Ilwrath space or worse, the Ur-Quan / Kohr-Ah battlefield. Also, my personal pipe dream is to integrate it into the game itself, as an option in the Game Options (including a "no random stars", "<x> additional random stars", and "completely random including plot point stars". The reason this is a pipe dream is that it's easier to tell a python program to change the coordinates for all the plot points in the dialogues than it is to tell Starcon's code to do the same thing.

Devices:  We need to work out how devices work, both in your device list and on planets.  We haven't even looked at this stuff yet, but considering how much of SC2's plot works around devices, it seems the next logical step.

64 turn arcs: This is back burner'd but not forgotten. This project is also hampered by SC2's... peculiar math system.

PIRATE REQUEST: If anybody has any cool ideas for extra planets, shoot them at us like cannonballs. Cause I'm thinking new planets are cool.

Cheers!

What we did, is go straight through our list of planets in plandata.c, then wrote strings for each in starcon.txt. So, in plandata.c, we have oolite world, yttric world, etc, etc, final small rocky world, then large oolite world, large yttric world, etc, etc, diamond world (final large rocky world). So we made a string for each. The large versions of small worlds (and vice versa) were intended to have the same "game" name. So you'd go to a large oolite world and you'd still see the string "Oolite World". To do that, we'd write in starcon.txt #Large_Oolite_World
Oolite World

Interestingly, some strings are distorted while others are not. For instance, every planet readout is completely nuked. Scrambled like crazy. However, star postfixes are correct (which, thinking back, makes sense as they show up before the planet type names) while the prefixes are some of the planet names (hooray for Magnetic Columbae).

So, does that clear it up any?

New question: how does starcon.txt organize planet names? It's not by their order in plandata.c or .h, yet that's how they're organized in orbits.c...

Thanks a bundle!
Us

DrunkenWolf: Aye, we be knowin' that.  'Owever, that be takin' time, an' as th' UQM program already knows 'ow ta use diff'rent sprites, makin' it rotate tha same sprite woul' be e'en more'f a hack-job.

Now!  We've bein' havin' some success the last week or two, an' return 'ere amidst much grog 'n' tacos ta revel in our triumph.  Be'old!

http://cec.wustl.edu/~snh1/cookies1.png

Five moons, baby.  Count 'em, FIVE.  An one jus' so 'appens to be a gas-giant.  I keep tellin' me first mate that that thar's utter insanity, but ye gotta admit 'tis cool.

http://cec.wustl.edu/~snh1/cookies3.png

Aha!  Fear the comin' of our bran' spankin' new starmap randomizer program!  Now, our trained monke... erm, programmers may've gotten jus' a weeee bit o'erzealous on certain bits, but e'ery star there is real, and the original SC2 starmap is bein' in thar somewhere if ye look reeeeeal close.

An' now, just for kicks, we be givin' ye the starmap randomizer isself!  We'll be tweakin' an' changin' things with't 'till it be givin' us the right results, but 'ere's the prototype we 'ave now.  'Tis GPL, since UQM is, and we be includin' the UQM starmap info in it, so 'tis technically usin' th' same code methinks.

http://cec.wustl.edu/~snh1/random-starmap.py

Yers with FIRE AND DOOM,
Crazy Pirate unIncorperated

Positions and dialog would be the easiest part.  Artifacts would probably be relatively simple, too...  Victory conditions I don't know about, as we've not looked at that bit of the code yet.

O'course, this is still a big ol' project in it's own right, as ye have to design the plot, write the new dialogs and all that stuff.  Though if you have a small group of people and a few months, and ye are not afraid o' messing with some fearsome code and getting yer hands dirty, 'twould be a doable project.

And who doesn't, matey?

Byarr, we be havin' some luck with tha Newtonian physics by gerrymandering... nar, errr... keelhauling? Jury-rigging! tha blasted Pkunk's code. Unfortunately, they were... unwilling ta part with it willingly.

So we parted tha Pkunk, y'see, with cannonballs. 'Twas an excellent skarrrmash, arrr.

Screenshots be forthcoming on a bugfree hackjob. Tha firrst vessel we be fittin' with accurate physics be the Chenjesu, gyarr.

Buckle up, me hearties, arrr!

Hey folks. This was inspired by a number of strange little things and vague wishes for cool stuff in the real world to happen in UQM. With the copious help of a too generous friend, I've been able to realize a few of these dreams. Success with some of the more ambitious ones has been a little less forthcoming, and so I was wondering if any kind soul would be willing to shed some light on them.

1: When I go to plandata.c and add a new planet that is, instead of a small_rocky_world, large_rocky_world, or a gas giant a dwaf_star... it keeps looking like a small rocky world when I call that type up. Earlier in our experience, small blue rocky worlds were the default for undefined planets; we'd screwed up planets.h and plandata.c and had gensol.c and planets.h looking for entries that didn't exist in plandata.c and lo, there were a number of small blue rocky worlds that were black voids when approached.

However, when I tried to make an dwarf_star orange_body at the edge of the Sol system, I got a small_rocky_world orange_body (like in the prior build). Also, when I went to orbits.c or one of them files in the planets directory, all stars disappeared when I set max_suns to 2. Essentially, I am wondering where the code governing the behaviour of a star in the system exploration mode would be and was wondering if anybody knew how to duplicate those effects as a randomly generated planet.

2: Another far more ambitious goal was increasing the maximum number of turn arcs to 64, and if anybody has even a clue about where to begin there, I would be much grateful.

3: Here's an interesting one. Now, UQM generates planetary orbits as if they were a circle viewed at an angle, which means they are drawn as ellipses. Gensol.c's entry on pluto seems to suggest the makers intended Pluto to be offset in the system view as it is in real life with the line "angle = FULL_CIRCLE - OCTANT;" yet its orbit is concentric with the rest of them. Is this having some effect I'm not noticing, or is it just nonfunctional? Or is it none of the above?

4: I'm attempting to make zones beyond 0,0 in the negative (eg -670, -500) logical places for the SIS to fly. Somehow, my friend managed to make the positive zones beyond 999 flyable (though the coordinates display exploded, showing impossibly small numbers) but never those dimensions. Any tips?

5: Second to last question. What file governs which planet types are called up for moons?

6: Last one: Gensol.c specifically generates all events and planets in the solar system, so it seems to me that as long as those planets are placed around a yellow dwarf star it should function properly wherever it is. However, when sol is moved from 175.2, 145 the game explodes. Is there some special information in the random seed that is special for Sol, or do too many plotline events refer to the location 175.2, 145 for it to be moved?

Thanks for all the fish,
Us.