The "consistent systems" project.

[Fireskull]

*We need to make it so sectors are logical, this doesnt means they have to be realistic, but they must follow certain laws and guidelines. Like.. "a average sized planet in WCU will have a diameter of 4000kms". This kind of thing needs to be stabilished so I can write the sectors and make them look at least believable.

issues: ( i need the opinion of you guys on this, cause I dont think it would work if i decided it all by myself and just sent it over to spirit )

-Fixed planets or planets that have orbits?

Fixed planets could have either real suns or "real far away ones" "Real far away "suns are like the ones you see in gemini sector, real suns are like the ones you see everywhere else. Planets with orbits cant have "real far away suns" cause they need to orbit something

-In the case we want orbital planets, I will have to change -everything- in Gemini Sector. The planets and units in gemini ALL have static places. troy would be a nice example. The system would have a star at its center, and helen and the two mining bases would orbit it.

What I first wanted to do was to have both mining bases orbit Helen, you would think thats quite logical... but then cargo runs in Troy would become just boring. But there are some systems where thats the logical thing to do... what brings me to my next issue, and thats the most important one IMO.

- The systems in privateer were designed with fixed planets in mind, and they also were designed with a smaller amount of bases than the ones we can work with it now. I could change this and make all systems a bit different and a bit more believable.

Troy, as a example again. In this case, if we used more planets and units, the system would have three planets.

2 minimal planets ( like our moon.. mars, etc )

1 Agricultural planet.

Minimal planets dont have anything that can be bought. But both mining bases ( hector and achilles ) would be orbiting them... kinda like as if those bases were build on small moons.

As another option, I could just wait for the new asteroids to be done and place a very sparce asteroid field around both bases.

*BIG ISSUE: If we go for fixed planets, instead of orbital ones, the whole auto system generator thingy will have to be modified to fit the change. Because I -know- it will be a long while before we have all the systens written ( I doubt we ever will actually ) and we will be using it for a long time.

The whole point between this orbital vs fixed issue is so we have some kind of standard for systems. Right now Gemini sector looks waaaay too different from everything else.

-What should be the size of a medium planet? Think about agricultural bases.. how big should they be, really?

-Can I go for some crazy scenery? I do know that placing two gas giants, with big rings, close to each other looks reaaaaaaally cool IG. But its not really realistic.. its very unrealistic.

*Please give me some feedback... I dont want to write half of sol system and have to redo it because of some change in policy.

[chuck_starchaser]

Damn good questions... Problem is, WCU includes Privateer, and we wouldn't want to change the nature of that game too much... But then again, if we might be adding a crap load of unexplored systems and hidden jumps, that's already going to change it quite a bit... Okay let me think... Troy...

I would think the mining bases would orbit Helen. This way,
a) We keep the distance between Helen and the mining bases short, as in the original, and
b) Will look more like the original system, with the star far away.

Well, you might say "only one planet?!!!". But actually, no contradiction, necessarily. For what we see so far in surveying extrasolar systems, our solar system is rather atipycal.
I wouldn't add "minimal" planets, because doing so would place them in the target queue, and that might be a hassle; --there's already enough jump-points in Troy. Maybe we could add just one gas giant, at some distance, and leave it at that?

With regards to moving versus non-moving. Klauss will probably have light to shed into this issue: The Vegastrike engine currently has this concept of "speed", as in "absolute speed", which as a concept was debunked by Relativity. And the problem is, when docking with planets or stations that are moving you are burdened with the task to "match speed" with the unit you're docking with. So, my first reaction would be to say "forget it, jus make them fixed". And there's another issue with the VS engine: You can choose between having the star reflect off the surfaces of the ship, or have the sky do so, but not both. For now, this could be got around by aligning the planets with the star, putting them all far from the star, and putting a sun on the skybox on the same spot where the star is, as seen from the planets, then choosing the sky to be reflected.
So, there you have 2 technical reasons to, at least for the time being, have the planets fixed rather than orbiting. But like I said, I think klauss will have up-to-date info on the status of these issues.

WRT gas giants close to each other: Ouch! Seriously, I know WC is not about realism but that goes too far, IMO. In fact I'd say priority numero uno with gas giants is to fix their damned rings. There should only be one set of rings (no cross rings), it should align with the texture, be far from any sizable moons, and no planets anywhere near a gas giant. Would be nice to go a step further and make sure that whenever there are asteroid fields, there's a gas giant nearby. (Not "close"; I mean, like next orbit). Asteroid belts are the result of planets that tried to form but couldn't due to the periodic tidal pressures from the gas giant.
And by the way, some of the textures for gas giants look like persian rugs on lsd. Whoever came up with them was watching too many false color pics from Nasa, thinking they were true color. Just bringing down contrast and saturation, and a bit of smoothing should fix them.

[mkruer]

I seem to recall this topic at least 2 two times in the past and both times it was agreed to keep with the static universe, mainly out of ease of implementation, and also not having to reinvent systems that exist. Personally I like the idea of static systems, it seems to fit the universe better.

[MamiyaOtaru]

I always planned on increasing the size of the gemini systems some when moving to WCU. They were kept closer to the original small size for the remake, but I don't think it's strictly necessary for a larger project.

Whether they need to be bigger can be debated, but they certainly can be as far as I'm concerned.

[mkruer]

I always planned on increasing the size of the gemini systems some when moving to WCU. They were kept closer to the original small size for the remake, but I don't think it's strictly necessary for a larger project.

Whether they need to be bigger can be debated, but they certainly can be as far as I'm concerned.

I can see where you are coming from. The nav points just feel too close. I think it has to do with the relative size off all the objects. I just seems weird to see stations from a planet, when in the original game, you would not see them. I wonder if we could implement scale all the object down a notch to make it appear further away, while still keeping the same general physics. Also maybe we should include a visual field limiter to the nearest 16000 clicks around you?

[chuck_starchaser]

Certainly, making the systems bigger would allow us for bigger planets.
One thing that bothers me is how small planets are; no bigger than a few asteroids put together. Would be nice if the rule went somewhat like, okay from top to bottom:

gas giants
agri planet
minimal
moon
large roid
mining base
carrier
capship
destroyer
frigate
shuttle
centurion
small roid

realism would require each be 1/10 the size of the previous; but if each could be at least 1/2 the size of the previous, it would at least hint in the right direction.

[mat_yarrow]

Wouldn't bigger planets and systems correspond to longer travel time, and if so, how would it affect gameplay? I suppose the autopilot could be tweaked to compensate for this, or the key bindings for time compression in vegastrike.config could be enabled.

I recall running out of jump fuel when using afterburners and the very long flight it took to dock to refuel (autopilot needs fuel).

[spiritplumber]

I would like to have semi-realistic solar systems (smallish size, as in can be navigated without autopilot if you have a decently fast ship, but with the sun in the middle). And right now space stations aren't specified in the universe file.... this needs to be fixed will do.

Or do we want priv-style systems? That will require revamping the autogen.

I'm personally OK with both, with the caveat that the AI needs to be taught to not fly into the sun if we use realistic systems


please let me know.


autopilot uses fuel? odd, i never noticed... will look at it

[klauss]

Best choice, IMO: Semi-Fixed systems, with the sun in the middle, and (as spirit said), with a size that allows one to go from planet to planet without autopilot in decent times, but still looks "big".
Now... what does Semi-Fixed mean? It means that planets do not rotate when you're in there, but when jumping in they do appear "randomly" rotated, as if they had been orbiting slowly. IMO, this is what looks most realistic, without true realism. I'm not entirely sure if that can be done with the engine as-is... but that's no problem

Revamping the autogen... perhaps it's time I start doing that... Just after I finish merging the current CVS with my source tree (I've been doing this two days straight, and still haven't finished - @spirit: you were talking about pain? you don't know jack about pain... TWO DAYS! - I had the bad idea of optimizing things all over the code... there isn't a single unchanged file - but now, the game starts in seconds... 1 minute tops... yay!)

Also maybe we should include a visual field limiter to the nearest 16000 clicks around you?

That's astonishling easy. I'll try to incorporate it in my tree, which I'll be committing as soon as it gets merged with CVS. I guess that would be sometime in the weekend, or monday. I wanted to do this today, but I couldn't get things to compile... damn I'm tired of merging...
Basically, just a tweak to LOD selection. As simple as that.

With regards to moving versus non-moving. Klauss will probably have light to shed into this issue: The Vegastrike engine currently has this concept of "speed", as in "absolute speed", which as a concept was debunked by Relativity. And the problem is, when docking with planets or stations that are moving you are burdened with the task to "match speed" with the unit you're docking with.

It's actually the lack of gravity. Has nothing to do with relativity. The speed wouldn't matter if gravity could help ships follow the planet's orbit. But it doesn't, since gravity is nonexistent right now. So, it's not speed, it's acceleration: the orbiting station is not following a straight path, and in order for you to do so, you have to use your thrusters. Normally, in real life, it wouldn't be necessary, since the gravitational pull of the star would make you orbit as well.

So, my first reaction would be to say "forget it, jus make them fixed".

Agree, mostly. See top of the post.

And there's another issue with the VS engine: You can choose between having the star reflect off the surfaces of the ship, or have the sky do so, but not both. For now, this could be got around by aligning the planets with the star, putting them all far from the star, and putting a sun on the skybox on the same spot where the star is, as seen from the planets, then choosing the sky to be reflected.

If you have anything newer than 0.4.3, try this:

in vegastrike.config

Code: Select all

...
<section name="graphics">
...
    <var name="specmap_with_reflection" value="1"/>
...

This should fix that. Of course, if that extension is to be used, models should be made with that in mind. Current models would probably look OK, but if you tweak them with that effect in mind, they could look better.

[klauss]

Best choice, IMO: Semi-Fixed systems, with the sun in the middle, and (as spirit said), with a size that allows one to go from planet to planet without autopilot in decent times, but still looks "big".
Now... what does Semi-Fixed mean? It means that planets do not rotate when you're in there, but when jumping in they do appear "randomly" rotated, as if they had been orbiting slowly. IMO, this is what looks most realistic, without true realism. I'm not entirely sure if that can be done with the engine as-is... but that's no problem

Revamping the autogen... perhaps it's time I start doing that... Just after I finish merging the current CVS with my source tree (I've been doing this two days straight, and still haven't finished - @spirit: you were talking about pain? you don't know jack about pain... TWO DAYS! - I had the bad idea of optimizing things all over the code... there isn't a single unchanged file - but now, the game starts in seconds... 1 minute tops... yay!)

Also maybe we should include a visual field limiter to the nearest 16000 clicks around you?

That's astonishling easy. I'll try to incorporate it in my tree, which I'll be committing as soon as it gets merged with CVS. I guess that would be sometime in the weekend, or monday. I wanted to do this today, but I couldn't get things to compile... damn I'm tired of merging...
Basically, just a tweak to LOD selection. As simple as that.

With regards to moving versus non-moving. Klauss will probably have light to shed into this issue: The Vegastrike engine currently has this concept of "speed", as in "absolute speed", which as a concept was debunked by Relativity. And the problem is, when docking with planets or stations that are moving you are burdened with the task to "match speed" with the unit you're docking with.

It's actually the lack of gravity. Has nothing to do with relativity. The speed wouldn't matter if gravity could help ships follow the planet's orbit. But it doesn't, since gravity is nonexistent right now. So, it's not speed, it's acceleration: the orbiting station is not following a straight path, and in order for you to do so, you have to use your thrusters. Normally, in real life, it wouldn't be necessary, since the gravitational pull of the star would make you orbit as well.

So, my first reaction would be to say "forget it, jus make them fixed".

Agree, mostly. See top of the post.

And there's another issue with the VS engine: You can choose between having the star reflect off the surfaces of the ship, or have the sky do so, but not both. For now, this could be got around by aligning the planets with the star, putting them all far from the star, and putting a sun on the skybox on the same spot where the star is, as seen from the planets, then choosing the sky to be reflected.

If you have anything newer than 0.4.3, try this:

in vegastrike.config

Code: Select all

...
<section name="graphics">
...
    <var name="specmap_with_reflection" value="1"/>
...

This should fix that. Of course, if that extension is to be used, models should be made with that in mind. Current models would probably look OK, but if you tweak them with that effect in mind, they could look better.

[chuck_starchaser]

It means that planets do not rotate when you're in there, but when jumping in they do appear "randomly" rotated, as if they had been orbiting slowly. IMO, this is what looks most realistic, without true realism. I'm not entirely sure if that can be done with the engine as-is... but that's no problem

Yeah, that's the best idea, IMO.

If you have anything newer than 0.4.3, try this:
in vegastrike.config

Code: Select all

...
<section name="graphics">
...
    <var name="specmap_with_reflection" value="1"/>
...

This should fix that. Of course, if that extension is to be used, models should be made with that in mind. Current models would probably look OK, but if you tweak them with that effect in mind, they could look better.

What does it do? And how should ships be made to take advantage of it?

[chuck_starchaser]

It means that planets do not rotate when you're in there, but when jumping in they do appear "randomly" rotated, as if they had been orbiting slowly. IMO, this is what looks most realistic, without true realism. I'm not entirely sure if that can be done with the engine as-is... but that's no problem

Yeah, that's the best idea, IMO.

If you have anything newer than 0.4.3, try this:
in vegastrike.config

Code: Select all

...
<section name="graphics">
...
    <var name="specmap_with_reflection" value="1"/>
...

This should fix that. Of course, if that extension is to be used, models should be made with that in mind. Current models would probably look OK, but if you tweak them with that effect in mind, they could look better.

What does it do? And how should ships be made to take advantage of it?

[klauss]

specmap_with_reflection makes specmaps work, even with reflection enabled. That is, you can have specmaps, and reflection. In such cases, the specmap modulates both the reflection intensity and the specmap intensity. Basically, it's a better way of doing the "paint the sun in the skybox" thing. It's the exact same result - only more accurate.

[Fireskull]

I really like the semi-fixed systems idea. Much better than doing those crazy orbits with sk rk and whatever.

I will just change sol.system to fixed planets, and then do the other systems in sol as fixed for now then? If its ok with you all.

With fixed sytems I wont do any change at all in Gemini, that was only for orbital systems. The reason being that there are some systems in gemin that just wouldnt make any sence if we had orbital planets... Troy is a good example.

Not because of having just one planet, like chuck said, but because having two mining bases orbiting the same agricultural planet would make for waaaaaay too easy cargo runs. And to have bigger orbits we would need bigger planets.. so well, everything would be just messy in Troy if we keep things as they are and change to orbital planets.

But with fixed planets the system makes sence because its a whole different view on systems.

With semi fixed planets too I guess.

important issues if we go for fixed planets ( please refrain from going off topic )

-Changing the autogen to reflect this.

Chuck:-ok, so I wont go for crazy scenary. I will keep it normal looking, though about gas giants with rings not having bodies near them.. doesnt Jupiter has veeeery thin rings?

-Planet size

When I was writing Sol I noticed that if you increased planet size 10x they would look much more realistic while not being extremelybig . The bad thing about this is that they would look 10x bigger when you were far away from them, and systems would look too small.

If we plan to increase planet size we will have to make it so the player can only see so far

-New issue: System size

( these are my views )

Quite often at New Detroit I had a dralthi/pirate ship/whatever win a dogfight near one of the jumps then go chase me near the planet. They arrive in no time.

It just feels a bit wrong that starfighters can go from one side of the system to another in a few seconds. I really dont think it would stop AI from traveling around if we increased the size of systems a bit.. plus it would fit better with bigger planets.

It would fit better with big capships too ^_^

*New issue
-More types of planets in Gemini/Get ride of all types of planets that werent in the original/Leave stuff as it is.

It just doesnt makes sence that we have minimal, ocean, gas giants, whatever planets outside of Gemini sector but nothing like that inside it.

In my opinion, for the universe to be more believable we will have to add some of these in Gemini. I really dont care a lot about copying privateer and having systems be exactly like the original. WCU is like a whole new game.

I dont think we should just leave things as they are because then we wont have a consistent universe.

I dont agree with just using the types of planets that were in the original because that would be too limited for what we have in mind.

[Wisq]

The Vegastrike engine currently has this concept of "speed", as in "absolute speed", which as a concept was debunked by Relativity. And the problem is, when docking with planets or stations that are moving you are burdened with the task to "match speed" with the unit you're docking with.

Huhwha? VS has no absolute speed; speed is always in relation to the local star. (It probably implements absolute speed internally, but it can do that, because all universes are centred around the local star.)

Of course, set speed can be in relation to anything. Hence, I can speed with a ship moving at any crazy speed and still dock easily once I'm matched, provided it doesn't suddenly change on me.

But then, the original WC games had absolute speed, "space friction", and everything completely immobile. So I'm sure you guys have a lot of creative freedom in how you handle physics and stuff, given the source material. I can only speak for VS.

[chuck_starchaser]

Chuck:-ok, so I wont go for crazy scenary. I will keep it normal looking, though about gas giants with rings not having bodies near them.. doesnt Jupiter has veeeery thin rings?

It does. That makes room for bodies closer to the planet; just don't put them *too* close to the rings, that's all I meant. I don't have figures on me, but probably you can google how far the Jovian satellites are from the rings. Again, I'm not sure there might be a moon to the inside of the rings. I do have the idea that Io is pretty damn close to Jupiter...
Actually, there are tiny moons between individual rings, in all ring systems, which is what creates gaps between the rings, in fact. The idea is to just not put a big moon right next to the rings, or else the rings could not exist.

-Planet size
When I was writing Sol I noticed that if you increased planet size 10x they would look much more realistic while not being extremelybig . The bad thing about this is that they would look 10x bigger when you were far away from them, and systems would look too small.
If we plan to increase planet size we will have to make it so the player can only see so far

Here's an idea to "optimize" viewing distance. If you are fixing the planets, then might as well place them at wide angles between themselves and the sun. I made a drawing to make it clearer:



Notice the 110 degree angles I marked between Mercury and Venus, Venus and Earth, Earth and Mars. If you place them like that, distances between planets on neighboring orbits is maximized, sort of, while remaining kind of randomish looking.

I agree on everything else in your post.

@Wisq:
Actually, that's what I meant: "Speed relative to the star", which happens to be the origin of the coordinate system. Sure, I was aware of that, but still that's "absolute" in the sense that it is irrelevant to a pilot. What you really care for, if you care to know your "speed" at all, is the speed relative to another ship, or to a base you're trying to dock with. If you're on the same orbit with a space station and stationary relative to it, I'd rather see 0 as my speed (zero); who cares what my speed relative to the local star is? And what's funnier is the "governor setting" that "limits your speed", but does so relateive to the star???!!! Who'd buy that? But then again, if I try to think of an implementation of "speed" I find a can of worms I don't want to open. I'd just get rid of the concept. Even if we were to implement "speed relative to whatever you lock", suppose you lock another ship and the two ships are flying around each other keeping a constant distance, would we call that "zero speed". BIG can of worms...

Anyhow, I may be wrong if I understand klauss right: That the problem is acceleration. Maybe things have changed. I remember having to press a key to "match speed" with a station, but that was actually the second-last time I played VS, last time I don't remember having to do that, so maybe speed IS now relative to the closest base. If so, disregard my rants. But then, if I understand klauss correctly, the implementation went half way by not matching acceleration also.

Anyhow, I would think that at least *temporarily*, either fixed or "randomized on entry otherwise fixed" is the way to go until gravitation and orbital flight paths are in the engine. I would even say that for WC style flight, where you press A and you're there, any kind of orbits and gravity and dynamics are overkill.

[spiritplumber]

Yeah... Vegastrike is Newtonian at its core, but each ship has a very complicated thrust model to fly more "armospherically". I don't know how much people will pay attention... however, hacving planets rotate would be a nice touch, I think that should stay

[chuck_starchaser]

You mean "spin in place", like day/night rotation? Yeah that couldn't possibly hurt...

[Wisq]

@Wisq:
Actually, that's what I meant: "Speed relative to the star", which happens to be the origin of the coordinate system. Sure, I was aware of that, but still that's "absolute" in the sense that it is irrelevant to a pilot.

Not really, since most objects in the system will be practically stationary (very slow-moving) relative to the star.

If you're on the same orbit with a space station and stationary relative to it, I'd rather see 0 as my speed (zero); who cares what my speed relative to the local star is?

Perhaps two speedometers, then, because (for the reason above) the local speed is really relevant. It's easy to match speed with a ship and fail to realise the ship is accelerating and taking you with it, and then (at least in VS) you spend a lot of time decelerating back to reasonable system speeds.

And what's funnier is the "governor setting" that "limits your speed", but does so relateive to the star???!!!

Not in VS. The ship can go insanely fast and I just get "tugged" along with it (by my engines).

I remember having to press a key to "match speed" with a station, but that was actually the second-last time I played VS, last time I don't remember having to do that, so maybe speed IS now relative to the closest base.

It may as well be. I've found very few situations (one, I think, possibly in Sol) where the base was moving any more than a few pixels on screen per minute relative to the local star, so I typically don't need to match speed.

Just clarifying a few points about VS, at least, since I've been playing CVS. Maybe it's different in 0.4.3, maybe WCU/Privateer does things a little differently, or maybe VS has advanced since you last played it... the actual cause doesn't matter, but I'm very well-versed in it and just felt the need to correct the misunderstanding.

[spiritplumber]

I don't know anymore. I can't even compile vegastrike now. Whatever good thing I had going, I think I lost it.

[chuck_starchaser]

Cheer up, spirit! Shait happens, and then there's another day.

Maybe it's not you, and something broke in the CVS.

[mkruer]

I was thinking of a much simpler map design for the sol system, something inline with this.

All the planets are color coded
Grey = Mercury
Bright yellow = Venus*
Green = Earth*
Red = Mars*
Brown Dots = Main Asteroid belt**
Brown = Jupiter***
Yellow = Saturn**
Light Green = Neptune
Light Blue = Uranus

Dark Blue = Jump points.

* Can Land on Planet
** Can Land Asteroid Base
*** Can Land on a Moon / Space station

This is very simplistic, and gets around having to have a star, while at the same time includes most of the planet (no Pluto, why would you want to go there anyway?)

[Fireskull]

I wont take any planets from sol. If pluto exists,it should be in game.

[chuck_starchaser]

I totally agree; I even put Sedna in my chart

[klauss]

Remember that pluto has a companion... Charon IIRC.
It's like binary stars: they're orbiting each other.

Yep. I remembered correctly: see the wiki