helldiver

It doesn't work that way. If they are using a normal map (which odds are they are), we'd screw the tangents up by flipping the texture. Again I'd need to work with the originals to get things fixed. Also, working on decompressed DDS is a big no-no. For the MFDs and HUD that is correct. Ok I see what you mean with Analog gauges. No, that would complicate things a lot and would require I do some UV separation which I really didn't want to do. The fix I'm going to do has to do with twisting the UV and the geometry so that the numbers and such aren't twisted, thereby clearing them up a lot more.

ZRM that is exactly how I wanted them! Did you pose them to hold the arrest handles? Or did we get lucky? Man that is spot on. Those MFDs and the HUD need to get finished. Once we get all of this out of the way, I'm going to update Analog_guages with a new texture for the scales, but not at the moment. What you have there should hold us off. You explained that they didn't have to be linear? I forget. I don't think I understood the concept. This whole non-linear thing is new to me.

The artist didn't properly mirror his texture. If I could get the originals plus an OBJ I could probably fix it in a matter of seconds. Of course that could probably only be done by Squad.

What lighting solution did you use in these shots? -Did you use an actual light? Because that looks perfect. Do you see the orange/red medical bag behind the PIC's headrest? That contains multiple barf bags

That's a negative. As ZRM said, we still have a host of bugs and parts of the project that aren't complete. For example we're still fleshing out the MFDs. Once all of that is complete, I'm going to do a texture/art study with the model in game. So far based on shots I've seen, I don't see anything incorrect. But again I have to view it in game to make sure all parts are functioning the way we intended, they are displaying the way I intended, and are hassle and bug free. I never release incomplete work. Most of any that would probably be texture swaps, nothing too intense or requiring programming. Once all of that is out of the way, and we're both satisfied, I'll give ZRM the green flag to proceed with packaging it and putting it up. We'll then make a post on the released mods forum and we'll go from there. Right now the big hurdle for me are the MFD artwork.

I just noticed that the Kerbal Cam, is clear, no geometry is intersecting between the kerbal cam and the kerbals. Did you do anything? Did we luck out? I was afraid that the panel geometry would intersect and you'd see some of it when viewing the kerbals down in the lower right hand corner.

That is beyond amazing! Forgot this image in the last message. -gimbal range is +- 10.5. I'm ok with 11 or up to 12 if you absolutely have to. The clip isn't that noticeable. -If the engine overheats, blow up LRB_Nozzle_Base and LRB_Nozzle. If you don't remove both of these you'll reveal LRB_Nozzle_Base which is just filler artwork. This images look fantastic! Great job!

I can make an optional parachute box that can attach to the base of the rudder (or anywhere you wish to put it). However, you guys will have to wait until phase 2. Also, some of you guys are going way too into Simulation territory, and forget this is for KSP which is a bit arcadish. Things like a split air-brake rudder, drogue chute, spoilers, and so on is taking things too far. I was debating fully modeling the wing with a fully functional stabilator, spoiler, aileron, and elevon system like real airliners/space shuttle uses, but it's just a bit much. Also, I'm not quite clear as to whether or not KSP takes into account such physics. We have to remember that KSP isn't XPlane or FSX with a proper aerodynamic model.

ZRM, you also have automatic fuel feeding without a KSP fuel line? Update: -I just sent off some additional support materials needed. That included the updated Nav ball and components, engine emissives as well. -I ran out of time today since I wanted to marathon the MFD components, will try and get them done throughout the week, one mfd at a time (starting with ADI and so on) Just wanted to clear up guys that we are not adding anything to the project that deviates from our original goals. The only things I added was the lift vehicle and this was because as ZRM discovered, we needed to do some custom work in order to get it all functioning correctly. Any work that may seem like "bloat" is actually stuff we discovered that was either missing, bugged, or required for the project. Most of the additional technical work is on ZRM's side as he discovered issues with KSP, including bugs, incomplete components and so on that needed to be cleaned up, added, or repaired

This man is beyond incredible. Just got this today during our regular dev updates. Keep in mind this is still WIP and ZRM is still bare-bones on flight data and such. -ZRM's WIP -Please do not remind us that the nose cone and LRBs are missing (or V-tail configuration). Each part has to be tested and possibly programmed to ensure it functions properly. The more ZRM works on this the deeper the rabbit hole has gotten.

My navball doesn't really change anything from the original, aside from the new texture. As ZRM said you could simply replace the stock textures with the ones in this project. In regards to using the actual Navball instrument; Not currently. Definitely once we have everything going I can split off the instrument itself (the Nav ball holder is part of Analog_guages mesh and we could package it so someone could use it to replace the stock one.

Just a quick update. I decided to go with a texture on the navball that was closer to what the Space Shuttle uses as well as Apollo and such. It's a lot clearer and I made the fonts slightly smaller so that the whole thing is easier to read. This is still a work in progress since I'm stuck figuring out the texturing on the markers. -Note: The navball is being lit by its emissive. It won't be like the default KSP navball that is lit from a light source. Instead this ball has its own lightbulb inside.

Just a quick update: -ZRM is rounding out most of the larger parts of the project so that's getting knocked out. -Right now we've kind of slowed down a bit resolving some MFD related workflow issues on my end. It's a matter of coming to an agreement on certain resources and how they'll display as well as what ZRM's software can handle or work with. -The Squad, in-game Navball could not be used. I'll be assembling a new one from scratch using their Navball as a guide. Unfortunately, in order to provide a proper functioning MFD as well as Navball, we'll be delayed. Once the workflow issues are resolved, I'd be out of the gate and can complete that portion in just a few days. Keep in mind guys that if ZRM needs an asset from me, he can't do much but wait until that asset is completed. The goes same goes for me, I can't continue until he gets back to me if a feature is working or not.

General work in progress update -Work continues on the technical side, and we're definitely seeing the end of the first phase tunnel. -We've had a few hitches and delays mostly related to the cockpit IVA scale meeting the Kerbals. It seems despite my calculations, I didn't really think they were really just over two feet tall. In other words the Kerbals are much smaller than I originally anticipated. No offense to Squad, but that's a really difficult character scale to work with, specially the when you take into account the gnomish leg and arm proportions. ZRM has done a more than outstanding job on this project. He's been really patient with all my nit picking. The best part is that we should soon have the scale issue nailed down. It involves doing some minor adjustments to the seats. To be honest, I think it may be best if we collapse the lift vehicle into the first phase. I know this may delay the actual shuttle out, but it would give you guys a proper configuration that ZRM can tune. That way we don't have to go back and make more changes when we find the lift vehicle has weight/mass/attach point problems. We'll have some in-game screenshots hopefully by tonight if not tomorrow. ZRM has sent me several internal shots, but given this threads' propensity to skip on the info I put in, we'll have people wondering why the MFD's don't look right or something (even after we explain that it is a wip). So once we get all that cleaned up, I'll ask him to post up some shots of the in-game work so far. [edit] In case you're wondering, we're up to version 16 of the shuttle thus far, meaning there's been 16 iterations of the artwork so far

No, sorry I don't have that kind of time. My main goal is parts aimed at the KSO. Many of those parts will more than likely be generic just small enough to fit into the cargo bay. However you can use those parts for anything else. -Mini-rover. More than likely will be one whole thing with a few accessories such as batteries and instruments. -Mini moon lander kit. Command pod, fuel section, rover roll-on-roll-off, and engine mount. -Space station kit. Basically a series of components to build a space station all compatible with the KSO.

Will you need an ILS as well as a VOR beacon antenna to install at the airfield? The ILS transmitter goes near the runway, the VOR goes anywhere at the airfield. Your MFD ILS/VOR navigation mode pics up their signal and that's how you fly to it. Or do we want to do that later? Let me know and I'll put them together really quickly. I can make them small enough so you could use one of the many truck/rover mods to deploy it. ILS station VOR station [Edit]Although instead of VOR we should instead us TACAN which is what I believe the space shuttle uses. The antenna is much smaller and modular and can be deployed via truck.

You only get 1 rudder actually, but in the VAB you can place as many rudders as you wish. There's attach nodes for a v configuration or if you want to put it on top of the fuselage end. Same for the LRB, you only get 1 and you just copy it or place another in the VAB, heck you can place 8 of them if you want.

I'm not really sure what you're asking so I'll try and answer as best I can. -The robotic arm I'm making is a future addition. Right now I've stopped until we've got the KSO working in game. -The arm isn't really anything fancy. Its purpose is to push out cargo you have in the bay, that's it. You can grab things with it and pull them back into the bay. I don't know at this point if you'll be able to rotate it, so it'll pretty much just be like a jack. This would allow you to put things in orbit far enough away from the KSO so that it doesn't collide with the rudders or with the cargo bay. Basically it's a safe way to release the cargo without you having to RCS the cargo out of the bay; reducing the chance to collide with the cargo bay tub and blowing the whole thing up. -We're using way too many of other people's mods as it is. So for the KAS mod, you'll have to download it (or already have it installed) and attach the part yourself like you would any other part mod. The KSO won't have any parts that inherently use the mod. -In the super future, based on demand I could put together a parts kit for the KAS authors so that we could have a KAS that fits the KSO in a small package, again it's a future thing. Interesting how he has an Imperial cruiser. I own over 22,000 points of Imperial Navy, 18K of it fully detailed and painted.

Update: the KSP Lifter project files and textures were mailed off. I hope I'm not overwhelming ZRM.

It would be impossible for me to tell you when. However I'm in the same spot you're in, i.e. I want to start playing with it already. Actually I haven't played KSP since I started working on this project except for a few times I fired it up to take screenshots for reference. Our goal is to get the KSO done and out. The lift vehicle you see above is not part of that first phase, but it seems it may end up being part of it.

As long as you attach them with a TT-38K at the top you should be fine (or similar coupling). Use struts at the bottom to stabilize. You shouldn't need sepatrons.

The LRBs and the EFT are solid objects. No man, not solid fuel Solid as in they are not three or more pieces. The nosecone, middle section, end section are all welded. LRB are separate from the EFT though.

Enjoy -Up above is final. Some very minor changes maybe in case the stock engines don't fit the mounts which I highly doubt. -I'm not making couplers unless ZRM requires them. I think the stock couplers should be fine. -The mounting configuration you see there is what I wanted, so the attach points will more or less be in that configuration. -The EFT and LRBs are designed to be large and imposing. They aren't mini, I don't want them to be. This should give you plenty of power and fuel for other orbiters such as B9 kits or if you make your own. -Why is it orange and white and those colors? I tried my best to match the colors of the rockomax jumbo as well as other colors and patterns used in KSP. I didn't normalize the bumpy texture into the normal because it looked too strong and it just didn't look right (even the stock rockomax jumbo looks way too bumpy for my tastes). -EFT and LRBs are solid. I'm not making them separate pieces unless we run into issues (unlikely). I'm not messing with fuel distribution non-sense, so the tanks are solid. -There are engine mounting spots on the LRBs and the EFT, after all this is a Kerbal construct not NASA or Soviet -If possible I may install a nozzle into the LRB, making it an engine+LRB all in one with gimbal capability (but not vector). Will wait for feedback from ZRM if that is possible or if we should just let players decide what engine to install into the LRBs. Dimensions: -EFT 3.5m dia, Mount 1.6m dia -LRB 1.6m dia, Mount .8m dia I've moved on to collision meshes already. [Edit] Bleh, went back in and killed the liquid hydrogen hose, it felt unsightly and messed with the sleek vertical look of the LRB. Kept the LOX and pressure hose however.

Step 3 -After the low res game model is completed and fully UVed, I then import it into the high resolution scene. -I apply an Edit Poly modifier on both models (high and low res). This will allow me to move their elements without screwing them up. It will also allow me to do a good projection without object interference that can block rays. -I move all the elements of the Low resolution game model first. I then use snap to vertex and move the high resolution elements so that they match perfectly with the low resolution elements. -I select my low resolution game model and then Render to Texture and select my high resolution model as the model to project from (reference geometry). -The projection cage (in blue) has to be fixed so that all rays are cast correctly and with as minimal errors as possible, otherwise I'll have a lot of work to do in Photoshop. This can take a very long time depending on how complicated the model is. The projection tools are similar to standard mesh editing tools making the job slightly easier. Setting it to shade also helps in finding areas with casting problems. -I bake multiple times, typically at 256 or 512 resolution looking for miscasts. These can be found by setting miscast areas to show up as red on the baked texture (ray miss color). A note about what you can and can't do to a game mesh after you've gotten to this point. The KSP 3D Studio Max wiki has some errors in it that I'd like to clear up. What you CAN do -You can edit the geometry as much as you like, including deleting or adding geometry. However, your UVW will be messed up on any area you added within an element. If the area you added was an element and it already had UVW information, your mesh will be perfectly fine! -In fact the KSO is composed of a ton of pieces (elements) each with their own UVW that were all made into a solid object. This allowed me to move the UVW islands until it all fit on a single texture. -You can delete any part of your mesh and your UVW will be fine. -For advanced users dealing with the skin modifier, you can also delete and add to your mesh that has a skin modifier, you just have to do it down to the editable poly level. However, you have to be careful and do only one addition at a time. Move the addition over and close to the area you'll attach it at. Never add or attach objects at the Skin Modifier level or you'll wreck the vertex weight assignments. With some practice you can get really good at adding/changing legs, arms, torsos, heads etc on characters that are already animated and skin weighted. What you can't do -You can't share the UVW information of two different objects that have their own transform and vertex count/order. That means that if you add/subtract an element or vertex, you can only share UVW, Vertex Weight and Projection Cage information with a clone of that same object, but not of a clone whom you added or removed elements or vertices from its parent. This is for purposes of exporting and importing a UVW file, something most users here probably wouldn't be doing. -You usually can't share the same Normal Map of one object with the clone of the same object if that object had vertices removed, since it violates the rule above. Keep in mind when you bake a Normal it picks up the vertex/face tangent information of the mesh you casted on. However, you CAN share the same normal map on the clone of the same object which has had an element added or removed, as tangent information is preserved. This error manifests in a big nasty black spot on your model. You have no idea what's causing it since your smoothing groups are correct, and the mesh has no holes in it. That's when you discover that the tangents got fudged and you need to recast the whole thing. Step 4 -All textures I bake have to be fixed. In particular, Normal maps will always have geometry errors of some sort which have to be cleaned up using the smudge tool in Photoshop. This is why it's important to get as clean a cast as possible as you won't have to do as much clean up work. Also, the closer your projection cage is to your game model (without intruding into the reference geometry) the less geometry errors you'll have. -The AO map is used as the basis for all the shadows, grunge, and areas where dirt or dust has accumulated. This one also has to be cleaned up and typically takes the longest. Most 3D editing programs have issues with floating geometry and determining exactly where two parts intersect. So you'll often end up with the shadows and grunge offset by half a pixel. All those areas have to be filled in. The completed model with base texture, normal map, and a basic specular. And now I move on to final detail texturing. The rest of the work is all done in Photoshop.

It's actually slightly shorter now since it was a bit too tall. But not by much. I want the EFT to show bulk and mass. It needs to look large and in charge. Just because the KSO is mini doesn't mean the EFT needs to be a mini-me version as well.