helldiver

No, that isn't going to be done for now. In the future once we get all this mess squared away, we can make it so that the nosecone can open like a door, revealing a docking port. Would be a marvelous idea. But not in the first version. Ok so wait, the parts will snap in VAB correctly regardless of my collider mesh shape? For example, notice how the Cargo bay segment is flush with the cockpit/command segment right? So even if I make the cargo bay segment a bunch of boxes, and the cockpit/command segment a bunch of boxes as well, in the VAB they will snap together properly? Or do I have to define specifically the vertex in which they will snap at? Do to the complexity, the need of shaders, and plugin writing and integration, ZRM is going to be doing most of the importing. So my question is, @ZRM are you going to be able to determine where all the parts snap at so that the vehicle is flush? Do I need to do that before hand? I tried finding the vertex coordinate tool but wasn't able. If someone can post it, I'd really appreciate it. Right now my main concern is making sure the whole shuttle snaps together properly like legos. [Edit] I downloaded some mods where I ended up fighting with the parts to get them to snap properly. I don't want that to happen with the KSO, that's all. I once worked on a game that had a very intuitive vertex flagging system. You built your terrain tile as you wanted. You then went into the vertex paint tool and flagged all your vertices to be 0 value. The vertices on the edges that you wanted to snap to another tile, you'd flag 100 (the range was 0 to 100). Scenery vertices (so when you went into the editor scenery would snap to them) were flagged a value of 50. 0 meant nothing could snap to them. You then exported using their tool and it would generate a text file with addresses of all the vertices and their function. Really wish KSP worked like that

Man I'm so confused now regarding how parts snap in the VAB. What are nodes? *beats head against table*. You mean to tell me they didn't program it so that parts snap to vertex? Ok, so don't make colliders for the wheel well gotcha.

The wheel well collider is hollow so the strut collider shouldn't puncture it. That means both the cockpit and the wheel well would need 5 colliders components. I suppose the wheel well could be made as one box, and the strut collider could be animated to slide out and not go inside (instead of putting a scale transform controller which tend to be goofy). Oh and just a heads up to complicate maters more, all the landing gear assemblies are a little complex, they don't just rotate in and out. Note that the olio strut slides into the strut casing in order to give enough room as well as extend the gear far enough out. Another important question; in the VAB, parts snap to the vertices on what? The collision mesh or the visual mesh? The shuttle has been designed assuming that the parts in the VAB would snap to the visual mesh. If they have to snap to the collision mesh, it's not a problem, just that it will take longer to get the collision meshes done. Also, are we doing something that's not normally done in KSP mods? Feels like we're in frontier territory for some reason.

YEah I was gonna ask about the wheel well, I'll do... 5 boxes? And link it in its hierarchy. If we put collision boxes around the doors we'll run into issues with the door colliders intruding on the wheel well colliders and possibly the cockpit segment colliders. Ok, sounds good (ignore the convex portion of the lower side boxes in my first picture, I did it really fast and didn't pop out the vertices).

Alright, this should work I believe. I did it really fast just to get the idea across. Note that it uses 6 "boxes". I'm getting confused with the terms being thrown around, so I labeled the nose gear with the names I'm using. Simply point out which parts need a collision mesh.

Woah woah, landing gear is already animated. What do you mean by that? You mean wiring it? Alright, I'll take it step by step and post pictures, you guys let me know if it's legal or not. Since it's just boxes and no advanced texturing or anything like that, it'll be easy. Man, this is the most ass-backwards thing I've ever done. Usually (like in UnrealEd, or Cryengine) the skin mesh becomes the collider mesh on export with little tweaking. Although you can make a collision mesh very easily by lowering the resolution of your silhouette mesh.

-That was an oversight on my part. I knew about the 10000s hands but I didn't think KSP used it. Adding one would take 10 seconds. Gotcha -Tomorrow I will post a picture of the collision mesh for the cargo bay and wings, and you guys can tell me if I'm on the right track. Hrm... ok I'll do boxes then and label them and you guys can point out which I don't need or you can delete them in Unity. Not a problem -Ok that's all easy Thank you guys so much for the help, I'm 85% finished on my end. I'm trying to make things as seamless and easy for ZRM as possible. Think we can get a testing package by end of the week? ZRM, you will have to add the Navball into the cockpit, are you able to do that? Do you want me to model our own navball? My concern is the texture it uses. Hence why it is still missing. But I can tackle it if we want to use our own with textures that match your PFD display. [Edit], you guys said that the complex objects can be more than one collider box. So all these collider boxes (like the "cage" idea for the cargo bay) can be one object? Or a bunch of separate objects linked in a hierarchy?

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.

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.

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.

-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. 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. Nah, those seats are permanently bolted on. Only moving I'll be doing is for Kerbal scale purposes. 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. ??? 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 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.

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.

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.

Looking fantastic. On the MFD I'm going to put a small black border around it, just a few pixels wide. You don't have to make any changes since the border is part of the MFD mesh part not the instrument pane. Looking forward to the NAV and ENG screens. Currently no, but I definitely want them to eventually. Hopefully we can figure it out, if not when the time comes I'd definitely appreciate your help and guidance on how to get that working. More like ZRM to be honest since I deplore Unity. I covered this in a previous project summary, but I don't expect everyone to go back and read every thread (I myself don't have the time to do such a thing). As I explained earlier the KSO was never intended to be separate parts. The reason it ended up being separate parts was because I didn't/don't know how KSP handles components. When I proposed the project (this thread) most of the responses and advice leaned towards the "parts" idea. Originally the KSO fuselage was going to be a single piece, with the vertical planes, landing gear, avionics, and docking component separate. Since learning that it didn't have to be separate parts, I've welded some sections permanently (i.e. the SAS and Cockpit segments for example). I specifically made the wing base so that it would snap to the cargo bay in that fashion. Again keep in mind that I originally never planned for the wings to be separate parts. The other issue (the more important one) is the one of aesthetics; I don't want a disjointed look. I intentionally designed the KSO to be sleek and aerodynamic and "chibby" like the original pics that inspired me to make it. To get proper edge flow, loops, and later sub-division of surfaces, meant that the wing-to-fuselage join as well as other locations wouldn't be flush if I split them. I could have made it very geometric, but then we wouldn't have ended up with the aerodynamic look I wanted. I'm not making an angular looking craft, there are plenty of parts pack on the Space port for that. Possibly in the future. Again, it's still up in the air if I'll end up welding more of it together. The cargo bay attachment points have plenty of spots to attach things to of different sizes, unless you're trying to add something that is specifically the exact size as one of the attachment pads. Definitely going to include a it and include it in the mod, it will have all the action groups and such as well. We definitely will! When we start adding the engines, I'm sure we'll have a ton of questions. You'll see a labeled pic of the whole thing, and I'll probably be asking what to name what part or what needs a collision mesh and so on. Not now however, I'm trying to keep at the right pace. I'd like to tackle one problem at a time. And thank you so much for the awesome support!

Currently no, not that I know of. If ZRM is able to program the ADI, NAV mode (for orbital flight), and any other monitor we need, then no. Otherwise I'd be glad to ask for his permission. Unfortunately at this point I don't think the art style would match and I would have to be able to edit the display to match the KSO's glass cockpit. So odds are that it would be a no. That's a no to your first question. Although there will be a navball on the control panel (just above the altimeter and inbetween the center and pilot MFDs) we are not spending any time or effort working on it. Although I'm placing it at the best location so you are able to zoom out a window while still having it in view. That being said, the NAV mode of the MFD will eventually have all of the information you need to do orbital maneuvers with the KSO without resorting to the Navball. Don't confuse the ADI display (which ZRM and I have been throwing around) with NAV display (which we haven't really developed yet). A few pages back ZRM and I discussed NAV mode, and we settled on something similar to ADI but with additional information for orbital work. -You will have to learn the new NAV mode which may require some minor getting used to. However, I think in the end you will appreciate it much more than the cluttered up Navball. All of the information you need will be in NAV mode in an intuitive and clutter free method. We'll test it extensively before you download this mod and start playing. If we find that it doesn't work, then we'll bring it closer to the Navball. As I said earlier, the standard KSP Navball will still be there (two of them infact), in case we are still testing and developing the NAV mode of the MFD. You won't be using the ADI for Orbital navigation. The MFD can be switched to NAV mode (see earlier screenshot of the MFD), which has all the info you need for orbital maneuvering. -The MFDs have switches to change the mode the MFD is in (ADI, NAV and ILS for first release, Additional cameras, and docking cams, later) -The overhead panel has switches to turn on the cabin lights, panel backlight, and so on. -The Flight Director has push buttons for RCS, SAS, etc so you can activate them. -Throttle control. Currently that is all I have planned. Perhaps once we get everything in game we may discover additional things we can add.

^^^^ This -I've done contract work in the past as well as been involved in game development (as well as my own game). I have a very clear notion of what the limits are to some degree. Right now the budgets are sitting at: -2048x2048 (Diff, Spec, Norm, Emissive, Opacity) single texture sheet for the entire cockpit, minus the gauges and MFDs. -2048x2048 (Diff, Spec, Norm, Emissive) single texture sheet for the KSO -512x512 (Diff, Spec, Norm, Emissive) for the Guages. -1024x1024 (Diff, Spec, Norm, Emissive, Opacity) for the MFDs. -1024x1024 (Diff, Spec, Norm) for the engines (both the Thrustmax and the Omnimax use the same texture sheet. -1024x1024 (Diff, Spec, Norm) for the Docking Module. The IVA of the Docking module might end up using the same sheet. The IVA for the Docking module is not part of the first phase of the project. The KSO sits at 7800 polys (including engines and accessories), its cockpit sits at 17,000 polys (17200 if you include the accessories such as gauges and MFDs). So, from a technical or engine standpoint, Unity can more than handle this with a lot of room to spare.

Here's an update. Cockpit art is about 75% finished. Got to do an edge highlight thing and some more details around the back panels and such. Lights turned down. Looking towards the PIC Looking back from the pilot in command location If you don't want to break the illusion, don't view this image. http://i.imgur.com/pIBNl1f.jpg Kind of meh that the lettering is blurry, but not on anything usable, just the non-usable stuff. Although if you zoom out in-game you should be able to make out what everything says. Functional gauges use their own texture, so rest assured. Adding the artwork of an actual FMC is easy and something we could do in the future, as well as replacing the flight director with the status tapes NASA uses (for things like O2, RCS Fuel, etc). The layout is flipped and uses panel managers instead. Otherwise it follows a dissimilar setup to Atlantis based on what images and info I could find. I'm moving along to finish this, I'm not going back in to make it 100% accurate to Buran, Atlantis, or whom ever's favorite spacecraft. [Edit]The blank gauge you see on the control panel is where the Navball goes.

Fantastic! So we've got the NAV mode figured out. The only modes missing is ILS and the ENG (Engine) display. Regardless, folks are going to have to learn to work the ADI and the NAV. Also, keep in mind that you are already relaying the information of the directions that are out of view by having the compass down below. Unless I'm missing something. For example, I know right now I'm pointed 0 North. If I yaw right, I know I'm going to start heading east because the compass tape will start increasing above 0 and the E will eventually come up when I hit 90 degrees. Also at the top the North will switch to East. So I don't see a need to show the directions that are not visible. Unless I'm missing something, hrm. [Edit] I think we're saying the same thing, lol!

Yeah, exactly. Check this one: I like the Prograde Retro, Target, etc, being ticks on the compass tape: -The targets also show up as Ticks on the compass tape, allowing me to Yaw to the correct heading. -The targets also come up on the pitch ladder (similar to an ILS approach instrument). This allows me to set the proper pitch to the target. Note that both are off center because both targets are not at 0 degrees. However, we don't have to have them do that, you can simply put ticks on the Pitch ladder and another tick on the Heading tape. You simply Yaw to the heading on the compass tape, and Pitch to the tick on the pitch ladder, if you wanted to simply things even further. -If roll is a factor, simply put another tick on the roll marker. If we can pull off this tool, I don't see a lot of people using the Navball. By the way, the cockpit has spots for Navballs and you can see it a few posts back. [Edit] This instrument assumes that propulsion is at the rear of the KSO, and that the KSO does most of its maneuvers nose first. We would need to implement a docking camera in order to properly dock with the auxiliary docking module.

Ahh I getcha. For targetting pointers just steal the default ones. They would come up in Nav mode as I show above (Retro, Pro, Maneuver and so on). They'd appear in your gimbal as they do normally. For roll indicator do what real aircraft do, the roll indicator at the top can read more information if you go beyond 120, you don't have to make it a full circle (the readout increases the numbers).

What the MFD shows when you select NAV mode. -Gimbal flips to 90 horizon, 0 sky pitch -NO Cardinal heading on the gimbal. This is to avoid clutter. I find the KSP Navball confusing. -Heading is on the compass tape at the bottom. The main cardinal directions in degrees, the tick marker is replaced with the cardinal letter (0 marker with N, 180 with S, 90 with E, 270 for W). At every 45 degrees, you have an additional cardinal marker, 45 would show NE, 135 SE, and so on. -At the top where it says NORTH 000, that would be replaced with the cardinal heading and the digital degrees number (i.e. NORTH 010, EAST 126) and so on (there would be a 45 degree blend before it flips and says the next cardinal direction. So it only shows north if you are between 315 and 45 for example (would show west or east if you are less than 315 or greater than 45 respectively). -Altitude and Speed tapes are Blue to denote that they are not in Knots and Feet anymore but in Meters Per Second, Meters respectively.

The ADI works perfectly for orbital flight, there is almost zero difference between an ADI and a nav-ball. The only thing is that the ADI doesn't have the heading markers on the gimbal. However, you don't need the heading markers on the gimbal since you are putting that information on the compass tape. All you would have to do, is put an orbital direction tape on the ADI and you have a digital navball. That's what NAV mode was supposed to be. It replaces the ADI's Compass tape with the orbital direction tape, both devices are essentially a gyro. In NAV mode, the ADI switches its pitch markers to 0-90. So on launch you would select NAV on the MFD. You get the same ADI you would get in HDG mode. Except that the gimbal pitch markers have 0 at the top, 90 at the horizon. You can superimpose cardinal degrees on it, but that's just confusing when you can simply use the compass tape to show heading. Also, I thought the in-game Navball had the ability for you switch between Orbit and land modes?

Yeah, the seat cushions will be blue. Although after I did the carpet, blue seat cushions might bleed a bit. So I might experiment with other colors, like burgundy. Already started texturing. It's a meticulous process since I'm loosely basing the instruments on a 777 and on Atlantis. Nothing is realistic (I don't want it to be), but everything looks functional. Radios are where they would be, auto-braking/gearing panels where they would be. I shortened up all the labels and such since a lot of those details is lost at that resolution. Besides you won't be looking down at the center console or overhead ones for long. It would be impossible for us to do an FMC. Not planning on it, maybe in the super-future if there is enough demands, people like the KSO, and we continue to support it, I might convince someone to help me program one (Flight Management Computer). Maybe make it into MechJeb but inside the cockpit. Afterall, an FMC is pretty much MechJeb for an airliner. The KSO uses F-14 Inspired ejection seat looking things. If you scroll back a bit I posted a picture of them, they look really cool. Fluff The Murica corporation was at a loss to what seats the KSO would use. They experimented with all sorts of contraptions including lawn chairs. In the end they settled on using the same seats as those used on one of their fighter jets. Murica Corp. originally intended for the KSO to have fully functioning zero-G ejection seats (one of the contract stipulations by the KSP). Unfortunately the KSO's airframe was designed by VEG Design Group, who was adamant about cutting holes on the roof of the flight deck in order for the seats to punch through. After much lobbying, KSP and Murica Corp. were eventually convinced to drop the ejection seat idea and instead install a fast escape system. The seats were then converted to have fully functional survival equipment (first aid kit, oxygen and nitrogen canisters, temperature control, and High-G auto-inclination system). I'll post more pics of everything tomorrow when I finish up more of the flight deck. I'm marathoning this as much as I can.

Just keeping everyone updated. Keep in mind these shots are just the raw AO bakes, I still have to go in and touch up the AO. It can take up to an hour or more just to bake the AO. Normal maps took less than ten minutes to do (including the projection cage). Just got to cast the seats and I'm moving on to texturing. The instruments that are completed are lit. During normal gameplay they won't be lit, but you will have a switch on the overhead panel to turn on the cockpit panel back light. I would like to be able to turn on and off the internal cockpit lights so you have better visibility. Ignore the translucent effect of the MFD. In game, the instrument data plane would be there.

We're seeing the light at the end of the tunnel. So hopefully we should get this out soon. The big part of the project is soon coming to a close (all the art assets). Next step is getting it all in KSP. The cockpit has just taken me a bit because it just has a lot of detail and such. But it's UVed and the Sub-D is almost done, just got the seats to do. Yup, and that would be no to your other question as it goes completely against the design. As I explained earlier I'm making an orbiter, not a parts pack perse. This is also a no currently. As I explained earlier being able to switch the name of the KSO is something for the future. Everyone is getting the Dauntless test KSO, later on I might be able to work with ZRM if he's willing (and by later I mean way later) we may be able to come up with some shader system for that, possibly using the technologies he developed for the MFD. Essentially the entire orbiter would become an "MFD"... However doing that right now is out, we're not putting anything else on our plates. I want to finish this project, and want to be flying it ASP. Bogging it down with additional programming, bells, and whistles might cause us to enter "modding hell" or fizzle our enthusiasm (the most common causes of mods dying before they are completed). Fantastic!