helldiver

No KSOS has never been FAR compatible, never will be. You need to post on that thread for customized configuration files. Should I put that in bold in the OP? Nothing against FAR, just that it requires customized exclusive versions of all the cfg files. Either the KSOS runs Stock or FAR, we're not doing both. We're not spending the time to balance both, we have enough issues as it is getting this to work in Stock KSP. I don't care how popular FAR or DRE is. If they become part of KSP Stock installation, then the KSOS will be 100% FAR compatible. I hope that answers that.

That is because that is Nazari's department. He handles game data and configuration. Odds are he already saw it and either a fix is under way for our next update or there may be something else. Even if we don't reply we're both watching the thread

Screenshot? I'm thinking you're still using something that is outdated (old cargo bay perhaps?). You must use the new blank provided in Alternate Textures v203. Can you give an explanation or reason why they can't be 1.25 meters? Why do you want to see them in 2.5m? If you don't mind. Placed album in OP

And hundreds of videos (including a few I've done which you didn't watch) clearly demonstrate you're wrong. Not the least of which the reason for the mod popularity is the ease of use of the shuttle. In fact that was my entire goal originally when I made it to make it easy for the average KSP user to use it. So either you didn't install it correctly, or are using some mod that's affecting it, or who knows. So either give more details of your installation if you want help, or otherwise move along and don't download this mod.

Like FREEMANtsing mentioned, the KSO in v2.03 should work with MechJeb when launching. Unfortunately the SST hates MechJeb. More Phase II testing

Thank you so much for your work on this. I'm going to be tackling RPM and the HUD Screens once I get Phase 2 out of the way. Nazari and I did various experiments and we still can't fix the issues. My original theory was that each prop had to be unique and you couldn't share props, but so far that still doesn't work. There is a bug with RPM that it forgets what background texture it uses. This was very evident with the Laptops which use the RPM. When first loading a laptop, RPM will forget its background screen so the user will see a strange rogue texture. Hitting menu or cycling the RPM pages will clear the bug. I just sent the first Phase 2 distributable which included your updated RPM Dev build to our testers to see their results. I'm still having the Blue ADI bug with your dev build I will send you a link to our latest mod build which is being tested. Keep in mind that release is very soon, so although the mod may release I plan to continue hunting down the RPM bugs post release.

Update -Minor bugs to clean up. -Testing

This is mysterious. If I recall, Antimatter said when he replaced his with the stock Hyomoto Mod, the HUD showed up just fine. Keep in mind we use the same exact settings. Only thing changed is the PNG artwork and only minimally. @Wesi29; you deleted your RPM folder found in KSO, and replaced it with the one in the download right?

Pretty much. Hence I switched those PNGs to TGAs to rule out any other possibility. We have Linux users without any problems after updating to the latest versions and we have Mac users who haven't reported problems either.

@Westi29 and @AntiMatter and anyone else running Macs that are having the HUD not showing up or is black as well as the ADI. http://www./download/rjedt1anjdd0e52/HUD_ADI_Fixes.zip Please download this hotfix and take a screenshot of your result. This is a manual install and assumes you know what you are doing: Navigate to, Kerbal Space Program/GameData/KSO/ Delete the folder RPM Extract the archive (HUD_ADI_Fixes.zip). Place the RPM folder from the archive into Kerbal Space Program/GameData/KSO thereby restoring your RPM folder. You cannot simply overwrite the RPM folder with this one, you have to delete it so that KSP uses the right textures. -Changes: -Replaced PNGs with TGAs. Will see if there are issues with the PNG format I'm using. -Changes to the ADI display to have better contrast on the ladder as well as moving the RPM information so that it doesn't sit on top of the speed and altitude tapes. Please take a screenshot of your result. Note, this will not fix the Blue ADI bug -The blue ADI bug is linked to the Orbital display and may be a bug with the RPM renderer as users have experienced it with other RPM features (outside the KSO). This bug is benign and to make it go away all you have to do is cycle the MFD to another page and then back to the ADI. -This bug is linked to using the same prop name. In the future we will export all the screens as independent props. The reason I know this, is because the bug occurs on the ADI which is really just a retextured HUD. The HUDs don't suffer from the bug because they are separate props from the six screens. Yet the six screens tend to affect one another with the bug when you turn on the orbital display and flip an adjacent screen to the ADI page. -I will try and squeeze the fix in before version 2.0 of the KSOS, but we'll see how the schedule goes.

Drag and drop these files into %/Kerbal Space Program/GameData/KSO/RPM/Ghost Essentially replacing the textures you have with this one. This also contains a CFG that puts 1% opacity into the HUDs. http://www./download/dj72ktbcawint2d/KSO_HUD_fix_2.zip Are you using an Nvidia graphics card by chance? [edit]My bad, it didn't color shift properly, try fix 2 linked above and screenshot your result.

This is not regarding the dark ADI and HUD bug (I'm aware of that one already). I'm trying to hunt down the causes. Has anyone experienced this bug? The ADI turning blue when ever you select the Orbital display on an adjacent MFD? Show of hands if anyone else is experiencing this bug specifically. @Antimatter and @Westi29, I'm already aware of the dark ADI/HUD bug and I'm experimenting with some solutions. This is just specific to the blue ADI bug.

Listening to Skrillex while we fix bugs and stomp some geometry related issues.

Update Just got the first version today in game. We've got a lot of bugs unfortunately. All of the bugs are related to RPM and the IVAs. Unfortunately a lot of the bugs are really tedious ones like getting the Kerbal cams right. Some bugs require rebaking of assets, while others require reconstruction in some places. I was hoping for an earlier release, but after checking everything today it seems it will be a while. I don't want to spam the thread since I don't want it to become a development thread. My apologies for the delays, if only you guys knew how frustrating this is. Fortunately the ISS Style large panels are working perfectly in game now (I had to reanimate them differently). The SST is still giving us issues.

Update -We got the IVA's working and they are sharing the same texture without repeating. -Nazari tried the Model method described above and it didn't work. He used a different method (don't think he wants to share his very unorthodox solution...). -Going to release with the SST's IVA, even though the needles don't work. Will look into them post release. That means that other things we promised to fix once Phase II was released will get delayed until the issues of Phase 2 get fixed... -In future phases you may start seeing some really weird and wonky stuff. Like an entire IVA being a prop or like the KSO and the KSO Super 25 being one massive super prop that is shared by various vehicles. Basically a matrix of IVAs that are moved depending on which vehicle is using them.

How does B9 do what? If he has DDS natively in his mod installation, then it'd be nice of him to PM me or Nazari on the step by step process of exporting or directing the MU files to read DDS instead of TGA. Again, I'll do some research once Phase II is out. If you mean the IVA issue, he does the same thing we're doing, except his pack has a lot less IVAs and interior spaces than this does. Also he uses the native props. I thought it was really just one IVA? He then reuses that same one or the stock game IVA's? I haven't downloaded the more recent versions of B9 Aerospace so I don't know if it includes 6+ unique IVAs for all the various command pods and internal spaces included in his pack. The KSOS has 6 Unique IVAs for the 6 parts with interior components (KSO, SST, Habitat, KerbaLab, Green Lab, Observation Module). This doesn't include the KSO Super 25 and the Moon lander's IVAs (bringing the total to 8). The plan was that they'd share textures between them with maybe one more texture added in for variety. The KSOS does not use the native props and each IVA is a unique 3D detailed object. [Edit]Don't confuse external parts with internal IVAs. The problem is the internal IVAs not the various external parts.

We'll do what ever research we can. Once Phase II is out of the way, going to see about going the DDS route as has been suggested. I'd love to compress everything into DXT5, just need someone to speak up on how they did it (I don't mean the texture mod, I mean how to set it up so our MUs can find and read .dds). I converted everything over to DDS and they all showed up white (textureless) in KSP. So if you mod authors out there know how to make a Mu read DDS instead of TGA, please speak up.

I don't believe the texture management issue or the texture preloading is a Unity problem. I'm not a programmer, but something just seems strange to me. There are a lot of games out there being done in Unity that are using way more resources than KSP uses asset-wise. Unity Showcase Gallery I've had contracts before for assets that were later converted over to Unity (from UED). These were much larger and more expansive than all phases I've done for KSO combined. KerbalEdu is mostly backend/frontend, software related plugin support. At least from what I read and saw it has nothing to do with the texture limitations and issues I discussed. Unless they plan on adding additional content in the scope of the KSOS project. Then again, barebones KSP with a DLC or two they produce would run just fine. However, they are still short-sighting themselves if they keep their current setup. Even if they keep their game without mods or mod support, eventually at the current rate it will run into memory issues. Unless they plan on keeping the feature/content set small. How long has KSP been on Early Access? A 64-bit client is not necessary to solve this issue what so ever. I'm no programmer, but even my little jinky free engine made by university students can handle 10x the resources KSP can handle, and it's not 64bit at all. Shoot, Skyrim is not even 64bit and they even have a mod manager software... yes there are so many mods for that thing they have a mod that manages your mods... By the way, a 64bit client will only Band-Aid the problem for a while. Now if it's a funding issue (funding a programmer to program KSP to handle resources differently) that's another issue entirely.

The geometry of the other larger orbiter is different.

With the way they've handled the memory thing, asset allocation, mod support (how do you import and get Skin weighted objects functioning properly?), plugin support, I don't think they have to yell in our faces, they're practically saying it already. I thought so to. Unfortunately that's all you can do. You cant specify an individual path for separate internals. In other words lets take the KSO and KSO Super 25 for example. Nazari can simply point the KSO Super 25 to internalKSO (which has the stuff from the KSO). The problem is that the MU file from the KSO and the Super 25 are different because the Super 25 is larger, the geometry of the internal is different, and shared parts and textures from Phase II (Kerbin_Station_Satellite.tga's). That means that the internal for the KSO Super 25 uses a different MU file than the internal for the KSO. Except, KSP in all its glory picks up the MU file found in internalkso that's it. We can't specify specifically which assets to use in a different model. The only way you do it, is by giving each model its own internal folder (internalkso, internalsuper25, internalhab, internalgreen, etcetera follow me?). Then you can put in each model's IVA Mu files... But then we have another problem... because we have each model with its own internal spaces folder, now we have to copy any shared textures over to that folder. See the problem? See my explanation above.

Repost of the image I posted in the KSO thread But Helldiver, can't you just break up everything into a bunch of props? -No for several reasons. I use the same production pipeline used in triple AAA titles. This makes producing all the stuff fast and efficient. Don't like that the color of the SST is yellow? In one two seconds that's fixed. Need a better Specular? Generated in a matter of minutes. By having one large object on one UVW, I can produce all the needed baking in just a few passes. -I am able to bake the lighting into the internals so it looks like everything belongs there. If things were individual props, it would take much longer to reproduce that. Additionally Nazari would have to place each prop more or less. This current method makes it much faster to do all that (a mater of days instead of weeks) and when Nazari gets it to put it in game all he has to do is assign texture, do the plugins, and export. -Had the KSO been separate props, the size of the installation would have ballooned to near double the size. By having a single texture we can compress that (using the texture compression mod) or do what ever. Individual prop textures would have actually added up to much larger than a single 2048x2048 (keep in mind that what makes the large one look good with some loss of visual clarity are the shadows baked in). Can't the KSO Super 25 (Phase III) be a separate download? -Yes, and if I muster up the enthusiasm to do it, it will be separate. However, the majority of folks are like me, they're going to want both the KSO and the KSO Super 25 (KSO for their normal service missions, Super 25 for hauling the large 2.5meter components). That means we're back to the problem at hand; i.e. copies of Cockpit_Interior.tga in KSO/Spaces/InternalKSO and KSO/Spaces/InternalKSOS25. Nazari can't simply point the Super 25 to the KSO's internalkso files because the Super 25 for being bigger has a different IVA (not that different, but enough to need its own MU file). The savings for -you- was in reusing the textures. Which has been lost do to this moronic method of handling texture data.

The problem demonstrated for all of you guys to see a bit more clearly: Q: But Helldiver, can't you just break up everything into a bunch of props? -No for several reasons. I use the same production pipeline used in triple AAA titles. This makes producing all the stuff fast and efficient. Don't like that the color of the SST is yellow? In one two seconds that's fixed. Need a better Specular? Generated in a matter of minutes. By having one large object on one UVW, I can produce all the needed baking in just a few passes. -I am able to bake the lighting into the internals so it looks like everything belongs there. If things were individual props, it would take much longer to reproduce that. Additionally Nazari would have to place each prop more or less. This current method makes it much faster to do all that (a mater of days instead of weeks) and when Nazari gets it to put it in game all he has to do is assign texture, do the plugins, and export. -Had the KSO been separate props, the size of the installation would have ballooned to near double the size. By having a single texture we can compress that (using the texture compression mod) or do what ever. Individual prop textures would have actually added up to much larger than a single 2048x2048 (keep in mind that what makes the large one look good with some loss of visual clarity are the shadows baked in).

Actually we've hit some issues and will be making some cuts unfortunately although it isn't final. The casualties are currently the Large Solar Array (ISS style solar array) and the Station Service Tug IVA. Same goes for any other IVA or objects that gives him issues. I'm seriously fed up with KSP's lack of proper Mod and texture management support. Having to copy textures that are shared by multiple objects was it for me (and yes if it weren't for Naz doing some workarounds, each station module would have had its own internals folder with copies of the same texture file), which pardon my French but is bull**** and demonstrates total lack of proper experience, design, and quality control on behalf of Squad. This needs to be priority number 1 before spending a dime on NASA inspired DLCs. If you guys would like more quality free mods made by me, you guys as a community will have to request from the Developer the following: -Textures must be able to be shared by multiple assets regardless of their designation, whether they are a prop, internal, or external. Preferably a dedicated Textures folders the way Skyrim and pretty much any Mod friendly game does it. This helps the issue of having to repeat the same texture on assets that share it. As it is right now (I've never seen an engine do such an inefficient and absurd method) each part must have its own Internals folder, and even if the same texture is shared, a copy of that texture must be in that internals folder, and a copy of that texture gets loaded into memory (I can't confirm that). That is absolutely absurd. -Texture and Asset memory management. Folks are already cutting parts and mods off. An argument could have made that all the Phases in the KSOS could have been separate. But guess what? The savings you would have received by having it separate wasn't that much since all the parts shared the same textures. However, because of the way that KSP is currently configured, you would have had to re-download and install all textures used by the other phases shared by each other anyhow. -Internals should be treated like any other object. Allow us to specify directly where the Internal geometry's textures are located. -A workaround for texture lookup could be a Unity KSP export tool that allows the modder to designate specifically the location of an object's textures. The asset will always look in those folders first and then check the default folders if it doesn't find its texture. Alternatively, KSP should use a Textures folder with a part subdirectory. Modders place textures here and point to them in their exporter. In the end these suggestions help everyone: -Squad wins because it means more quality mods out there. It makes their own asset scalability and production cheaper and efficient. -KSP owners can have more mods installed in a game lacking content. -Modders have an easier time getting their mods to work on a variety of systems. I have zero interest on further phases. That includes Phase III which includes the larger 2.5meter KSO, why? Because it shared assets from the first KSO and the other phases. Unfortunately that would mean having copies of the largest files (such as the cockpit textures) inside the internals folder of the Super 25. Same goes for the moon lander and pretty much any other IVA'ed object I create. And as you all know, my goal is primarily IVA'ed spacecraft and spacecraft components. I have very little interest in flying lugs, which sadly the SST has now become.

Love those stations and videos! We'll talk about which mods you're running, cause I really would like to change my Kerbals. I don't want the uniforms, just the faces and female Kerbals.

Just a quick update -Nazari continues to get stuff in game. Everything has been smooth so far minus a few hiccups with Solar Panels. -Nazari has used some innovative techniques to be able to get all IVAs in game without repeating interiors (saves on installation space and possibly loading). -Geometric resolution increased on the KSO's tires. I never liked the blocky 12-sided tires it had. Increased to KSP standard 18 sided. They look much better. -The old standard docking adapter has been changed to be an elbow joint compatible with the coupling parts included in KSOS Satellite (part of Phase II) -Added a coupling/decoupling adapter to the Observation Module. This part must be installed before putting the Observation Module in orbit. It allows you to more easily maneuver it with the SST into place. Once placed on your station, you can jettison it the old fashion way. -Added 6-way Octagonal coupling which unfortunately has been cut from Phase II and will be part of Phase III.