Kerbin Mini Shuttle

[helldiver]

Anybody have an idea about some of these instruments on the Space Shuttle PFD? I'm just wondering whether there's a really useful one we're missing out:

What is the instrument marked alpha? Is that the pitch angle? It looks like the Altimeter and VSI are on the right hand side, with the airspeed on the left. What about the three scales (one horizontal, two vertical) all marked from 5K to 5K, and the scale at the top of the navball? The G-meter also looks like a useful addition.

The 5K markers are Pitch, Roll, and Yaw rate indicators; we don't need those. Interesting that they put an ILS instrument at the bottom of the PFD.

They're using Knots Estimated, which is what I suggested for our ADI not the NAV (orbital ADI). When you switch to orbital that airspeed would read M/s as standard KSP.

Website for more info:

http://www.spaceshuttleguide.com/system/dedicated_display_systems.htm#Attitude_Director_Indicator_(ADI)

The NAV mode we worked up is fine, otherwise this is going to spiral into modding hell.

[ZRM]

Semi final, forgot to do the window and MFD glass (they are separate pieces). Also need to detach the throttles and any other parts that will be movable. I'll post a diagram with collision labels so you can clue me in on what needs collisions in preparation for export.

What your view would look like if you went to the PIC position camera and didn't move it or Zoom it (you can zoom in and out in KSP in case you guys didn't know)

Finished the highlighting. I'm keeping things clean and simple to loosely match the KSP style. I didn't want to clutter the already clean look, so I didn't put additional status panels on the d-pylon bulkhead behind the pilot's seat. I left it clear except for a single access panel, nothing fancy. That area is also at an angle it seems, so putting a panel and buttons there would cause them to be slightly blurry. I don't know, if you guys think it looks to sparse I can add more. But I think I like the clean simple look. As they say, less is more.

Looking towards the rear.

Future Docking camera locations (on the other size)

The seats are under-scaled with plenty of room to make them larger or move them. Their shadow is also temporarily baked and can easily be moved and redone, same with the pedals and control column. Once in game I'll judge it by viewing the Kerbal and going from there. I may put together a measuring rig so we can set a Kerbal against it and get measurements.

Very nice.

Just a thought - if there are 4 Kerbals, all in their seats, none of them have a view of the docking console. We can get the camera to the docking console easily, similar to the way double-clicking on stock command module windows moves the camera to the window to get a better look, however there won't actually be a Kerbal standing in front of it.

Also, if you want to really fit in with the stock cockpits you could fill that empty panel space with storage cupboards, with labels on them such as "stuff", "things", "rubbish", "garbage", "refuse" etc., though I admit that would break the very tidy and orderly impression the cabin has.

If you do make a measuring rig, it would be very useful to publish the resulting measurements for other modders to use. I expect that this is a problem people encounter quite frequently, and always solved by trial and error.

[ZRM]

The 5K markers are Pitch, Roll, and Yaw rate indicators; we don't need those. Interesting that they put an ILS instrument at the bottom of the PFD.

They're using Knots Estimated, which is what I suggested for our ADI not the NAV (orbital ADI). When you switch to orbital that airspeed would read M/s as standard KSP.

Website for more info:

http://www.spaceshuttleguide.com/system/dedicated_display_systems.htm#Attitude_Director_Indicator_(ADI)

The NAV mode we worked up is fine, otherwise this is going to spiral into modding hell.

Sure, I wasn't planning on changing anything unless there was something really useful missing.

[DisarmingBaton5]

Just a thought - if there are 4 Kerbals, all in their seats, none of them have a view of the docking console. We can get the camera to the docking console easily, similar to the way double-clicking on stock command module windows moves the camera to the window to get a better look, however there won't actually be a Kerbal standing in front of it.

Same thought I was having. Maybe move the docking console to the back of the pilot seats or above the cockpits, facing downwards? That way, the rear Kerbals get a view of the docking console(s).

[ZRM]

Same thought I was having. Maybe move the docking console to the back of the pilot seats or above the cockpits, facing downwards? That way, the rear Kerbals get a view of the docking console(s).

How about chairs that swivel and lock into place? They would have to be placed further back than they are now, though, and it might be tricky to get just right, though it would be extremely cool.

[DisarmingBaton5]

How about chairs that swivel and lock into place? They would have to be placed further back than they are now, though, and it might be tricky to get just right, though it would be extremely cool.

That would be awesome, but how would you get the Kerbal to turn with the chair?

[ZRM]

That would be awesome, but how would you get the Kerbal to turn with the chair?

Well, if the Kerbals are attached to GameObject instances like anything else, moving the chair should hopefully move the Kerbal correctly, as long as the hierarchy is set up correctly in Unity.

Another thing to be considered for that to work - the minimum crew requirement command module setting. I think, realistically, the minimum crew for the Shuttle should be at least two for the docking console to be operable.

[Dave7]

The kerbals in the back seats wouldn't be looking at anything other than the back of a seat. You could make their seats face the sides and give them a little console or something. You may not have enough room on the sides though.

[DisarmingBaton5]

The kerbals in the back seats wouldn't be looking at anything other than the back of a seat. You could make their seats face the sides and give them a little console or something. You may not have enough room on the sides though.

You can rotate the camera while in a seat.

[ZRM]

BTW, I have now released a proper bugfix version for KerbCom Avionics to fix all of the critical bugs that I know of. So now I can make some tentative guarantees about the performance of the shuttle using the gimbal, reaction wheel, RCS and thrust balancing. Now I just need to get the Linux and Mac support working correctly.

[CERVERUS]

AMAZING (!!!) work...

Ok the shuttle is fantastic...but the interior is awesome,superb!!!

CONGRATULATIONS!!!

[MinerEdgar]

I agree those interior are amazing, but i feel I'll need a better computer to do this mod justice.

[The Destroyer]

Seriously this is the best plane I've ever seen.

[TouhouTorpedo]

Very nice.

Just a thought - if there are 4 Kerbals, all in their seats, none of them have a view of the docking console. We can get the camera to the docking console easily, similar to the way double-clicking on stock command module windows moves the camera to the window to get a better look, however there won't actually be a Kerbal standing in front of it.

Also, if you want to really fit in with the stock cockpits you could fill that empty panel space with storage cupboards, with labels on them such as "stuff", "things", "rubbish", "garbage", "refuse" etc., though I admit that would break the very tidy and orderly impression the cabin has.

If you do make a measuring rig, it would be very useful to publish the resulting measurements for other modders to use. I expect that this is a problem people encounter quite frequently, and always solved by trial and error.

I'd really rather he didn't add those kind of labels everywhere, it just looks a bit tacky to be honest. Access panels, joining textures, maybe, but not big labels saying "food" "not food". Like you said after - best to stick to the tidy look.

I don't know if you can or can't click things after moving the camera via the double click method. Never tried to double click into a double click view, don't even know if that's possible. Kerbals can't look too far left or right either. I doubt they can look far enough back to even see those screens behind the rear seats. They most likely won't be able to see behind the Kerbal besides them at all.

[helldiver]

Very nice.

Just a thought - if there are 4 Kerbals, all in their seats, none of them have a view of the docking console. We can get the camera to the docking console easily, similar to the way double-clicking on stock command module windows moves the camera to the window to get a better look, however there won't actually be a Kerbal standing in front of it.

Also, if you want to really fit in with the stock cockpits you could fill that empty panel space with storage cupboards, with labels on them such as "stuff", "things", "rubbish", "garbage", "refuse" etc., though I admit that would break the very tidy and orderly impression the cabin has.

If you do make a measuring rig, it would be very useful to publish the resulting measurements for other modders to use. I expect that this is a problem people encounter quite frequently, and always solved by trial and error.

-No view of the docking console.

-No Kerbal at the docking console or the SSMC (Spacecraft Systems Management Computer). Both of these that I showed in the above screenshots are "fluff" art. Meaning they serve no gameplay function.

In real life astronauts don't sit there, they float over and operate it. Not spending time and effort simulating that as it's not necessary in the name of gameplay. In the future when we get the docking camera implemented, you can switch one of the MFD on the front control panel to the Docking cam. That is the extend of it, I'm not taking it any further.

Same thought I was having. Maybe move the docking console to the back of the pilot seats or above the cockpits, facing downwards? That way, the rear Kerbals get a view of the docking console(s).

No, that's not possible. Only the seats, rudder pedals, and HOTAS have been kept modular temporarily for Kerbal fitting purposes, no other purpose. The four seats are meant for the Kerbals to sit tight and launch. You don't do anything in those seats just like in real life. The only people doing anything from their seats is the mission commander (flying the shuttle) and the guy next to him. The mission specialists behind them don't do anything from their seats (aside from monitoring stuff or helping with check lists what ever). When they get into orbit, they leave their seats and go to the different crew work stations. I'm not simulating that portion.

Ideally the KSO features collapsible seats; fluffwise the Kerbals would collapse the two rear seats becoming work stations. They then float to either the SSMC or the Payload and Docking Camera Console (PDCC), or they go down below to the Mission Deck.

How about chairs that swivel and lock into place? They would have to be placed further back than they are now, though, and it might be tricky to get just right, though it would be extremely cool.

Nah, those seats are permanently bolted on. Only moving I'll be doing is for Kerbal scale purposes.

Well, if the Kerbals are attached to GameObject instances like anything else, moving the chair should hopefully move the Kerbal correctly, as long as the hierarchy is set up correctly in Unity.

Another thing to be considered for that to work - the minimum crew requirement command module setting. I think, realistically, the minimum crew for the Shuttle should be at least two for the docking console to be operable.

No moving of Kerbals or chairs. Not only does it go against the design, but it doesn't make sense functionally. That's a big no.

The kerbals in the back seats wouldn't be looking at anything other than the back of a seat. You could make their seats face the sides and give them a little console or something. You may not have enough room on the sides though.

???

I agree those interior are amazing, but i feel I'll need a better computer to do this mod justice.

You should be fine. If you have a large Kethane operation or a spot with lots of parts like a space station or something, then yeah you might have issues.

I'd really rather he didn't add those kind of labels everywhere, it just looks a bit tacky to be honest. Access panels, joining textures, maybe, but not big labels saying "food" "not food". Like you said after - best to stick to the tidy look.

I don't know if you can or can't click things after moving the camera via the double click method. Never tried to double click into a double click view, don't even know if that's possible. Kerbals can't look too far left or right either. I doubt they can look far enough back to even see those screens behind the rear seats. They most likely won't be able to see behind the Kerbal besides them at all.

I completely agree.

I think it's fine as it is, we captured the KSP look more or less with a little modern taste which is what I wanted originally.

In the future when KSP implements IVA activities we can do things like ZRM suggested or like some of the other suggestions. Particularly modeling the mission deck down below or realizing the SSMC and the PDCC. However that's for the super future.

Edited August 15, 2013 by helldiver

[tygoo7]

Would the parts be compatible with Deadly Reentry? I don't want the shuttle to burn up and explode since I have it installed. BTW those interiors look amazing!

[The Destroyer]

???

I think what he means is that some kerbals that are looking at the back of another seat should be facing another way with some sort of console for them?

[helldiver]

Would the parts be compatible with Deadly Reentry? I don't want the shuttle to burn up and explode since I have it installed. BTW those interiors look amazing!

Good question

The KSO project is compatible with a stock installation of KSP using ZRM's KSO related plugins (the KSO plugins are one and the same, the shuttle won't work without ZRM's plugins). That is my goal.

Once we get the KSO features in and working then I can work with the community to enhance or fix any compatibility issues, but it will not be a priority. My apologies in advance if this is gonna bum out a lot of you guys.

I neither have the time or enthusiasm to account for many of the community mods out there (that includes Ferram Aerospace).

Once the KSO is flying perfectly, the Cockpit MFDs and instruments function flawlessly and we have it complete and done done, (and people are downloading it and flying it as bug free as we can) then I'll talk to ZRM or any others helping me about changes to accommodate physics related mods.

In fact, I don't even want to mention it to ZRM as I don't want him to feel overwhelmed. Getting the MFDs working is enough as it is and he's been awesome and kind enough to get this project going. Actually if it wasn't for ZRM's work on researching the shaders odds are this project would be dead in the water by now.

Again to make it clear; We are NOT accommodating physics related mods for the first version of the MOD. There will be a big warning on the download in bold. I want to be flying this yesterday, I don't want to spend another three weeks working out the compatibility issues with other mods.

[Toyotawolf]

Good question

The KSO project is compatible with a stock installation of KSP using ZRM's KSO related plugins (the KSO plugins are one and the same, the shuttle won't work without ZRM's plugins). That is my goal.

Once we get the KSO features in and working then I can work with the community to enhance or fix any compatibility issues, but it will not be a priority. My apologies in advance if this is gonna bum out a lot of you guys.

I neither have the time or enthusiasm to account for many of the community mods out there (that includes Ferram Aerospace).

Once the KSO is flying perfectly, the Cockpit MFDs and instruments function flawlessly and we have it complete and done done, (and people are downloading it and flying it as bug free as we can) then I'll talk to ZRM or any others helping me about changes to accommodate physics related mods.

In fact, I don't even want to mention it to ZRM as I don't want him to feel overwhelmed. Getting the MFDs working is enough as it is and he's been awesome and kind enough to get this project going. Actually if it wasn't for ZRM's work on researching the shaders odds are this project would be dead in the water by now.

Again to make it clear; We are NOT accommodating physics related mods for the first version of the MOD. There will be a big warning on the download in bold. I want to be flying this yesterday, I don't want to spend another three weeks working out the compatibility issues with other mods.

Here here, i second that motion

[tygoo7]

Good question

The KSO project is compatible with a stock installation of KSP using ZRM's KSO related plugins (the KSO plugins are one and the same, the shuttle won't work without ZRM's plugins). That is my goal.

Once we get the KSO features in and working then I can work with the community to enhance or fix any compatibility issues, but it will not be a priority. My apologies in advance if this is gonna bum out a lot of you guys.

I neither have the time or enthusiasm to account for many of the community mods out there (that includes Ferram Aerospace).

Once the KSO is flying perfectly, the Cockpit MFDs and instruments function flawlessly and we have it complete and done done, (and people are downloading it and flying it as bug free as we can) then I'll talk to ZRM or any others helping me about changes to accommodate physics related mods.

In fact, I don't even want to mention it to ZRM as I don't want him to feel overwhelmed. Getting the MFDs working is enough as it is and he's been awesome and kind enough to get this project going. Actually if it wasn't for ZRM's work on researching the shaders odds are this project would be dead in the water by now.

Again to make it clear; We are NOT accommodating physics related mods for the first version of the MOD. There will be a big warning on the download in bold. I want to be flying this yesterday, I don't want to spend another three weeks working out the compatibility issues with other mods.

Sounds good

[Marscommander]

Good question

The KSO project is compatible with a stock installation of KSP using ZRM's KSO related plugins (the KSO plugins are one and the same, the shuttle won't work without ZRM's plugins). That is my goal.

Once we get the KSO features in and working then I can work with the community to enhance or fix any compatibility issues, but it will not be a priority. My apologies in advance if this is gonna bum out a lot of you guys.

Wait, What? we have to use ZRM's mod for the shuttle? (no offense ZRM but I don't exactly want a balancer mod) Or do you just mean the shuttle mod itself. Because you didn't say anything about this before... Even so this shuttle is so awesome that I could use any mod even if it removed the kerbals themselves.

[helldiver]

Wait, What? we have to use ZRM's mod for the shuttle? (no offense ZRM but I don't exactly want a balancer mod) Or do you just mean the shuttle mod itself. Because you didn't say anything about this before... Even so this shuttle is so awesome that I could use any mod even if it removed the kerbals themselves.

Yes you're going to need ZRM's mod in order to run this. How far that goes I would have no idea at the moment. My goal is to make the shuttle functional in a one stop solution. I don't want to fidget was stuff, even if it means it requires a mod solution to be a part of it. Its flight characteristics as well as the engine numbers are all bound with the assumption of ZRM's avionics mod.

It was one reason why earlier on I had asked ZRM in his thread if his mod could be integrated into a part. For purposes of this mod it would have been integrated in the avionics portion.

ZRM will be taking over that portion of the project (coming up in the next few days). I asked him specifically to integrate it all with his mod. The goal is (my goal is) that the average user can download the mod and in just a few minutes with basic KSP launch, orbiting, maneuvering, and decent skills be able to fly this thing. That is my top priority and I'm not deviating from that.

Without his mod (and without proper numbers and flight envelope parameters) people are going to have a nightmare flying, launching, and putting this in orbit. I know, I tried.

Now the part I don't know (and I'm sure he probably doesn't at the moment) is if the KSO will have its own version of ZRM's avionics mod as part of it. We'll find that out once we start testing things in-game.

To clarify: I don't know if you will need KCA specifically. I do know, and I have asked ZRM to use something similar (or the same) to wire the KSO so that it flies properly both atmospherically and in orbit in a space shuttle (piggy back) configuration. He might end up programing an FCS using his KCA mod, I don't know. The ultimate goal again, is for the average non-advanced user to be flying this thing successfully 5 minutes after installing it. Maybe later we'll release a bare bones version without an FCS for advanced users of KSP.

I want my work and his work on the project to focus on cool add-ons to the shuttle; functional MFDs and IVA components, a mini rover, a mini roving vehicle, docking accessories, space station components that fit the cargo bay, alternate cargo bay segments like a crew module, expansion of the mission deck with lab stations, lift vehicle, and so on. I don't want to bog down the project with flight, center of mass, center of lift problems, drop rate, lack of proper flight envelope, and what have you, as to me that isn't fun.

Edited August 15, 2013 by helldiver

[skykooler]

I am hoping that the shuttle won't need the bit of ZRM's mod (lpsolve) that makes it platform-specific - I would hate to see this beautiful shuttle but not be able to run it because I don't have Windows.

[ZRM]

I am hoping that the shuttle won't need the bit of ZRM's mod (lpsolve) that makes it platform-specific - I would hate to see this beautiful shuttle but not be able to run it because I don't have Windows.

The mod does still run on platforms other than Windows - you just can't use the balancing features of it. I am also going to put some time aside shortly (i.e. today) to see if I can get it working properly on Mac. The only thing standing in the way of it being properly cross platform is getting KSP to find local native libraries correctly. On Windows this is easy, but Mac and Linux make this a bit more difficult.

Edit: Also, currently my plan is that the MFD plugin is a mod that should be independent of the shuttle and KCA - i.e. you should be able to wire it up in other custom cockpits, for example Firespitter screens. I would then make another separate plugin for any feature that is truly specific to the shuttle. So you would end up with 3 plugins - KCA, KCG (KerbCom Glass?) and the KSO-specific plugin.

Edited August 15, 2013 by ZRM

[helldiver]

Moving along.

ZRM (and any others with solid information).

I'm packing things up to send to you. First we'll tackle the cockpit and work in reverse (cockpit outwards).

I need to know what needs collision meshes and any other important 3D model in my part (I call them dummy models). Look at the hierarchy on the right and check it.

In the image above, the red are dummy collision models on top of the graphics 3d model. Each button on the MFDs have their own collision mesh as well, although you probably won't use ILS, AP, DTV1-2, DCK (although eventually we'll want to implement those modes). Note that the mfd's are named from LEft to Right with A being the left most, and A on the right being the right most.

The switches on the overhead panel are for the light system. The only switches we'll be using is lightswitch_panel, lightswitch_fd1 and 2. Lightswitch panel controls the emissive (on or off) for the entire cockpit backlights. Unless you want to leave the cockpit panel backlights always on. Lightswitch_fd1 or 2, will control and interior light source. How do I add that lightsource? Does a light added in max work? Or do you have to do that in unity? (that's 4 emissives all turned on by one switch)

Do these work as collision meshes? Do they have to be simpler? What are the rules exactly for collision meshes?

What parts on this landing gear need a collision mesh? Can the collision mesh be complex as you see there? Or can it be simple?

We're looking at a 300mb download currently. Although after DDS compression in unity, that number may be a lot smaller.

Let me know in PM or here any additional information.