Idea Unified KSC / Canaveral for all addons

[Countdown84]

Hi everyone,
It seems that almost every major realistic / historical addon for Orbiter (AMSO/NASSP/Shuttle Fleet/SSU/Mercury, Gemini) installs its own version of KSC in order to be period-accurate, insert custom launchpads, etc. While this is nice, all the different versions of KSC get confusing and tend to cause conflicts / corrupt installations. They also make it difficult to install "common" upgrades like surface tiles.

Starting with the last version of Orbiter, two new parameters were introduced for surface bases that should have helped address this problem - namely PERIOD and CONTEXT. (if not familiar with how these work, check page 104 of the Orbiter manual). I propose a way to unify many of the KSC addons running around out there into a common addon that most historic vehicles can use without modification.

As far as I can tell, the most complete KSC addon to date is algol's KSC Missile Row v2, which uses many of kev33's launchpad meshes (http://orbithangar.com/searchid.php?ID=3966)
I suggest we use this addon as a starting point (with author's permission of course), and do the following:

1. modify the positions of all the meshes to line up properly with kukanotas' excellent hi-res surface tiles
2. Split the base into a small number of PERIODs representing the major eras in NASA spaceflight. For each period, only the launchpads (and possibly even the buildings) present at that time in history would be loaded in the base configuration file (others can be commented out). In Earth.cfg, these different KSC's would be invoked using the PERIOD flag so that the appropriate base would be loaded automatically based on the MJD in the scenario file. So, if you load up a Mercury launch during 1962, the 60's era base will load without needing to specify an alternate solar system in the .scn file.
3. For time periods with multiple launchpad versions (NASSP/AMSO , SSU/Shuttle Fleet / Stock Atlantis) the CONTEXT parameter would be used to define variants. It would be up to the respective addon developers to include the corresponding CONTEXT flag in scenarios for their addons. Likewise, if addon developers want to develop their own launchpad, but not include it in the standard Unified KSC package, it would be up to them to conform to the configuration file structure and add their own variant of the base without disturbing others.

It seems like with relatively little work, building on some great addons that already exist, we could have a common KSC addon that automatically adjusts for different times and different vessels, and not have to worry about files getting overwritten, etc. etc.

I'm willing to put in the time to make this happen, but I would need some guidance on the easiest way to relocate all the base meshes relative to kukanotas' surface tiles. It doesn't appear that SurfaceBaseWizard allows you to load tiles as a background.

What are your thoughts? Would this be worthwhile?

 

[Star Voyager]

I totally agree! I am a fan of this addon and would like to see this go far.

 

[4throck]

Yes, It's a good idea, not only for KSC but also for other major spaceports.
And for other planets it would make sense to have something of that sort. For example, if you went to the Moon today, there should be leftover Apollo hardware, but if you went before 1969 you shouldn't see it.

 

[fort]

Of course. It should also not neglect to take into account AutoFcs (AFCS)

 

[Urwumpe]

Actually, you want a Earth.cfg...The last time I looked at it, SSU already used the context parameter.

I would suggest making the context-free KSC base versions the historic and low quality versions of the base, and leave hi-res and alternative history features to different contexts.

IMPORTANT: Make sure the name for each KSC base configuration file is the same. If you have Caneveral.cfg and KSC.cfg, orbiter will load both files at the same place, if you have overlapping folders.

 

[fort]

Of course it would be possible to work with SurfTileCalculator, among others.

The problem is that it is failing, according ar81, for its annex function, intended to put an item with POS on a tile.

I have an idea about that problem but ar81 seems absent for the moment.

In addition, the height value for a tile ( and the width ) in the main window seems to me wrong (and can be there all starts here).

Maybe, in that case, for the height :
6371010 * sin (0.703125/2) * 2 = 78183.56... meters.

For the width ( for which interested me : at the half of the height ) :

0.703125 * cos 0.3515625 = 0.70311176
6371010 * sin (0.70311176/2) * 2 = 78182.09... meters and some dust.

But once adjusted, if necessary, this tool could be usefull.

 

[Saturn V]

After doing a little of the recommended research, it looks to me to just be a round-about route to the same result. You're not reducing the number of meshes in a given installation. You're only specifying which ones are called up by Orbiter for a given scenario...which is exactly what the Sol configurations do. If the Sol configurations are set up properly, there is no conflict between addons.

And I agree that if an add-on is intended to use the hi-res KSC tiles, the pads should be placed in the correct position by the add-on's builder (which I do). But you should also bear in mind that not everyone uses kukanotas' tiles.

To further complicate matters, it seems you're aiming for one LARGE base file with only certain sectors being called up by a scenario. What happens when a developer needs to modify or create a launch pad that's not already in that base file? The developer now has to contend with a cumbersome set of meshes or configuration files. And we'd better hope that the developer really knows what they're doing because if they don't, they won't be crashing one Sol system, they'll be destroying your nice big base file...which means none of your other add-ons will work either. Then you're right back to what you're trying to do away with...modifying files.

I think the current system keeps things small enough to be managable. If a Sol system doesn't work for you, all you have to do is remove it. Far simpler than having to repair one massive file that everything is depedent on.

Just my 2 cents...

 

[Urwumpe]

I think the current system keeps things small enough to be managable. If a Sol system doesn't work for you, all you have to do is remove it. Far simpler than having to repair one massive file that everything is depedent on.

I agree. The danger is there. But on the other hand, it is easier to manage add-ons, if there would be at least one or two standard solar systems, one with standard tiles and one using highres tiles, which each have a standard set of time periods defined.

 

[Saturn V]

I agree. The danger is there. But on the other hand, it is easier to manage add-ons, if there would be at least one or two standard solar systems, one with standard tiles and one using highres tiles, which each have a standard set of time periods defined.

In theory, I can agree with you. But you're assuming that all add-ons are assembled correctly before they're distributed. You know as well as I do that's not the case. A well intentioned beginer could unintentionally destroy an otherwise functional system due to their inexperience.

Could it be repaired? Certainly...if the user is experienced enough to correct/modify the offending files. My point is that isolating the problem and effecting the repair could become unecessarily complex.

And God help those who can NOT make repairs themselves. They're left with the option of completely starting over or flooding the forum with "HELP ME" posts.

Given the learning curve of Orbiter (nevermind making add-ons or modifications which is a whole different realm) I think it's something to seriously consider before jumping on the bandwagon.

 

[Countdown84]

Thanks for all the thoughts, folks! Let me offer some responses:

To further complicate matters, it seems you're aiming for one LARGE base file with only certain sectors being called up by a scenario. What happens when a developer needs to modify or create a launch pad that's not already in that base file? The developer now has to contend with a cumbersome set of meshes or configuration files. And we'd better hope that the developer really knows what they're doing because if they don't, they won't be crashing one Sol system, they'll be destroying your nice big base file...which means none of your other add-ons will work either. Then you're right back to what you're trying to do away with...modifying files.

The way I understand it, you would still have to have a bunch of separate .cfg files (one for each PERIOD and CONTEXT), so that if a developer did screw one of them up, it (theoretically) should only crash that particular PERIOD/CONTEXT. Ideally, it would be understood that any new launchpads should be placed in new versions of the base (add a new CONTEXT), not the original files. The aim of this idea is to give addon developers a common framework for doing this so that we don't end up with overlapping solar systems, KSC/Canaveral .cfgs etc. etc.

The second objective is to make all the different PERIODS/CONTEXTS consistent with each other (e.g. they all originate from the same master set of meshes/positions). That way, you don't get one set of surface tiles in 1962 and another in 2000, or end up with two versions of the VAB or something.

What I DON'T want to do is add another variant to the confusing mess of KSC addons already in existence. I think this is only worth doing if it can supercede the others and become "THE" Canaveral addon.

EDIT: I retract that statement; poor wording. What I mean is that I want this addon to integrate, rather than compete with, as many of the other addons that already exist as possible.

 

[Saturn V]

That way, you don't get one set of surface tiles in 1962 and another in 2000, or end up with two versions of the VAB or something.

There are circumstances where that is exactly what you want. I have a version of Missle Row which I created (not based on algol's which doesn't work for me and see no point in reconfiguring since I have one that I prefer anyway) set in the 1961-1966 period which shows the VAB under construction. Then there's the Apollo era VAB and yet another for the Shuttle era which differs significantly from the other two. Eliminating all but one VAB mesh would be grossly limiting. Certainly you don't want them all showing up in the same scenario, but as I said earlier, if you're paying attention to what you're doing in the first place, it isn't an issue under the current arrangement either.

And I am most definitely NOT in favor of one new "Super KSC" superceding all others. There are far too many variations in the appearance and operation of KSC over the past 50 years to be served by one (exceedingly limiting and constricted) environment.

 

[Urwumpe]

In theory, I can agree with you. But you're assuming that all add-ons are assembled correctly before they're distributed. You know as well as I do that's not the case. A well intentioned beginer could unintentionally destroy an otherwise functional system due to their inexperience.

In praxis, nobody has to edit anything and break stuff that way, if the folders are already defined and the add-ons are just thrown into folders created for the standard periods. What could cause trouble then, is a faulty file in one or more folders, which could be deleted easily. Not really as hard as plotting a free return trajectory around the moon.

 

[Saturn V]

In praxis, nobody has to edit anything and break stuff that way, if the folders are already defined and the add-ons are just thrown into folders created for the standard periods. What could cause trouble then, is a faulty file in one or more folders, which could be deleted easily. Not really as hard as plotting a free return trajectory around the moon.

Where it concerns guys like you and I who've been around here for years, yes, that's quite true. I'm thinking of the younger/newer guys who might find this proposal simpler at the outset but running into problems later with poorly made add-ons that affect their installation as a whole.

Developers will remain free to develop as they see fit of course, and whether to configure them for the proposed KSC or not. And it would still be up to the end user to modify the configuration files to add or remove them as they see fit. So in effect, nothing's really changing, is it?

I just don't see this proposal as being a solution, just a different route to the same destination.

Now if you're talking about a project that's ancillary to the current system (users who want to take existing and new add-ons and incorporate them into the new KSC and periodically distibute it for the folks who want to use it), that's not a bad idea. But doing away with the current arrangement altogether in favor of this one is forcing one's will on everyone else...which is NOT a good thing.

 

[Countdown84]

There are circumstances where that is exactly what you want. I have a version of Missle Row which I created (not based on algol's which doesn't work for me and see no point in reconfiguring since I have one that I prefer anyway) set in the 1961-1966 period which shows the VAB under construction. Then there's the Apollo era VAB and yet another for the Shuttle era which differs significantly from the other two. Eliminating all but one VAB mesh would be grossly limiting.

I agree completely. What I meant was having two VAB's show up in the same scenario because of multiple KSC / Canaveral bases overlapping one another (I've had that happen several times). Sorry I didn't make that more clear.

I think the sort of structure that I'm suggesting actually lends itself perfectly to defining different meshes for different eras. (Just call an "under construction" VAB in the appropriate PERIOD config file, and the completed one in the other version).

And maybe this idea could be what Urwumpe suggests - more of a common structure or format for KSC addons than a single, all-inclusive base. But if everyone could get on the same page about HOW they implement custom Canaveral configurations for their addons we'd have a lot less confusion and many fewer conflicts I think.

 

[Saturn V]

I agree completely. What I meant was having two VAB's show up in the same scenario because of multiple KSC / Canaveral bases overlapping one another (I've had that happen several times). Sorry I didn't make that more clear.

I understood what you were getting at. I reiterate...

Certainly you don't want them all showing up in the same scenario, but as I said earlier, if you're paying attention to what you're doing in the first place, it isn't an issue under the current arrangement either.

Again, just not in favor of one version of KSC replacing all others. I'm 100% in favor of what you propose for the folks who want to use it. Eliminating the choice is what I take exception to.

 

[Countdown84]

I understood what you were getting at. I reiterate...

Again, just not in favor of one version of KSC replacing all others. I'm 100% in favor of what you propose for the folks who want to use it. Eliminating the choice is what I take exception to.

That's fair. I thought that the choice issue went without saying, since of course there's no way to force users to choose any particular addon. I just think a project of this sort might make it easier for novice users to navigate the complex maze of KSC addons.

I don't see this as one version, merely one configuration structure that facilitates managing multiple versions without conflict. It would be an addon package that integrates many of the surface tiles, meshes, and improved launch facilities available already and integrates them into a coherent Canaveral addon. Different meshes and tiles could be loaded in each of several bases (each of these would have its own separate config file):

"Standard" - no changes from stock Orbiter
Pre-apollo era - VAB under construction, surface tiles (optional), Mercury and Gemini era launch pads
Apollo era - apollo VAB, Apollo launchpads
CONTEXT AMSO or NASSP variants would incorporate those launchpads
Shuttle era - all modern buildings and pads. Contains default LC-39
CONTEXT SSU or STS variants would call launchpads for Shuttle Fleet or SSU. Others could be added (e.g. for kev33's LC-39)

Past that, the CONTEXT parameter could be used to define pretty much any other base one wanted. It would only be loaded when called from the scenario and would not interfere with the other bases. The advantage is that there would be no need to modify solar systems, only base and scenario files.

It seems to me a user could install such an addon and still have plenty of choice with respect to modifications or additions to it. Am I wrong?

I appreciate all your thoughtful comments, SaturnV, just want to make sure I understand you completely.

 

[Saturn V]

Yes, that's pretty much the gist of it.

For example, the current projects I'm working on concern the Mercry & Gemini launch complexes. They are distributed with a Sol system named Sol_MG. I do this primarily because not all users are running PCs powerful enough to run a massive installation (like the Missle Row I use), and also to confine the search area in the event of a problem.

I am not against the idea of these launch pads being incorporated into the system you're proposing if the user wishes to do so.

But speaking as developer, I would resent having to confine what I do to conform to someone else's idea of the perfect KSC. Do you follow?

Your edited statement regarding integration of existing (or new) launch complexes as opposed to replacing other KSC variants is precisely what I would be in favor of, and there are certainly enough of us doing something much like that for our own use.

I just believe that the KSC/Sol variants should remain an option for those users who aren't running top of the line PCs or those of us who also run smaller installations on our laptops.