[0.90] Kerbin Shuttle Orbiter System v4.13

[Railgunner2160]

Probably not the last iteration of the parts, but we'll just have to wait and see....

[Nazari1382]

The IVAs aren't gone TerLoki, it's just the Tug IVA that is showing some glitchyness and may need to be left out if the features won't work.

[AntiMatter001]

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.

sorry for the long qoute.

1) DLCs? already? but isn't thislike BF4? release broken game, say HEY GET THIS DLC! and get around to fixing the main bugs later? (i admit itisn'tbroken (much) but it is supposed to be in alpha/Beta)

2) i agree the memory allocation could be better... but then again they could turn right around and just yell in our faces and say KSP is not going to be about Mods all the time etc....

3)i thought you could give models and textures paths or put all the configs, .Mus and .png/.tga/etc in the same file like B9 did from 0.22... (i'm not saying you do it i'm just saying isn't this A way of doing it?) also LLL does it too with certain things.

4) why not instead of putting everything in gamedata and in your own folder put the internals into the "internals" folder...? or does that not work? (from experience i know the TT Mk3 cockpit internal can be used more than once on the same looking cockpit (like tiberdyne shuttle and the B9 Mk3 HL cockpit))

[Railgunner2160]

@AntiMatter001, IIRC the NASA missions pack they're releasing I don't think is the kind of DLC(if it can even be considered that) you pay for, it's a partnership with nasa to add a nice set of missions to then game and increase awareness of modern space programs. I can't recall reading anywhere they were planning to charge people for it.....

It pays to remember that while you've already paid for KSP you paid for early access and to help fund the development of KSP. Also your getting the game at a reduced cost compared to the final product(At least that's the way most of these early access games are being billed).......

Edit: At least it's not like the launch of Sword of the Stars 2, Paid full price for it(Preorder) The day it "Launched" it was so broken as to not be playable, wasn't really all that playable until a YEAR after the supposed "Official Launch"..........

Edited March 13, 2014 by Railgunner2160

[helldiver]

sorry for the long quote.

2) i agree the memory allocation could be better... but then again they could turn right around and just yell in our faces and say KSP is not going to be about Mods all the time etc....

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.

3)i thought you could give models and textures paths or put all the configs, .Mus and .png/.tga/etc in the same file like B9 did from 0.22... (i'm not saying you do it i'm just saying isn't this A way of doing it?) also LLL does it too with certain things.

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?

4) why not instead of putting everything in gamedata and in your own folder put the internals into the "internals" folder...? or does that not work? (from experience i know the TT Mk3 cockpit internal can be used more than once on the same looking cockpit (like tiberdyne shuttle and the B9 Mk3 HL cockpit))

See my explanation above.

Edited March 13, 2014 by helldiver

[AntiMatter001]

@AntiMatter001, IIRC the NASA missions pack they're releasing I don't think is the kind of DLC(if it can even be considered that) you pay for, it's a partnership with nasa to add a nice set of missions to then game and increase awareness of modern space programs. I can't recall reading anywhere they were planning to charge people for it.....

It pays to remember that while you've already paid for KSP you paid for early access and to help fund the development of KSP. Also your getting the game at a reduced cost compared to the final product(At least that's the way most of these early access games are being billed).......

Edit: At least it's not like the launch of Sword of the Stars 2, Paid full price for it(Preorder) The day it "Launched" it was so broken as to not be playable, wasn't really all that playable until a YEAR after the supposed "Official Launch"..........

i thinkgames are going down the drain as generations move on... most games which are sandbox or somewhat free roam are all either released early (and 1 in every 50 not completed fully) or in Beta and when the productis done (1 in every 10) are notwhat people invisioned it to be when they paid for it.

then again this is coming from a guy who still plays Quake 3 Arena.

[AntiMatter001]

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.

sorry for double post but i do get it thanks for taking some time in explaining it to me. just another lil question can'tyou use the "RescaleFactor" command on the internal or am i just talking out of my Butt again?

[CaptRobau]

@AntiMatter001, IIRC the NASA missions pack they're releasing I don't think is the kind of DLC(if it can even be considered that) you pay for, it's a partnership with nasa to add a nice set of missions to then game and increase awareness of modern space programs. I can't recall reading anywhere they were planning to charge people for it.....

It pays to remember that while you've already paid for KSP you paid for early access and to help fund the development of KSP. Also your getting the game at a reduced cost compared to the final product(At least that's the way most of these early access games are being billed).......

This needs to be emphasized. The NASA Mission Pack is not a commercial DLC. It's a free side-project they got to chance to do after talking with NASA. It'll expand the stock game, get more people looking at KSP and help NASA get the word out about what it's doing in terms of manned space exploration. It was a once-in-a-lifetime opportunity and it makes sense for them to take it.

[AntiMatter001]

This needs to be emphasized. The NASA Mission Pack is not a commercial DLC. It's a free side-project they got to chance to do after talking with NASA. It'll expand the stock game, get more people looking at KSP and help NASA get the word out about what it's doing in terms of manned space exploration. It was a once-in-a-lifetime opportunity and it makes sense for them to take it.

what about the KSP Edu thing they're doing? http://www.kerbaledu.com/

[helldiver]

Just another lil question can't you use the "RescaleFactor" command on the internal or am i just talking out of my Butt again?

The geometry of the other larger orbiter is different.

[Railgunner2160]

@AntiMatter001: That's a educational version of the KSP software they're going to make and market to schools, to teach people about the various aspects of space flight, I know that as of now the spaceplane bit is somewhat unrealistic but the rocket portion is pretty darn close.....

[Deltac]

Since this mod is so great, can we summon the devs to make some official statement on this resource (not ore in game lol) management? This really feels like something the devs should comfort us about. We need comforting!

[CaptRobau]

what about the KSP Edu thing they're doing? http://www.kerbaledu.com/

What about it? They're helping kids learn about rocket science. That's a noble thing to do. Squad might've dropped the ball in how they designed this texture thing that is plaguing mods like KSO, but something like KerbalEdu needs not to be attacked.

[Jason Cox]

Since this mod is so great, can we summon the devs to make some official statement on this resource (not ore in game lol) management?

I'm sure that even if we could somehow get a dev response that it'd just be about how they're waiting on Unity to do X so they can fix Y.

[qnistNAMEERF]

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?

I don't know the inner workings of KSP apart from what I find in their documentation, which is sketchy sometimes, and I don't know if this applies to PNG and TGA as well, but according to their version wiki, MBM textures are supposedly cleared from ram once loaded to the the gpu. According to this page, this guy claims all textures, regardless of initial format, are converted to DXT, and DXT1 or DXT5 depending on the presence of an alpha layer. I don't know if that helps, just throwing it out there. I understand how interiors are handled currently sucks on system resources, but maybe we can minimize the impact until Squad gets their S together. I'd hate to see such a great mod fail to launch. If all this is already known, then please disregard.

[helldiver]

I'm sure that even if we could somehow get a dev response that it'd just be about how they're waiting on Unity to do X so they can fix Y.

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.

What about it? They're helping kids learn about rocket science. That's a noble thing to do. Squad might've dropped the ball in how they designed this texture thing that is plaguing mods like KSO, but something like KerbalEdu needs not to be attacked.

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?

The lack of a 64-bit client has to do with Unity itself not having a stable 64-bit Windows client and has nothing to with Squad. Seeing as 64-bit would solve a lot of problems, I imagine Squad will jump on it the moment Unity gets that done.

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.

Edited March 14, 2014 by helldiver

[helldiver]

I don't know the inner workings of KSP apart from what I find in their documentation, which is sketchy sometimes, and I don't know if this applies to PNG and TGA as well, but according to their version wiki, MBM textures are supposedly cleared from ram once loaded to the the gpu. According to this page, this guy claims all textures, regardless of initial format, are converted to DXT, and DXT1 or DXT5 depending on the presence of an alpha layer. I don't know if that helps, just throwing it out there. I understand how interiors are handled currently sucks on system resources, but maybe we can minimize the impact until Squad gets their S together. I'd hate to see such a great mod fail to launch. If all this is already known, then please disregard.

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.

[Deathsoul097]

Hang on though. How does B9 do it then? It uses almost no unique texture files, they all reference the same one. Also, a .MU file contains the exact name and type (If you export the part from Unity to a .MU, and the texture is a .tga, then you can't change it to a .dds, or .mbm, etc, because it looks for Texture.ABC, not Texture.XYZ) of texture file it uses. You will have to export the texture with the KSO parts as a .dds in the first place, not change it later as it needs the correct extension too. As for making unity export as a .dds, I have no idea. I have never tried it. Sorry I can't help any more. That solar panel looks awesome BTW. Sucks that it's getting cut.

Edited March 14, 2014 by Deathsoul097

[somnambulist]

Also, a .MU file contains the exact name and type (If you export the part from Unity to a .MU, and the texture is a .tga, then you can't change it to a .dds, or .mbm, etc, because it looks for Texture.ABC, not Texture.XYZ) of texture file it uses. You will have to export the texture with the KSO parts as a .dds in the first place, not change it later as it needs the correct extension too.

Edit: the filename is baked in with the extension, but the game ignores the extension when loading.

Edited March 14, 2014 by somnambulist

[helldiver]

Hang on though. How does B9 do it then? It uses almost no unique texture files, they all reference the same one. Also, a .MU file contains the exact name and type (If you export the part from Unity to a .MU, and the texture is a .tga, then you can't change it to a .dds, or .mbm, etc, because it looks for Texture.ABC, not Texture.XYZ) of texture file it uses. You will have to export the texture with the KSO parts as a .dds in the first place, not change it later as it needs the correct extension too. As for making unity export as a .dds, I have no idea. I have never tried it. Sorry I can't help any more. That solar panel looks awesome BTW. Sucks that it's getting cut.

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.

Edited March 14, 2014 by helldiver

[Starwaster]

I'm having some trouble with what I'm hearing about how KSP handles Internals... that it does not handle them like any other part?

I'm doing some experiments here and so far it seems like it very much does.

KSP does not care what a part's folder is named or what it's internal's folder is named and doesn't look for internal.cfg, it's not aware of those files or folders.

What it looks for are config nodes.

I'm pretty much abusing the hell out of the MK1 pod internals right now. I've renamed folders, separated the model and textures from the cfg, renamed the cfg to jebs_trailer_home.cfg. All that matters is that the game can find an INTERNAL node named mk1PodCockpit

//jebs_trailer_home.cfg
INTERNAL
{
  name = mk1PodCockpit
	MODEL
	{
		model = Squad/Spaces/MK1_Assets/jebs_trailer
		scale = 1.0, 1.0, 1.0
	}
	// buncha other stuff [I]<SNIPPED!>[/I]
}

Right now I'm trying to learn what the meshes and textures are used by the MK1 pod model so I can separate them from the model (though for your purposes I don't think that's necessary?) and spread them across three folders.

Texture designation is handled in the MODEL{} node via texture = <texture name>, <texture URL path> Edit: Oops that was wrong, it's texture name not mesh name. Much simpler

But what does work right now is that I have the model and textures in one folder (Squad/Spaces/MK1_Assets/) with a model named jebs_trailer.mu as indicated in the config file excerpt above.

Edit: Just to make sure it's clear: I inserted that MODEL declaration after moving model/textures and renaming the model.

Edited March 14, 2014 by Starwaster

[Deltac]

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.

You'll have to PM B9, then wait maybe a month or so before he'll look at his PMs, then wait another month before he'll respond. I assume that's the process currently with Artyom/bac9.

[Deathsoul097]

I believe I misunderstood what you had originally said. I thought you meant that you couldn't have or work out having each part referencing a single texture file, like B9 or FusTek. Sorry.

[wasmic]

Hang on though. How does B9 do it then? It uses almost no unique texture files, they all reference the same one.

Biggest lie ever. The reason that B9 is the biggest memory hog of all KSP addons (AFAIK), is that it uses SO MANY 1024*1024 texture files. Yes, they do base multiple parts off the same textures, and all the wings share a single texture. However, there are a lot of parts that really should have used the same approach. B9 suffers from part and texture bloat, and therefore some people can't use B9 at full res, even when not running any other addons. The KSOS, in comparison, uses much less RAM, because of the texture sharing.

[Razorcane]

The reason KSP is such a memory hog is because of how it loads its data. Most game engines, including Unity, use a database system to compress and decompress data, which takes less resources. Older versions of Unity didn't have this, which is what KSP is based on. I'm not sure what version of Unity it was, but I remember Felipe saying he started the game nearly 10 years ago, so the technologies back then aren't what they are now. Of course, KSP is updated to the latest version of Unity, and they could make use of all these new features, but these features would require a re-coding of the game (the entire game if they want to make the conversion to 64-bit), which unfortunately Felipe doesn't really want to do. It's a shame, since this game could be so much better.