General Question Clickable Shuttle VC cockpit?

[Longjap]

Is there a way to click the buttons in the Shuttle Fleet cockpit? The only switches that seem to work with me are the MFD ON buttons. Most of the others are low res but some panels are high res and i've seen a video of someone using those switches. Are those programmed to work? If they are, they don't work with me. Can't find it in the manuals or in the forum.

 

[diogom]

I'm not sure if the Shuttle Fleet has them, but try on the aft, on the panel that controls the payload bay doors.

 

[Longjap]

Those too don't work. But they look so tempting! Feel like a kid in the a candy store without the money to buy.

 

[diogom]

I know that feeling :lol:. You should try igel's Vostok addon. It gives you the money for the candy. :thumbup:
Then it's the default Shuttle that has the clickable switches in the aft.

 

[PhantomCruiser]

The G42-200 that Moach is putting together has a really good VC, and he is still working on making it better! http://www.moachcraft.xpg.com.br/G422-WIP/G42-200-WIP2.zip

To get the skinny, read the whole development thread here... http://www.orbiter-forum.com/showthread.php?t=21197

This promises to make it to the "must-have" list of Orbiter add-ons.

 

[Longjap]

Thanks for the suggestions. I'll surely give those a spin!

 

[Donamy]

If you want to have operable switches in a shuttle cockpit, you need to get SSU.

 

[PhantomCruiser]

SSU=Awesome...

 

[Urwumpe]

SSU is currently a bit hard to "acquire", since there is only one old release of the add-on. You need to checkout a development snapshot and compile your own modules or get a module pack with already compiled modules (or ask somebody for the modules who has them). But it is definitely worth the effort.

 

[Longjap]

Indeed, can't find it in the hangar.. Even the link in the must-have-addons-thread is dead.. So if I understand you correctly it is for orb 2006 and need modules to make it work in 2010? It's becoming mythical now. Ehm.. does someone know how I do "acquire" SSU?:shifty:

 

[Urwumpe]

Indeed, can't find it in the hangar.. Even the link in the must-have-addons-thread is dead.. So if I understand you correctly it is for orb 2006 and need modules to make it work in 2010? It's becoming mythical now. Ehm.. does someone know how I do "acquire" SSU?:shifty:

The official way? Get a Subversion/SVN client and get the source files (game data and source code) directly from Sourceforge. And then compile it by using a microsoft C++ compiler.

The alternative is getting the game data from subversion again, and installing a pack with compiled modules on your PC to not having to compile the modules yourself.

http://sourceforge.net/projects/shuttleultra/

You have to understand that the project is one big huge construction site. We try to publish halfway reliable versions from time to time, but it is still not finished. But despite not being finished, it is already pretty distinctive compared to other Shuttle simulations.

 

[Longjap]

First thanks for sharing that link, but sorry, I have absolutely no knowledge of computercodes, programming and that sort of stuff. So the alternative way suits me best I guess. But I'm actually quite good at reading readme's. And following them.

Is that link with the .dll's the pack of compiled modules? Or is it the game data?

Edit: This sounds like a stupid question, even to me..
My question is actually; can I just put them in my directory or am I then missing some steps?

 

[Urwumpe]

Is that link with the .dll's the pack of compiled modules? Or is it the game data?

Only modules. Gamedata has to be acquired via SVN, there is no better way. I use TortoiseSVN, that is pretty easy to use and doesn't require you to dive into command line codes.

http://tortoisesvn.tigris.org/

We had the installation instructions on the old wiki, I just see that it is lost with the new wiki, I currently work on getting this all organized.

Essentially, you have to work like that:

1. Make an empty folder, for example "OrbiterSSU"
2. Check out the gamedata and sources from SVN into this folder, use this URL for the checkout for getting the most recent data: https://shuttleultra.svn.sourceforge.net/svnroot/shuttleultra/trunk
3. Install Orbiter 2010 into this folder
4. Install the modules pack and pray that it works... it could be a bit outdated already.
5. If it does not work - report the bugs to us of the SSU team, so we can fix it or give you more recent modules with the already fixed bug.

 

[Cras]

http://www.space-shuttle-mission.com/

About as complete a Space Shuttle as you will ever see.

But I am still looking forward to SSU.

 

[Urwumpe]

http://www.space-shuttle-mission.com/

About as complete a Space Shuttle as you will ever see.

Yeah, but it is just a "Space Shuttle Switch" simulator, which is the difference to SSU.

 

[Longjap]

I prayed, and the Probe answered my prayers!! Thanks for your time! It looks really great Urwumpe. I wish I could be useful to help you with this project. Now it's time to get this baby started. Pfew..

Do you have a thread with the bug reports and/or development of the SSU?

 

[Urwumpe]

I prayed, and the Probe answered my prayers!! Thanks for your time! It looks really great Urwumpe. I wish I could be useful to help you with this project. Now it's time to get this baby started. Pfew..

We can really use any help we can get there, and if it is just somebody volunteering to manage his own favorite Space Shuttle Missions and keep them running on the latest version of SSU.

Do you have a thread with the bug reports and/or development of the SSU?

We have a dedicated forum here, that you can use.

http://orbiter-forum.com/forumdisplay.php?f=55

 

[Cras]

Yeah, but it is just a "Space Shuttle Switch" simulator, which is the difference to SSU.

That is not fair. Granted SSU is for Oribter, which means all the onus is on the user to get the launch right, the orbit right, , the re-entry timing, everything, and also there is some freedom to get creative.

SSMS does a pretty good job simulating the GPC, APUs, the RMS arm/system, the APDS, the cooling systems. It focuses a lot on those systems, some are just switches, but a lot are not. It doesn't require proper cryo configs, makes rendezvous seem a bit to simple, doesn't really simulate the IMUs and the other navigation systems.

If the plan is for SSU to have a full Genearl Purpose Computer, and not just crude mimics of OPS1, OPS3 like Shuttle Fleet, actually have OPS202 for changing the orbit, a DAP to hold INRTL and LVLH attitude, and provide the proper counter thrust for the RCS, then you are really cooking with gas.

The Shuttle is not just about removing latches, opening the payload bay doors and deploying the KU attena, or even turning on the APU at the right time. The heart of flying the Shuttle is the GPC, especially OPS1,OPS2, and OPS3, and the DAP, and if the sim has that, then you can have a pretty good shuttle experience. That is what SSMS simulates real well, far beyond anything I have seen for Orbiter thus far. Even as nice as AutoFCS was.


But I have to admit, I was not aware a version of SSU was available, so I certainly will give it a look and help out by reporting bugs.

 

[Urwumpe]

The important difference is, that SSM doesn't simulate the Shuttle - it just replays data, and if you don't give it the right switches, the mission simply doesn't progress as planned, but there is no true effect on the indicators. It doesn't simulate at all, it just behaves like a interactive novel - the whole gameplay could maybe even be done by DHTML. The same with the computer screens. If it would be only about showing these screens and don't have to worry with the real vehicle state, it would be done in a week.

The problem is: Orbiter starts at the other end. SSM had the luxury to work easily top-down. You start at the user interface and make it pretend some sort of activity. Orbiter and SSU are bottom-up: We have a physical model that permits finetuning to the real flight data, and there are many subsystems and physical models following orbiter, before the data is eventually displayed.

The current plan for SSU is to have two different models of the GPCs. A simplified one that is based on native C++ code, and an emulation based on a reconstruction of the AP-101S. Since there is a lack of magnetic tape images with the original software, it would have to run with a custom FCOS for a while, but the emulation would be better representing the run-time behavior of the GPCs. Pretending concurrency with C++ code is a major PITA, which is why I advocate the emulation approach. It is better than using a modern VM for this, because we can maybe one day get hands on the real software - and then we are literally bound by honor and our role model NASSP, to use it.

Also, what I see as advantage for SSU, we can include what-if scenarios. Space Station Freedom would be possible, just like permitting missions with alternative shuttle hardware. Ever wondered how it would be like launching with LRBs and a Centaur G stage? In SSU, this is a current development task.

What I am against, would be over the top Challenger and Columbia demises. No problem with complex failures and damage, but there is one point, where you are just glorifying death.

So, in brief... I am not against SSM, I tested the demo on my PC as well and quite liked it, but it isn't a shuttle simulation. In SSU, we can do what we really want, and that is something that can fail. I am not sure, does SSM already permit RTLS aborts? I did them a few times in SSU, with the proper aerodynamics, it is really fun, despite the DPS still not having a RTLS autopilot - manual control is more fun there anyway.

And yes, most active development currently is about hardware, that is seemingly pretty boring. But it is essential, all fun-stuff is build on it, or would use pattern that can already be tested in such small subsystems.

 

[Cras]

What you say makes all good sense. And a lot of SSMS short falls is due to the mission, and that is to reply historical missions as being dircted by Houston Mission Control. What makes Orbiter so exciting is that, as you pointed out, you are in control, and the craft we pilot in it have to function in the physical world it simulates. And with that, much more freedom, getting to fly missions that never happened, building Freedom would be a lot of fun, and the ability to perform the aborts that have never been tried. And to have a failiure system where it may be neccessary to try them, not just a fun scenario to fly.

I had a lot of fun flying SSMS, flying though the missions, help build the ISS, but once those missions are done, then so is SSMS. Orbiter I can keep going. So I picked up the Shuttle Fleet, even though on countless occasions I have read that the real deal is with SSU, so I do very much look forward to its development. Flying things like the XR2 in Orbiter are fun, but the Shuttle is something else entirely. Flying by hand is always a fun thing,and an accomplishment to say hand flew the Shuttle from LEO to KSC, but the automation is also nice, it is fun to fly it like the real guys do it, with the automation either as the primary means or just a tool to help the crew out.

And of course it sounds like you guys are going beyond the mission of Shuttle Fleet, with the VC, the APUs, fuel cells, the GPC, the HUD. And what you guys are trying to do is no doubt harder than what SSMS did, for like you say, you are working from the bottom, having to get it to work with a very realistic gravity simulator, while SSMS has the luxury of cheating, as it so often does. Not an easy task, but once done, should be quite a rewarding ship to fly. Look forward to it.