Jump to content

[1.0.5] FASA 5.44


frizzank

Recommended Posts

Hey Frizzank, I've noticed that many of the part folders contain duplicate textures that are named the same, but in a different format - that is, most textures exist in both .tga versions and .png versions. Do your parts actually use both versions? In that case, it's a waste of RAM. If your parts don't use both versions, it's still a waste of RAM to include both textures. I'd just remove them myself, but I don't know which parts use which textures.

Link to comment
Share on other sites

Hey Frizzank, I've noticed that many of the part folders contain duplicate textures that are named the same, but in a different format - that is, most textures exist in both .tga versions and .png versions. Do your parts actually use both versions? In that case, it's a waste of RAM. If your parts don't use both versions, it's still a waste of RAM to include both textures. I'd just remove them myself, but I don't know which parts use which textures.

Its a bug, TGA's have better mip mapping but a larger size on disk. So I converted some of them to TGA's to fix visual bugs.

Link to comment
Share on other sites

Clamps...

Mercury now has a proper launch clamp. Downside is because its a bottom attach node it auto adds a fairing to other engines. Im ok with it, it looks kind of cool in most cases. I do wish there was a tweakable to turn it off or something.

lH1nJAI.jpg

QzMPgDZ.jpg

CPLr09n.jpg

SjsML0F.jpg

RxonBAW.jpg

Link to comment
Share on other sites

Clamps...

Mercury now has a proper launch clamp. Downside is because its a bottom attach node it auto adds a fairing to other engines. Im ok with it, it looks kind of cool in most cases. I do wish there was a tweakable to turn it off or something.

http://i.imgur.com/lH1nJAI.jpg

http://i.imgur.com/QzMPgDZ.jpg

http://i.imgur.com/CPLr09n.jpg

http://i.imgur.com/SjsML0F.jpg

http://i.imgur.com/RxonBAW.jpg

I think I remember seeing a few mods with engines modded to not have fairings, don't know how it was done but could be useful in this case.

Otherwise its awesome!!!

Link to comment
Share on other sites

Its a bug, TGA's have better mip mapping but a larger size on disk. So I converted some of them to TGA's to fix visual bugs.

But the png's are still included in the download, so both the png's and the tga's get loaded, thus bloating the RAM use.

Link to comment
Share on other sites

If you are having Ram issues, one thing that helped me. is the memory reduction mod... there is one configed to work with FASA, and it seems to work well, I was crashing severl times a day, but I started usesing it yesterday and have not had a single crash to desk top...

And I dont know if I told you this fazzak but you are 110% awsom :D

Link to comment
Share on other sites

If you are having Ram issues, one thing that helped me. is the memory reduction mod... there is one configed to work with FASA, and it seems to work well, I was crashing severl times a day, but I started usesing it yesterday and have not had a single crash to desk top

I do use the active memory reduction mod, but I prefer to keep a large safety margin, and the png's are currently just using up RAM for no reason at all - if I understood Frizzank correctly, they aren't used in any parts and could just as well be removed.

Link to comment
Share on other sites

I do use the active memory reduction mod, but I prefer to keep a large safety margin, and the png's are currently just using up RAM for no reason at all - if I understood Frizzank correctly, they aren't used in any parts and could just as well be removed.

Redundantly-named textures can safely be removed. I've done that myself, along with converting PNG to TGA so they mipmap properly. Based on how KSP appears to treat textures, it doesn't matter what the format of the texture is in the model file - as long as the file is a loadable image, and it is in the right directory, it'll be used on the model.

Link to comment
Share on other sites

Redundantly-named textures can safely be removed. I've done that myself, along with converting PNG to TGA so they mipmap properly. Based on how KSP appears to treat textures, it doesn't matter what the format of the texture is in the model file - as long as the file is a loadable image, and it is in the right directory, it'll be used on the model.

Oh, so it doesn't matter whether I remove the png or the tga? That's nice to know. Now, if I could just get my paint.net to NOT turn all images either all white, all black or monochrome, I'd be happy. Or maybe I should just get GIMP.

Link to comment
Share on other sites

But the png's are still included in the download, so both the png's and the tga's get loaded, thus bloating the RAM use.

Yes I was saying it is a bug they should not be in there, and I need to fix it. Just giving a reason of how and why they were there....

You can replace texture types (Different extensions) with other types and it still works. It only looks at the first part of the file name, that is how the texture reduction mod works.

The game reads the .cfg and then loads in the model and texture data from the .cfg. So duplicate textures would not have any ram overhead since its only loading the first one. You could in theory load in 47 super high resolution textures and put them in your GameData folder but without a .cfg to tell them to load it would just ignore them.

You can double check this by looking through your ksp.log file and seeing that it is only loading the first one.

Link to comment
Share on other sites

This would be cool but anyone that had something below the gantry on there rocket would see it ripped off on disconnect.

I know there were several versions of towers and walkways but i'm going to do a retracting one and make it sort of look like the Saturn IB one in style.

I only have time to make one, and I like the way this one looks. I could make a perfect replica of a historic launch tower but it would be completely static and only good for a specific rocket. The launch clamps have some weird restrictions on how they are built, and I would like people to use for more than one specific pre-made vehicle. The mesh and texture for the tower have to be square. The mesh stretches and the texture is tiled as it goes up, and this launch complex would work well for that.

I do however plan to make swing arms for fuel and electricity so you could if you wanted to load a completely empty rocket on the pad and fill it up with fuel, Kerbals and whatnot.

Aha. I did a little research, for the record, and you might be able to do both Gemini and LC34/37 Saturn I/IB-style LUTs with minimal work. The one that swung down at the base was the "white room" gantry for Gemini; it, like the Mercury white room, clamshelled around the entire capsule, but whereas the Redstone and Atlas gantries for them rolled back on rails (pulled by a bulldozer, no less!), the Titan II version was hinged at the bottom as described.

Redstone and Atlas didn't actually use launch umbilical towers--because they were essentially single-stage boosters, they could get all their umbilicals through the booster's tail. The only exception was a simple hinged pole mast next to the Redstone that carried an external power line to the Mercury capsule, allowed to free-fall away from it on launch (I believe Atlas had a wiring tunnel to keep the Mercury batteries charged).

The basic LUT structure for both the Saturn I family and the Titan II looked very similar to what you have; the big difference is that the Saturn LUT used swingarms (which swung in both directions(!) at launch), while the Titan II used simple hose and cable connections with no supporting arms to them. (In fact, if you look at photos of the Gemini 10 launch, you can see that one of their upper stage umbilicals failed to disconnect from the booster, and instead ripped clean off the LUT, as designed to allow a clean launch in the event of a disconnect failure.) Maybe you could make a "hoses only" version of the LUT for Titan-based vehicles?

Also, if you do make a Saturn V-type LUT, it'd be awesome if you offered two sets of launch clamps, one just the standard clamps used for the Saturn V, and one simulating the "milking stool" structure added to Mobile Launcher 1 in the early 70s to allow the Saturn IBs used for Skylab and Apollo-Soyuz to launch from LC39 instead of having to reactivate the mothballed LC34 or LC37. (Basically, it was a similar structure to the LUT gantry that sat atop the Mobile Launcher's platform, supporting a work deck and holddown clamps high enough above the platform's deck to use the existing White Room, Service Module, and S-IVB swingarms on the LUT with the shorter booster; it was permanently mounted to ML1, and the S-IC swingarms removed, while the S-II swingarms were modified and repositioned to support the S-IB first stage.) That's not really *critical*, of course, but it'd be a cool thing if you ended up having the time to do it...

Link to comment
Share on other sites

I have found and interesting bug in ksp. I am using a node_attach_top to hook up rockets to a launch clamp from the bottom. Sometimes on load the rocket jumps to some other position from a few centimeters to almost a meter and then locks in position. This doesn't work so well with large rockets and the new launch tower because it flexes in the middle. The fix is to put stock launch clamps on the sides and it reduces the problem but then your still stuck with the old clamps.

Also found out that increasing the mass of the part increases the strengths of the joint but also reduces its flexibility. Putting the mass too low and it wobbles around like a slinky, to high and it vibrates like an electric tooth brush at a cavity convention. Both situations are bad for the new launch tower, but I have a solution.

The umbilicals I am making will function like the stock struts as well so they should help stabilize larger rockets. Also Im going to put these radial, surface attached clamps in.

The yellow guys at the bottom.

agenap14.jpg

Link to comment
Share on other sites

The game reads the .cfg and then loads in the model and texture data from the .cfg. So duplicate textures would not have any ram overhead since its only loading the first one. You could in theory load in 47 super high resolution textures and put them in your GameData folder but without a .cfg to tell them to load it would just ignore them.

You can double check this by looking through your ksp.log file and seeing that it is only loading the first one.

That's...not true. The mention in the log is about *using* the texture for the part, not *loading* it (if you were right, mods like Visual Enhancements wouldn't work at all). *All* images in GameData will be loaded, with the exception of anything in a PluginData folder (also true for mus, cfgs, etc.)

Link to comment
Share on other sites

Is this latest update compatible with RO? I'm having issues with scaling in RO but i'm not sure if it's the mod itself, or the rescale configs.

I don't have anything to do with that other than permission to use my models. NathanKell is setting up the files for it but other than that im at a loss.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...