Jump to content

[1.4] SpaceY Heavy-Lifter Parts Pack v1.17.1 (2018-04-02)


Recommended Posts

3 hours ago, NecroBones said:

This is an odd case, but not impossible. When you don't have Firespitter or InterstellarFuelSwitch installed, the alternate paint jobs are disabled by turning them into "engine shrouds" that correspond to an attachment node that is a kilometer outside the VAB. If another mod interferes with this, such as defaulting all shrouds to "on" even when detached, then you might also see z-fighting. Sadly, the solution might be to simply not use the mods together.

That's a pretty kerbal way to do things.

Link to post
Share on other sites
8 hours ago, PickledTripod said:

That's a pretty kerbal way to do things.

Isn't it? Heh. :) Unfortunately it's the only way I know how to disable specific mesh objects in the model, in stock KSP. So everything has to default to that if the mesh-switching isn't available via another mod.

Link to post
Share on other sites

Some textures seem to be missing on 5m fuel tanks, specifically "Alternate", "White" and "Black" paint schemes, everything else is there and I have no other issue with mesh or texture switching from other mods that use it. I tried deleting the Module Manager cache, uninstalling and reinstalling (manually, not with CKAN.) I tried figuring out how the color switching works exactly to troubleshoot but there's so much interaction between SpaceY, SY Expanded, Color-Coded Canisters and Fuel Tanks Plus (I have all of them installed) I just can't find a lead on what's the source of the problem, I can't even tell which file is the actual texture for these paint schemes since there seems to be tons of symlinks everywhere. Send help please.

47m9ZrJ.jpg

Link to post
Share on other sites
11 hours ago, PickledTripod said:

Some textures seem to be missing on 5m fuel tanks, specifically "Alternate", "White" and "Black" paint schemes, everything else is there and I have no other issue with mesh or texture switching from other mods that use it. I tried deleting the Module Manager cache, uninstalling and reinstalling (manually, not with CKAN.) I tried figuring out how the color switching works exactly to troubleshoot but there's so much interaction between SpaceY, SY Expanded, Color-Coded Canisters and Fuel Tanks Plus (I have all of them installed) I just can't find a lead on what's the source of the problem, I can't even tell which file is the actual texture for these paint schemes since there seems to be tons of symlinks everywhere. Send help please.

 

They're not actually symlinks, just placeholders. Though symlinks could do the job if you're on Linux. ;) It's just the 5m tanks breaking? (I'm not sure what's special about those tanks, that all other reassignment seems to work) I might need to look at your log file. But basically, here's what's involved for that case:

 

The 5m tanks are using the 7m textures from Expanded for those particular paint schemes.

GameData\SpaceY-Lifters\SpaceY_ColorChange5m.cfg - Has the rules for all of the 5m tanks.

GameData\SpaceY-Lifters\Parts\FuelTanks\SYtank7m-Specular.mbm - This is the purple placeholder that you're seeing.

GameData\SpaceY-Expanded\Parts\FuelTanks\SYtank7m-Specular.dds - The actual texture provided by SpaceY Expanded.

 

For some reason the reassignment from the placeholder to the actual texture is failing. Can you double check that the DDS texture is in the right place? Worst case scenario, you could delete the placeholder MBM and copy the DDS file into there. You'll get two copies loaded into memory, but it should get your working again. (or if youre using linux, delete the MBM and then symlink the DDS). But I do want to see if we can figure out why the reassignment is failing.

Edited by NecroBones
Link to post
Share on other sites
6 hours ago, NecroBones said:

It's just the 5m tanks breaking? (I'm not sure what's special about those tanks, that all other reassignment seems to work) I might need to look at your log file.

Which log do you mean exactly? The KSP.log file in the Kerbal Space program folder? Do I need to do something special before uploading it?

In any case yes it's only the 5m tanks, including adapters and fueled nose cones. The 7m tanks that use the same texture work fine so it really is an issue with reassignment, not a missing file. One thought I had is that it might have something to do with having both Firespitter and Interstellar Fuel Switch installed at the same time, but it's unlikely since these textures were working properly last week on the same setup.

Screenshot of my GameData folder as a bonus, might help: http://i.imgur.com/9vvmi32.png

My own MM configs have nothing to do with SpaceY, it's just a fix for an offset CoM on a QuizTech cockpit and a patch to add fuel switching to the NCS Adapter. And the later uses ":NEEDS[InterstellarFuelSwitch]", not ":FOR"

(Yep, this is on Windows, 32-bit KSP. Don't ask me how. Or how often it crashes.)

Link to post
Share on other sites

Yep, if you can put the KSP.log somewhere where I can grab it (Dropbox or whatever), I'll be happy to take a look and see if I can figure out what's going on. It's strange for just one assignment to fail. Maybe it has to do with the order things are loading in, or something. We'll have to see.

 

Link to post
Share on other sites
43 minutes ago, PickledTripod said:

Here, please take a look when you have time for it: http://puu.sh/lVZYw/b1b6ce2b83.log

OK, I suspect it might be Active Texture Management's fault:

[LOG 22:26:23.188] ActiveTextureManagement: Name: SpaceY-Expanded/Parts/FuelTanks/SYtank7m-Specular
[LOG 22:26:23.189] ActiveTextureManagement: Format: DXT5
[LOG 22:26:23.189] ActiveTextureManagement: MipMaps: 11
[LOG 22:26:23.190] ActiveTextureManagement: Size: 1024x1024
[LOG 22:26:23.191] ActiveTextureManagement: Readable: False

That "Readable: False" is the part that looks suspicious to me. I have no idea why it would decide to not like certain textures. I don't see any other errors or warnings about that texture. KSP seems to load it OK, and then later ATM does its thing.

 

SpaceY, FTP, and CCC are all mods that do heavy texture sharing and so are pretty memory efficient already, but of course that also means they're the ones that use this sort of reassignment of textures. From some quick googling, it looks like it may be possible to add some overrides for ATM? I'm wondering if it's possible to add a blanket override for these mods to distribute with them. Might be worth some more research.

Link to post
Share on other sites
14 minutes ago, blowfish said:

I think that Readable: False just means that it's loaded directly into VRAM and not accessible by KSP plugins.  It shouldn't affect this.  But try removing ATM anyway, it could still be causing the issue.

 

That could be. I'm going to do some testing against ATM on my side too, but that'll be a good experiment to try over there as well.

 

EDIT: I don't have much time tonight, but I thought I'd at least fire it up once. Apparently ATM is still reported on KerbalStuff as not being 1.0.5 updated, and it's causing a bunch of textures to not load in several of the mods, to the point of KSP hanging during startup. Yuck.

 

EDIT 2: ATM's last thread OP update was in April, for KSP 1.0.

Edited by NecroBones
Link to post
Share on other sites

Oh well, just clearing and re-generating ATM's texture cache worked... I know it hasn't been updated in a while and is less necessary since most modders have moved to DDS... But it's still vital on my specific install because I still run the original Astronomer's Visual Pack Interstellar V2, for E.V.E. 1.1. Not even the unofficial port to the new EVE, because the atmospheric scattering effect isn't supported for now and is a huge part of how it looks. And Scatterer is just too much to add on top of everything else, it makes the game crash every scene change and sometime on startup. I'm not willing to part with anything else, and my Linux install is a mess and I'm too lazy to fix it, and the 64-bit workaround makes my game crash even more than Scatterer, and... Basically I'm eagerly waiting for KSP 1.1. Anyway thanks a lot.

Link to post
Share on other sites

Notice a funny thing during some aerocapture tests. Its about docking ports from your pack. Seems like 2500/2500 a bit OP, because ports survive direct entry to Kerbin atmosphere, while the standart nose cones in same situation just explodes. Some screens here: http://imgur.com/a/V9FSA.

PS Dont look at root tank - kraken cancel a magic of tweakscale, but rocket still flyeable. :rolleyes:

PPS Best solution for aerobreaking. :)

Qnv54ip.png

Edited by Carepanda
Link to post
Share on other sites
6 hours ago, PickledTripod said:

Oh well, just clearing and re-generating ATM's texture cache worked... I know it hasn't been updated in a while and is less necessary since most modders have moved to DDS... But it's still vital on my specific install because I still run the original Astronomer's Visual Pack Interstellar V2, for E.V.E. 1.1. Not even the unofficial port to the new EVE, because the atmospheric scattering effect isn't supported for now and is a huge part of how it looks. And Scatterer is just too much to add on top of everything else, it makes the game crash every scene change and sometime on startup. I'm not willing to part with anything else, and my Linux install is a mess and I'm too lazy to fix it, and the 64-bit workaround makes my game crash even more than Scatterer, and... Basically I'm eagerly waiting for KSP 1.1. Anyway thanks a lot.

 

Wow, lol. Yeah, I'm glad that's all it was. I'll probably add some more "troubleshooting" to the OP and mention ATM's cache. Since SpaceY is already very memory efficient, and ATM doesn't really help anyway since it we have DDS images, I may go ahead and add the config entries to make ATM skip SpaceY. Before I gave up for the night, I did get ATM running in my test instance (by grabbing the latest github copies), and they seemed to work OK. I noticed the cache folder, so that would have been one of the next things I'd have suggested to try. Bad cache data is always fun to deal with. ;)

 

2 hours ago, Carepanda said:

Notice a funny thing during some aerocapture tests. Its about docking ports from your pack. Seems like 2500/2500 a bit OP, because ports survive direct entry to Kerbin atmosphere, while the standart nose cones in same situation just explodes. Some screens here: http://imgur.com/a/V9FSA.

PS Dont look at root tank - kraken cancel a magic of tweakscale, but rocket still flyeable. :rolleyes:

PPS Best solution for aerobreaking. :)

Qnv54ip.png

 

LOL, I see your point. The heat tolerance is left over from before the aero updates. I'll go ahead and lower it. Socking ports should be more of a weak spot than a heat shield. :)

 

Link to post
Share on other sites

Files are still posting to the various sites as I type this, but update released:

 

1.7 (2015-12-22) - More separator goodness.
 - Added "SpaceY_ATM.cfg" with settings to attempt to disable or dissuade ActiveTextureManagement for this mod.
    - Can optionally be deleted to return to ATM defaults.
    - ATM known to occasionally have caching issues with remapped/shared textures in my mods.
    - SpaceY is already very memory efficient and uses DDS, so ATM doesn't help much for this case.
    - May need to delete ATM's cache if using ATM and some textures still aren't appearing.
 - Updated 5m stack decoupler:
    - Ejection charge reduced by half (to 400, down from 800).
    - Added built-in "sepratron" solid propellant separator motors.
    - Research cost increased slightly.
 - Added slanted variants of the sepratron nose cones.
 - Reduced maximum temperature for docking ports. Should burn up more easily now. ;)
 - Added a default custom part tab for VAB/SPH.

 

Updated 5m stack decoupler:

KSP%202015-12-22%2009-33-48-42.jpg

Link to post
Share on other sites

These texture issues between ATM and your mods that suddenly popped up for no apparent reason made me think of something: why don't you use the Expended tank texture for the main pack too? It's much higher quality, the looks fits a lot better with stock parts if you compare specularity/reflectiveness or whatever. The layout is so much better, I love how it's possible to have up to 5 different black and white paint schemes with just one image, it's perfect for anything with a black and white scheme like Saturn rockets or the old SLS design or anything NASA-like out of your imagination. And you could reduce the download size of Expanded since the texture would be part of Lifters, which is a dependency anyway.

Link to post
Share on other sites
1 hour ago, PickledTripod said:

These texture issues between ATM and your mods that suddenly popped up for no apparent reason made me think of something: why don't you use the Expended tank texture for the main pack too? It's much higher quality, the looks fits a lot better with stock parts if you compare specularity/reflectiveness or whatever. The layout is so much better, I love how it's possible to have up to 5 different black and white paint schemes with just one image, it's perfect for anything with a black and white scheme like Saturn rockets or the old SLS design or anything NASA-like out of your imagination. And you could reduce the download size of Expanded since the texture would be part of Lifters, which is a dependency anyway.

I think ATM was failing all along, but no one reported it since the placeholder textures at least had the correct colors. I was noticing in some screenshots people were posting in various threads, that some things didn't look right. Plus Kottobos did his review of Expanded without noticing that he installed it wrong. So I figured we need to shine a light on texture reassignment problems and strongly encourage people to troubleshoot it, and thus we now have magenta placeholders. :)

 

Yeah, I could always rearrange the texture loadout a bit. The thing is, I'd still need at least part of the existing Lifters 5m texture since it has the stuff in it for the rims and tank end-domes and the like. Anything else that relies on that texture would have to be reworked too. Not out of the question, of course, I'll just have to give it some thought.

 

Link to post
Share on other sites
On 12/23/2015 at 10:41 PM, PickledTripod said:

These texture issues between ATM and your mods that suddenly popped up for no apparent reason made me think of something: why don't you use the Expended tank texture for the main pack too? It's much higher quality, the looks fits a lot better with stock parts if you compare specularity/reflectiveness or whatever. The layout is so much better, I love how it's possible to have up to 5 different black and white paint schemes with just one image, it's perfect for anything with a black and white scheme like Saturn rockets or the old SLS design or anything NASA-like out of your imagination. And you could reduce the download size of Expanded since the texture would be part of Lifters, which is a dependency anyway.

 

On 12/23/2015 at 11:53 PM, NecroBones said:

Yeah, I could always rearrange the texture loadout a bit. The thing is, I'd still need at least part of the existing Lifters 5m texture since it has the stuff in it for the rims and tank end-domes and the like. Anything else that relies on that texture would have to be reworked too. Not out of the question, of course, I'll just have to give it some thought.

 

I've looked at the texture arrangement, and I think I may do exactly this. Right now the 5m tanks have two textures, since a second one was needed to cover the blue/red/grey color schemes. The first one can be cut in half though, by relying on the 7.5m texture for the black and white parts. So the net effect is that the Lifters pack will grow in size by half a texture after moving the 7.5m texture to it, and the Lifters+Expanded combo will shrink by half a texture overall. This will also permit color-changing on the 5m parts whether Expanded is installed or not. It'll take repainting the default appearance for all 5 of the 5m tanks, plus the fueled size adapter and all three fueled nose cones.

 

I was thinking of repainting those anyway since they lost a lot of the surface detail by necessity with how it was laid out.

Link to post
Share on other sites
On 14/12/2015 at 11:42 PM, PickledTripod said:

Some textures seem to be missing on 5m fuel tanks, specifically "Alternate", "White" and "Black" paint schemes, everything else is there and I have no other issue with mesh or texture switching from other mods that use it. I tried deleting the Module Manager cache, uninstalling and reinstalling (manually, not with CKAN.) I tried figuring out how the color switching works exactly to troubleshoot but there's so much interaction between SpaceY, SY Expanded, Color-Coded Canisters and Fuel Tanks Plus (I have all of them installed) I just can't find a lead on what's the source of the problem, I can't even tell which file is the actual texture for these paint schemes since there seems to be tons of symlinks everywhere. Send help please.

47m9ZrJ.jpg

I have the same problem, even with more objets.

How i can fix it ?

Edited by Gotcha
Link to post
Share on other sites
30 minutes ago, Gotcha said:

I have the same problem, even with more objets.

How i can fix it ?

Troubleshooting steps are on the first post in the thread. Chances are you're using ActiveTextureManagement and its cache is hosed up. Try deleting both the ModuleManager.ConfigCache file and the cache for ATM. Assuming you're using ATM, ideally at this point you should stop using it, and get Dynamic Texture Loader instead (made by the same person, and ATM is out of date and a bit superfluous now).

-------------------------

Unrelated to above,

Repaint progress:

KSP%202015-12-27%2018-35-20-74.jpg

Edited by NecroBones
Link to post
Share on other sites

Would it be possible to make a RealFuels config for the SpaceY & SpaceY Expanded engines/tanks? Engine Ignitor is defunct and RealFuels has taken over its capabilities.

 

And do you know if Lithobrake's parachutes work with RealChute?

Edited by Jodo42
Link to post
Share on other sites

Hey there @NecroBones, I really like this pack, it's a lot of fun, (even if I don't often get that high up the tech tree ><).

I wanted to write in a possible bug/typo in the cfg file I found: In SpaceY-Lifters/Parts/ThrustPlates/SYplate3m1mX7.cfg, the node_stack_bottom03 definition is missing a space between the node and the "=". I don't know if this will actually cause a problem, although I suspect so... i've never seen it done elsewhere. (Don't ask how I found this, it's a long story ><)

Thanks!

Link to post
Share on other sites

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...