[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[lo-fi]

Annoying that doesn't work. The textures only load half the time with these new fangled model node things. It's starting to bug me.

[Gaalidas]

Ah ha! That'll do it, Madrias

Doh, keep forgetting to add you in as contrib. Will fix shortly.

Errr. No way I can think of to remove the arrows. They got added because I got fed up with "wheels no work" when people kept putting them upside down. Funnily enough i havent had a single issue since! How does vessel viewer deal with engine shrouds though? Does it show them?

I seem to remember using the mod a while back and it did indeed show shrouds, as well as including them in the "blown up" view (spaced the parts out based on their decouplings and whatnot). My thought is that the arrows need some form of toggle option in the editor. It would be extra awesome if the arrows would only show up if the part was in the wrong orientation, or perhaps they could only show when the part is being moved and disappear upon attachment... just brainstorming here.

- - - Updated - - -

Annoying that doesn't work. The textures only load half the time with these new fangled model node things. It's starting to bug me.

Really? I haven't had that problem, except when trying to do large numbers of texture swaps. That's where things get weird, since you have to have a dummy texture for the model to load (as specified in the model file, and referenced properly in the config) or it won't swap the texture correctly.

Currently I've moved all the KF parts into a single folder and I have them all working. This is without trying to do texture sharing of any sort, though.

Hey, cool little tidbit here. Before culling out the parts that I don't want (dev parts and such that are not finished enough for use) the KF folder (from the non-source repo) is over 400 megs of data. After being processed (local texture resizing and conversion to DDS format) I get it packed into a nice ~20 megs. Without local processing, that's a major impact on the memory there.

Edited June 16, 2015 by Gaalidas

[lo-fi]

Yeah, it wouldn't be impossible to add a toggle in the editor. Won't help kronal, though! Well, unless using an earlier version of the parts that don't have the arrows, like the early 1.8 releases.

No idea what's up with the texture loading. One load its fine, the next none of the tracks in the single folder have any textures. I tried adding texture = lines to the model nodes too, but that results in a loader crash. Incredibly frustrating!

The github stuff takes up a whole bunch of space, don't forget. Think it's about 80 with released parts? Still a very worthwhile saving with the texture sharing. Can you post an example config for the long tracks?

Edited June 16, 2015 by lo-fi

[BioRoots]

Errr. No way I can think of to remove the arrows. They got added because I got fed up with "wheels no work" when people kept putting them upside down. Funnily enough i havent had a single issue since! How does vessel viewer deal with engine shrouds though? Does it show them?

There a option to hide the shrouds can i disable the arrow in the cfg ??

[lo-fi]

No, not without an update to the models. I'll add it to the list, it'll be an easy fix for the next release

[Tyren]

Ah KF itself is causing this? i ran through several logs to find the cause of the texture fail, it almost bugged me out >„<

Well, i have a 6th clean install of KSP for testing it.

[lo-fi]

Well, not directly. The textures are tga, and after all the FUD about tga texture not loading correctly, I never saw the problem or had a single bug report. As usual with these things, the truth lies buried somewhere beneath, and it appears that the tga bug only happens when using MODEL nodes. I'll swap to png and see how it goes. DDS can do one, it looks terrible.

[smjjames]

Ah KF itself is causing this? i ran through several logs to find the cause of the texture fail, it almost bugged me out >„<

Well, i have a 6th clean install of KSP for testing it.

Huh, that explains why I'll occasionally see a broken texture with one of the KF tracks or wheels. A few days ago, the 5m truss from IR got hit by that glitch, somehow.

the basic hull from the Maritime parts mod got hit by that a few times too. Don't think its related though.

Edited June 16, 2015 by smjjames

[lo-fi]

I guess it's totally random! Very odd, and seems it's not limited to KF.

[Tyren]

Well, it doesnt happen to stock parts, so i guess its really a format issue.

[lo-fi]

They don't tend to use MODEL{} nodes...

[Tyren]

Is it even possible to avoid them in a mod?

[lo-fi]

Not if you want to share textures between parts, no.

When using one part per folder, the mesh = method works fine

[Gaalidas]

No one said texture sharing and asset folders would be easy.

My suggestion, which obviously didn't go the way I expected, was to keep all of the .cfg files in a single folder called "Parts" and for all the textures/models (gotta make sure none of the parts use the same texture name, or there will be conflicts) to go into an "Assets" folder. The config would then go like this:

MODEL
{
    model = KerbalFoundries/Assets/TrackLong
}

This is how the USI part folders are set up, and I have never had any problems loading those parts. Also, the switch from TGA is a good move. KSP never really recovered from that issue, and these days you only ever see PNG or DDS, even MBM has nearly disappeared completely.

On the node of DDS, I discovered that if your mod uses texture sharing using the "texture = oldtexturename, new path and texture name" method, which requires dummy textures to be placed in the folder where the model is (not necessary in one-folder setups) and you convert those tiny textures into DDS, something goes wrong somewhere and those tiny DDS files will fail to load properly. I've started filtering out any texture that is smaller than 64x64 and leaving them in PNG format, which has eliminated that problem. It seems that even non-texture sharing setups suffer from failed texture loads when small textures are converted like that.

Another thing to keep in mind: the texture converted utility that was made for KSP a while back uses an auto-detection method for normal maps which, in some cases, will misidentify a texture that contains a mostly-blue color-scheme. For instance, I converted my TextureReplacer fueled planetary textures to DDS and the texture for one of those near-complete ocean planets was misidentified as a normal map because of its colors. When the utility was done converting it, and bashing it into the format it feels is right for DDS normal maps (I kinda dislike it, but if it works... whatever) that planet ended up being a bright pink. Had to disable that detection method for that folder and convert the normal maps separately.

I'm remaining skeptical about the DDS conversion saving RAM, though. Sure, it makes loading the game a lot faster since it can skip loading the textures into system RAM first, then converting them, and then copying to video RAM. The thing is this: if you have mips turned on, those mip levels will make the file larger. Also, DDS images tend to have very uniform disk sizes compared to other formats that will have varying sizes based on number of colors, compression levels, dimensions, etc. Sure, in the end they're all the same in your video ram, but I'm unsure if the conversions we do on the outside are quite the same as what happens when KSP loads them. Either way, since switching to DDS and since KSP left beta, my performance has been pretty cruddy and I've been crashing a lot more often. I'm being forced to cull my mod list down a ton, which is painful in many ways. On the bright side, I likely use about 1% of those parts anyway... but still, you never know when you'll need that obscure part.

If you'd like, lo-fi, I'll commit my current setup where I have all of the non-dev parts in the folder structure that I mentioned higher up in this post, with all the textures loading perfectly fine (on my end anyway) and all the model nodes set up correctly. Just say the word and I'll work my magic.

Edited June 16, 2015 by Gaalidas

[smjjames]

The ohly ones that I've really observed to randomly break their texture are the KR ones. Not including those symmetry glitch outs.

[Tyren]

I dont have crashing issues that often. My main install runs on x64 with about 25k mm patches worth of mods. Thanks to dds. But sadly no kf there. I have several clean installs for my own modding and testing, though.

- - - Updated - - -

And no, it is no magical ubar gamer pc.

[smjjames]

I dont have crashing issues that often. My main install runs on x64 with about 25k mm patches worth of mods. Thanks to dds. But sadly no kf there. I have several clean installs for my own modding and testing, though.

- - - Updated - - -

And no, it is no magical ubar gamer pc.

Uh, are you running the 64 bit KSP or are you just saying that you have a 64bit computer?

[Gaalidas]

A good question there. Having an x64 processor and OS doesn't mean much for KSP since it runs 32-bit only right now.

Interestingly enough, there was a time back in KSP 0.23.5 when I reached well over a staggering 100k worth of patches being applied. Back in thsoe days, MM wasn't nearly as fast as it is now and it took a good 10 minutes just to patch things.

Lo-fi, I've actually finished doing that Parts/Assets conversion for all of the non-dev parts in the github repo right now. I can commit the changes and have things reorganized in a jiffy if you're interested. I'd still suggest somehow reducing the number of different textures being used, doing things like standardizing the track surface textures or something of that nature, but that can wait. I also converted everything to PNG, but left the texture dimensions alone. This means the rover body is still super annoyingly huge.

Edited June 16, 2015 by Gaalidas

[V8jester]

Uh, are you running the 64 bit KSP or are you just saying that you have a 64bit computer?

It's a hack to allow you to run 64 bit mode. I do the same thing and I'm at 50+ mods idling around 7GB of ram

64bit hack http://forum.kerbalspaceprogram.com/...ity-workaround

64bit Unfixer http://forum.kerbalspaceprogram.com/...-Total-Unfixer

[Tyren]

Nah, i said i am running KSP at x64. At.1.0.1 it was a pain in the ass, but i can force it via launcher or command line to x64 without issues. But that is as far as i can go, only a few more patches will burn that client to ashes.

I have 4 GB GRAM and 24GB free RAM for use, most of it is still idle.^^

Well i never ran a really high part count ship, due to the sheer number of more or less handy mods it never counts up over 200.

- - - Updated - - -

Anyway, for several mods like this one, electronicfox' discreet parts and CSS i have separate independent installs for testing purposes, as well as BDA.

[lo-fi]

Go for it, Gaalidas!

Interesting about the x64 stuff. Mileage seems to vary wildly

[Madrias]

Gotta admit, the rollcage does make for a good driver's seat (minimal view obstruction, reasonable gauge layout) and a half-decent seat-of-the-pants pilot seat.

Bug report: the Compass in the rollcage is upside down.

[Gaalidas]

Go for it, Gaalidas!

Interesting about the x64 stuff. Mileage seems to vary wildly

Going for it then. Here's hoping nothing obscure gets broken in the mean time.

- - - Updated - - -

Gotta admit, the rollcage does make for a good driver's seat (minimal view obstruction, reasonable gauge layout) and a half-decent seat-of-the-pants pilot seat.

Bug report: the Compass in the rollcage is upside down.

Haha. That's awesome.

EDIT: Commit complete, and synced. I've wanted to overhaul this baby for a long time, but the moment never really felt right. Another thing I'd like to do sometime is further optimize the textures, resizing a few overly-large ones for the detail levels that you'll ever see in KSP, and redoing a few normal maps, as well as introducing my darker wheel textures that I prefer to use... But I'll wait on that stuff for the time being. I still need to look into figuring out what object names to enter into the texture switcher modules to make a texture switch available on some of these parts. All optional of course... not gonna introduce any hard dependencies into anything. Anyway, all stuff I'll look into on my own time later.

Edited June 17, 2015 by Gaalidas

[Tyren]

Another question regarding particle effects: will it interfere with CollisionFX or can you have MM ignore your parts from being patched?

[lo-fi]

Awesome, I'll check that out later. Laughing about the compass too! The textures for the props no longer load into Unity (DDS), so it's hard to tell which is the right way up for some of them!

I believe Gaalidas has MM patched CollisionFX away on the KF parts, so should be no problem.