IMPORTANT!

[spiritplumber]

Does anyone have time to talk this weekend about what needs to be done and so on? Thanks. IRC or YM work for me.

[chuck_starchaser]

I'm working this weekend, but I'd just like to reiterate what I mentioned about ships realistically maneuvering and parking or leaving space stations --would add a lot of spice. Even better if they followed trading routes (for merchant ships, or patrolling or harrassing routes for militias or retros). Who hasn't followed a ship in PR or VS to find out where it was going, at least once? Would be nice to be able to follow a ship through jumps and find out its trade route, then land on the planet and analyze prices to see why it chose that trading route. This would add a lot of realism and be good for VS and most mods.

Another feature that could benefit VS and PR/WCU in particular is a master-slave addon device one can buy for the ship. In escort missions, the escorted ship's pilot would press a button while locking you that would put the ship in slave mode. Whenever you accelerate, auto or jump, it would be as if you press those keys on both ships. In VS this should include SPEC engine synchronization. Particularly once we have multiplayer, if a group of players get together to run a long distance cargo mission as a convoy, they'd agree on one leader, and all would place their ships in slave mode, so as to SPEC and jump together.

[chuck_starchaser]

See?

[spiritplumber]

Meow, that's hard to do... I'd have to play with the vs.exe source code, which I will do as soon as I have hellcatv's blessing.

[chuck_starchaser]

I'll make you a deal. I'm good at C++, but I suck trying to understand the engine, with all the intricacies of xml and python and all that. But if you tell me "Okay, in file x.cpp, I believe function x() does x, but should do y", I'll do that for you in less time it takes you to post it. I have cvs commit, and never used it, BTW.

[spiritplumber]

meow, thanks!

[klauss]

@spirit: I can hack the exe. I've been doing so for quite a while. Just tell me what you need.

@chuck: Also, if you want to, and don't understand a piece of code, chances are that I've already deciphered it. Mail me, and perhaps I can help.

[spiritplumber]

Awesome! What would be nice to have in the exe is:

(0) More AI control, there are some predefined behaviors in the exe such as "loop around" and so on, i would like these behaviors also:

"fly straight with guns off" (used for carrier takeoff)

"match velocity with object and full stop otherwise" (used to tractor in cargo)

"shoot missile now, whatever you are aiming at" (used for carriers)
"shoot gun salvo now, whatever you are aiming at" (used for carriers)



also, an AI behavior table for non-hostile targets, to be used when there aren't any hostiles around (landing on bases, for example).

(1) More control for the system autogen, especially place a dummy planet in wcuniverse.xml (as in, the planet isn't actually generated but exists for trade route purposes -- this is used for space stations).


(2) A way for planets to have subunits (satellites and moons).


(3) A way to call video files, for cutscenes. (I know I'm asking a lot here...)

[klauss]

"shoot missile now, whatever you are aiming at" (used for carriers)
"shoot gun salvo now, whatever you are aiming at" (used for carriers)

More than AI modes, I think they would be direct orders, like:

ship.FireMissile(which)
or
sihp.FireGun(which)

Or did I get it wrong?

More control for the system autogen, especially place a dummy planet in wcuniverse.xml (as in, the planet isn't actually generated but exists for trade route purposes -- this is used for space stations).

More control for autogen was something I wanted to add for some time, but it never got any priority. But I'm not sure I get the idea: would you care to explain it a little more in depth, please?

A way for planets to have subunits (satellites and moons).

Hm... I'm not sure, but that should be possible already, except for the wcuniverse.xml and *.system limitations. I'll take a look.

A way to call video files, for cutscenes. (I know I'm asking a lot here...)

Hehehe... Got you there... I already did that for Priv 1.1's intro. Take a look at how it's done. It's a simple .spr file which adds the "video" keyword to the animation. It's specified just as an .ani, a series of .png, .jpg or .bmp files. If what you want is a real video file (like an MPEG file), then that's another thing. Not THAT difficult, though, since the current framework would be able to handle that, I think, quite easily, provided we get a library for decoding video files. If you mean inflight cuscenes, I'm sure there's a hack for that without code changes. But it could be useful to be able to do that legally, no hack. I'll take a look at all the options, but please clarify which one you were talking about.

Ok, enough for today.

[chuck_starchaser]

I'll write some pseudocode for planet system autogen tonight. I got this table of already catalogued extrasolar planets, to draw statistics from and approximate. Rocky planets and moons are not included, but I have a pretty good idea where and how to add them.

[chuck_starchaser]

Work in progress...

Code: Select all

void gen_system(int seed, int years_since_discovery)
{
    rand_seed(seed);
    enum material {gas, rock, ice};
    struct planet
    {
        double   dist_AU;
        double   mass_Mj;
        bool     exists;
        material mat;
        double   atmo_pressure;
        bool     has_liquid;
        double   liquid_fraction;
        bool     has_water;
        double   spin;
        double   volcanism;
        double   cratering;
        double   erosion;
        planet()
        : dist_AU(0.0)
        , mass_Mj(0.0)
        , exists(true)
        , material(gas)
        , atmo_pressure(0.0)
        , has_liquid(false)
        , liquid_fraction(0.0)
        , has_water(false)
        , spin(0.0)
        , volcanism(0.0)
        , cratering(0.0)
        , erosion(0.0)
        {}
    };
    std::vector<planet> gas_giants;
    std::vector<planet> rockytypes;
    std::vector<planet> icy_types;
    std::vector<planet> all;
    //FIRST WE DEAL WITH GAS GIANTS, AND LATER WE'LL CHECK
    //IF ROCKY AND ICY PLANETS FIT, AND IF SO WHERE...
    //first_gas_giant.distance = k1 * pow( k2, rand() )
    //where rand() returns a number between 0.0 and 0.9999
    //When rand() is 1, result should be about 7 AU's
    //When rand() is 0, result should be about 0.07 AU's
    //So, k2 should be 100; and therefore k1 should be 0.07
    gas_giants[0].dist_AU = 0.07 * pow( 100.0, rand() );
    //mass varies between 0.11 and 11 jupiter masses, so..
    gas_giants[0].mass_Mj = 0.11 * pow( 100.0, rand() );
    //The rules for second and third gas giants are a bit
    //complex. There are cases of two gas giants with close
    //orbits, but that's usually when the orbits are very
    //non-co-planar. I'd rather not have to specify orbital
    //inclination, so I'll just shove such cases under the rug.
    //What I will do is compute new gas giants at random and
    //then decide whether they can stay or must go.
    gas_giants[1].dist_AU = 0.07 * pow( 100.0, rand() );
    gas_giants[1].mass_Mj = 0.17 * pow( 100.0, rand() );
    gas_giants[2].dist_AU = 0.07 * pow( 100.0, rand() );
    gas_giants[2].mass_Mj = 0.04 * pow( 100.0, rand() );
    //For second gas giant, distance must be at least twice that
    //of the first gas giant, and its mass...
    if( gas_giants[1].dist_AU < gas_giants[0].dist_AU * 1.8 )
    {
        gas_giants[1].exists = false;
        gas_giants[2].exists = false;
    }
    else
    {
     //...its mass test must pass also. The ratio of mass to the
     //first gas giant must be at least 1/distance-ratio. It does
     //not matter whether it's bigger or smaller, as long as it
     //not be too similar while also being too close...
     double dist_ratio;
     dist_ratio = gas_giants[1].dist_AU/gas_giants[0].dist_AU;
     double mass_ratio;
     mass_ratio = gas_giants[1].mass_Mj/gas_giants[0].mass_Mj;
     if( mass_ratio < 1.0f ) mass_ratio = 1.0f / mass_ratio;
     //okay, at a distance ratio of 3 or greater, masses can be
     //the same, but as the distance ratio decreases to 2,
     //masses must be different by at least a factor of 2; so,
     //min mass factor = 1 + (3-distance-ratio), or 4-distance ratio
     if( mass_ratio < 4.0 - dist_ratio )
     {
         gas_giants[1].exists = false;
         gas_giants[2].exists = false;
     }
     else
     {
      //Same rules are applied to a third gas giant. Note that the
      //probabilities of a 2nd, not to speak of a 3rd gas giant, are
      //pretty low. Well, this agrees with current data, for one, and
      //increases our probabilities of finding rocky planets ;-)
      if( gas_giants[2].dist_AU < gas_giants[1].dist_AU * 1.8 )
          gas_giants[2].exists = false;
      else
      {
       dist_ratio = gas_giants[2].dist_AU/gas_giants[1].dist_AU;
       mass_ratio = gas_giants[2].mass_Mj/gas_giants[1].mass_Mj;
       if( mass_ratio < 1.0f ) mass_ratio = 1.0f / mass_ratio;
       if( mass_ratio < 4.0 - dist_ratio )
           gas_giants[2].exists = false;
      }
     }
    }
    //NOW WE CREATE ALL THE ROCKY AND ICY PLANETS AT ONCE, THEN WE'LL
    //CHECK WHETHER THEY EXIST OR NOT... ;-)
    for( int i = 0; i < 7; ++i )
    {
        //between 0.2 and 2 AU's we have rocky planets; and between
        //2 AU's and 20 AU's we have icies...
        //mass for rockies between 0.04 and 4 Earths mass. Now, Jupiter
        //is 318 earhs mass, so, in Jupiters, that's from 0.0001 to 0.01
        rockytypes[i].dist_AU = 0.2 * pow( 10.0, rand() );
        rockytypes[i].mass_Mj = 0.0001 * pow( 100.0, rand() );
        icy_types[i].dist_AU = 2.0 * pow( 10.0, rand() );
        icy_types[i].mass_Mj = 0.00001 * pow( 100.0, rand() );
    }
    //sort the planets by distance to sun
    //compute planet-closeness by force of attraction at nearest point
    //divided by attraction by the star. If closeness is greater than 1%
    //we say the smaller planet at some point impacts the larger one.
    //and if their mass ratio is less than 3:1, then both cease to exist and
    //become an asteroid belt. Also planets too close to a gas giant are
    //prevented from forming and so they never become anything but
    //an asteroid belt.
    //planets too close to asteroid belts are cratered and lifeless
    //planets with greater than 0.5 earths' mass have atmospheres
    //planets with atmospheres in the habitable zone have liquid water
    //...
}

[klauss]

Hm...
Complex... and rigid...

I'm not sure how to include such code in a configurable way.

Perhaps with an "EnforceBelievability" setting, and lots of tweak variables like "EnforceBelievability::MaxMassToDistanceRatio" or something like that.

Let me think about it. If you want to keep enhancing the ruleset, by all means, do so. I won't use it for a while (until I have things figured out).

[spiritplumber]

Wow that's serious...


Which brings me to the "realistic vs. early WC style" debate. Realistic WILL need some sort of space or time compression, however my impression in Vega Strike is that it slows the game down immensely.

A possible solution: Keep the ship in SPEC all the time (but with shields and guns working), so that it's slowed down by other objects.

[spiritplumber]

Wow that's serious...


Which brings me to the "realistic vs. early WC style" debate. Realistic WILL need some sort of space or time compression, however my impression in Vega Strike is that it slows the game down immensely.

A possible solution: Keep the ship in SPEC all the time (but with shields and guns working), so that it's slowed down by other objects.

[chuck_starchaser]

Well, like I said, it's preliminary work; I don't have a clear picture of what I'm going to end up with, so I'm "thinking with the keyboard" and waiting to see where it leads, for now.
Probably it would need post-processing to accomodate engine constraints, such as passing final distances through a root 1.5 or something. But I want to get something somewhat realistic from first principles first. My hope is that even if it has to stay as a lot of boilerplate code, that at least it achieves good results, propagating and multiplying uniqueness to the point that you get systems you actually remember, because they are different from any other system in more than one way. I want to work out even economic and social consequences of the planet types, weather, resources, tectonics and accessibility.

[mkruer]

Hm...
Complex... and rigid...

I'm not sure how to include such code in a configurable way.

Perhaps with an "EnforceBelievability" setting, and lots of tweak variables like "EnforceBelievability::MaxMassToDistanceRatio" or something like that.

Let me think about it. If you want to keep enhancing the ruleset, by all means, do so. I won't use it for a while (until I have things figured out).

I have though about this to some extent. The easiest way will probably be to scale the distances back some 100,000% and scale the planets down 1000%

I will argue that WC should be kept unrealistic as to maintain its original appeal. Bay adding to the realism factor, you are actually hurting the original game more then helping it.

[chuck_starchaser]

I wasn't thinking of WC, mostly Rylix and VS; I'm not sure how this discussion ended up here. Actually I did think about sytem gen in the context of spiritplumber asking for help on it, now I remember.
Yeah, what I thought was this: Might as well generate something realistic along many dimensions, and only afterwards, scale things down to fit game playability and technical constraints. If it takes taking the square root of the distances, and sizes, so be it; but at least there will be a semblance of realism. Right now there isn't any: Planets are sometimes sitting there next to each other, moons are too far away, non-gas-giants have rings, gas giants have two sets of rings crossing each other sometimes... It's totally absurd.

[smbarbour]

On that same note, shouldn't rings be treated like asteroid fields? The rings around planets are usually made up of large chunks of ice.

[chuck_starchaser]

Glad you mention... Those should be the *only* "asteroid fields", as in the asteroid belts you'd probably fly for weeks before you see an asteroid...

[mkruer]

Personally I like WC with the very simplistic, and static view of all the NAV points and what not. It makes it immensely easier to navigate, and IMNSHO adds to the over all feel to the game. For me WC should keep the KISS methodology. Right now I think that the NAV system is too complicated and should stick to only 2d. For that I would recommend all systems should be hand coded, hell there’s only 814 systems. I was working on a RAD tool to allow for easy development, but I bloated it by adding too much, such as ships, going into the NAV points and adding system histories where the system characteristics would change over time to mention a few. The only singular part of the of the DB that is completed is the location, and names along with all the connection (all of which is accurate) If you have MS Access I can sent you over the DB and you can rip the information you need from it.

VS is slightly different. The way I have always view VS is more of a more complex version of WC, adding all the “otherâ€

[spiritplumber]

I vote for simplistic (Priv style) too -- WC is WW2 in space after all.

[chuck_starchaser]

Okay, tell me where the system generation code is, and I'll fix just the grossest blunders but keep it simple; --priv-style.

[spiritplumber]

I wish I knew.... what I did for WCU (mostly to keep the distances similar to what is found in the Gemini systems) was mess around with vegastrike.config and wcuniverse.xml some.

[chuck_starchaser]

I see, so the only generator we have is the Vegastrike one, and we need one that places planets at fixed locations, like Priveteer, huh? I think I'd rather write this from scratch. So I suppose this should produce xml output? What's the input to it? It needs to know what systems to connect to, no?
Okay, I think I could start with a function that generates one system based on x many jumps needed to locations such and so, so the function will look like,

Code: Select all

void gen_system
(
    std::string system_name,
    std::string quadrant_name,
    std::vector<std::string> jumps
)
{
    ....
}

And I suppose this needs to append to or modify existing files to get the jump networks to agreee?
Anhow, I can start writing some code even before I know all the details.

[spiritplumber]

The input should be /universe/wcuniverse.xml (which contains an accurate depiction of the Big Prophecy Map) and the output should be .system files as seen in /sectors/Gemini ideally. wcuniverse.xml contains an accurate jump network, but the other details are admittedly random.

If you can generate the appropriate .system files, then we can edit the mission-relevant ones by hand (put a superbase in Ella, put a lot of asteroids in Rostov and so on).

I have half a mind of trying to write that myself but school is keepign me busy ^^,