|
Pages: [1]
|
 |
|
Author
|
Topic: graphical questions (Read 2467 times)
|
Crazy_Pirate_unInc
Zebranky food
 Offline
Posts: 24
Yarrrr!
|
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.
|
|
|
|
|
Logged
|
We pillage, we plunder, we rifle and loot.
Drink up me 'earties, Yo Ho!
We kidnap and ravage and don't give a hoot.
Drink up me 'earties, Yo Ho!
Yo Ho, Yo Ho! A pirate's life for me.
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
1. You shouldn't touch MAX_SUNS. The fact that it is a define suggests you could change it, but the rest of the code depends on there being just one sun.
What you can change for planets in plandata.c is the planet types, not individual planets. You don't want to change that. For more information on how solar systems are generated, start with doc/devel/generate. The systems for which the system generation is overridden have their code in src/sc2code/planets/gen*
2. This may require some recoding. See src/sc2code/units.h, starting by CIRCLE_SHIFT. Changing CIRCLE_SHIFT should increase the number of directions, but there's all sorts of places that use it that would need to be changed too, such as how much you turn when you press a turn button, and how much images are used. Calculating sin and cos is also done by lookup tables, which would need more entries.
3. That angle is only used for the positioning of the planet, namely at 7/8 of a full circle.
4. Those dimensions are depended on throughout the code. You'll need to change a lot if you want something different there.
5. src/sc2code/planets/orbits.c, in FillOrbits.
if (GeneratingMoons)
MaxPlanet = FIRST_LARGE_ROCKY_WORLD;
else
MaxPlanet = NUMBER_OF_PLANET_TYPES;
6. Change SOL_X and SOL_Y in races.h too, and the same numbers in ships/human/human.c.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
|
|
|
|
Crazy_Pirate_unInc
Zebranky food
Offline
Posts: 24
Yarrrr!
|
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?
|
|
|
|
|
Logged
|
We pillage, we plunder, we rifle and loot.
Drink up me 'earties, Yo Ho!
We kidnap and ravage and don't give a hoot.
Drink up me 'earties, Yo Ho!
Yo Ho, Yo Ho! A pirate's life for me.
|
|
|
|
|
|
Pages: [1]
|
|
|
|
|
