Orbiter-Forum  

Go Back   Orbiter-Forum > Blogs > jedidia
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Rate this Entry

Trying something different

Posted 10-26-2010 at 08:30 AM by jedidia

Of course, everything is not as easy as I thought it would be, beginning with the purely mathematical problems described in my last post, and now continuing with problems in the implementation: It turns out that my whole calculation assuming a legion of spherical cows suffers a problem not uncommon for overly generalised solutions, which is insufficient accuracy. Although the formulae seem to work more or less well, the error margins for a burn timing are terrifyingly small when racing around at even less than half the speed of light. Give a day or take a day, and you'll end up either just falling towards the star for a final aproach, or you'll be overshooting a loooong way.

To really calculate the whole thing in advance and throw the player right into the middle of an injection burn when the systems are switched would require something akin to a small navigational program, which is simply outside my skills and outside my priority scope. So, the player will have to rely on other tools to get the insertion right, like TransX or IMFD. Both do not offer an option to make an orbit insert around a STAR, however, but it all seems to work more or less nicely if you target a planet right away and search for the most efficient way to reach it from your aproach at ludicrous speeds.

It all works exceptionally well with the Orbiter Navigator, by the way, which alas is still in beta state and currently has a serious cough, but MindBlast will get there.

This all implies that a player has to have full control of his aproach, so he has to be positioned in a place somewhere close to the beginning. Which will be closer or further from the star depending on how fast he can/wants to travel. For the purpouse of calculating an apropriate point in time for that with a reasonable safety margin my few spherical cows are comfortably accurate enough.

All this brings some changes to the way you can travel from one star system to another. While it is no big deal to skip the drifting time, skiping and aproximating parts of the burn times is highly unpractical for above reasons. Therefore, the player will have to do the complete burns within Orbiter. A distance limit can still be set after which a switch occurs IF the burn is finished.
In the case of a ship like the Venture Star, this means about 5 years total burntime which have to be conducted in game. There might be ship configurations where this can maybe rise to 10 years, but let's face it: Any ship that can burn away for longer than that is about as probable to come about as a ship with warp drive, so you might as well use one of those (and they work very nice with orbiter galaxy). And for anything below that time I can argue that I have made trips in "vanilla" Orbiter that have taken just as long, so I don't see a need to go back to school and spend a few years brushing up on my math so I could write a calculation to save players an hour of in-game time and rob them of the hands-on experience that will provided without such a proactive switching function.

Because, the more I think about it, this actually seems to be the more fun solution: Players will have a lot more freedom how to do their journey, and stacks are back in the game. There will be an option to calculate the duration of the acceleration burn so you can still slow down on the same tank, or you can spend it all (with you being responsible to carry enough fuel in another ship to slow you down again, of course). Or they can go all generation ship and drift along at 0.1c and get there in a few hundred years. They'll probably even be faster in real world time than those burning all the way, because they'll be burning only a short period and can skip the drifting time.

The actual time skip will also look a bit different than I imagined at first. Instead of calculating a simplified solution and write a new date to the scenario file, I'll just use Orbiter to propagate the whole time forward until halfway at the other system, write everything into the new scenario file, reload and then propagate the time forward to a point maybe a month before the injection burn has to start. A plain, elegant, and above all much more precise solution than I could ever conjure up on my own!

Additionally, there's word from Artlav: A new version of the texture generator will be available for this release, although he's not sure how sophisticated it will be. It will certainly be a lot faster than the old one, but he's not certain yet how nice the textures will be. It'll be be nice enough for an Alpha in any case says I, plus let's not forgett that the developers of custom systems (of which I see quite a lot around here compared to "the olden days") already can count on full support to plug their systems into the generator, so if they do their part I don't think anyone will get bored too fast by not yet optimal procedural textures...
Views 3396 Comments 1
« Prev     Main     Next »
Total Comments 1

Comments

  1. Old Comment
    IgnoreThisBarrel's Avatar
    Hark! A new procedural texture generator, I hear?

    Thank Probe and the Holy Tuesday! I only have a few days left on my Lunarcell free trial.
    Posted 10-28-2010 at 02:45 AM by IgnoreThisBarrel IgnoreThisBarrel is offline
 

All times are GMT. The time now is 06:48 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.