Gaalidas

That's one beautiful looking craft.

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.

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.

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

That's awesomely hilarious. I remember making a mistake like that months ago. Speaking of single folder mistakes, I tried to merge all of the KF part folders into one a while back but I left the "mesh" parameters alone without converting to "model" nodes. It turns out, KSP doesn't like that. Instead of loading the meshes specified, I ended up with 10 parts all using the APU model. Needless to say, there were many errors in the log that day.

Worried, but not overly so.

So yeah, it's actually extremely similar to what CollisionFX throws up, but CollisionFX at this time tries to disable itself on wheels because it can't detect if we're supposed to be colliding or not, as is the case with wheels and such, and so it also throws up sparks. I began, about 6 months ago, attempting to adapt the dust portion of that mod for use as an effect which would simulate the dust that gets thrown up, especially by either fast-moving or very large wheels over surfaces that are not completely stable. That part was a complete success, but I decided that I would merge it with the work I was doing on KF in order to make sue of some special features that are unique to kF wheel modules. For a good example of what it should look like, simply watch a video that features a large truck moving at high speed over an unpaved surface. You'll get the idea. Lo-fi... There is really no chance of us committing at the same time because, you see, I do not have permission to commit to the KF_plugin github. Anyway, the separate modules were really only a temporary thing that I intended to re-merge at a later date. The issue I still have that keeps me from merging them is that I need to know if we're dealing with a repulsor or not so that I can force the dust to be thrown up at a much lower scrape speed than with the other parts. A repulsor field would not only push the repulsor part upwards, but also exert some forces on the surfaces in which the field is reacting. This would, in theory, throw up a small amount of dust even when the craft is stationary. I added the appliedRideHeight to the equations and lowered the default value of the field-variable which controls the minimum magnitude in which to call the scape method. Either way, I'm perfectly happy deferring to your work on the Dust. I'm just trying things on my own because I can. my only interest in uploading anything is in fixing anything you might break, or fixing up the format of the code itself, which I'm rather obsessive about, and implementing the documentation aspects. Speaking of which, I fixed a few typos and such in other areas of your code where you'd added XML documentation. Awaiting permission to commit. - - - Updated - - - The particle effects used in the DustFX portion of the mod are really just manipulations of the stock particles that come with KSP, which in turn are likely part of stock Unity. In reality, dependencies are not something you can avoid. The part we want to avoid is having a separate mod as a dependency. That's one reason why I didn't attempt to make a mod-mod (a mod that mods another mod... confusing eh?) for CollisionFX which would have simply used CollisionFX but injected different parameters into it for use on these wheels. By integrating the useful parts of the code directly, we eliminate CollisionFX as a dependency. I'm unsure if the correct word is "epic" though. Definitely nice certainly.

On the DustFX layer, I've been experimenting on the min/maxSize parameters and have done some modifications to a few of the equations that I'll merge in soon. Right now, I'm trying to solve the over-water effect part. I am unsure how I could detect if the repulsor is repulsing from it's water collider, but in the meantime I was trying to simply find out if the active vessel is currently in a splashed state. That is assuming it would actually report such a state when hitting the water colliders at all. I'm pretty much swinging at the air and hoping to hit something. Unfortunately I had to scrap that method due to a headache that formed when trying to determine what the current vessel is so that I could check its info, and discovered I was going in circles with definitions of different parts of that entire "Vessel" method in the attempt to find something useful. Irritating! - - - Updated - - - I thought the tracks were simply really tiny. - - - Updated - - - For the record, I didn't do it. I don't even like CKAN. - - - Updated - - - Dangit. If your "break" is in the code on the repo, I'll take a look and see if I can figure that out. EDIT: I can confirm it works, and I tried to update my code with what I've done recently but... it seems I don't have permission to do that. Care to comment?

I remember a rover I built long ago that had that problem with the medium wheels, and I was experiencing something similar recently with the medium wheels when transitioning from the runway to the planet surface. I'm not convinced it's KF that's doing it though. Sometimes, when running in less than high-quality planet details, the interaction between the ground and the wheels can become distorted and even "sticky" which has led to an entire rover being ripped to tiny pieces. That was a sad day, but what was left of the rover still made it back to KSC somewhat intact.

I see this mention in the notes about an "Animated Decouplers" thingie... except I can find nothing when searching for that on either of the two common mod release sites, nor on these forums.

Hey, you're the one who made it happen, so don't blame me if your computer starts begging for death. Anyway, I have enough performance issues for a whole army, and I've still managed to get away with rovers sporting over 20 wheels or wheel-colliders on each side without performance becoming a huge issue. Compared with a smkoescreen-style emission, in which I can get a near-crash when emitting a single effect, well... the possibility of this creating a huge problem is pretty small. With that said... I have no idea what a "GO" is nor how I would ever scale it. I'm sure it's possible and all, I just haven't found that magic little code snippet. I'd actually like to find out if there are other, possibly more appropriate, effects that I could use. Right now it's just using a light smoke effect. Would sure be nice if I could preview effects like that without loading them into the game. I'm really missing the super-easy NIF model format that's used in Bethesda games. It sure made effect modding easy. EDIT: I discovered the min/maxSize properties of the particle emitter. Going to do some testing tomorrow and see what kind of effect they have. I'm also experimenting with a "grow" parameter in the color animation part. supposedly is handles a grow rate over the lifetime of the color animation, which is set up by the array of colors which, in DustFX, is the same for all the frames we populate it with. Without a clear idea of how much they will grow/shrink (I'm experimenting with entering a negative number, hoping it will shrink over time), it'll take some experimentation. Knowing what KSP sets for the default values of these parameters when not set would sure be nice.

Alright then, back to the drawing board. I've also been digging a bit into cameras for the idea of sampling the texture color under the collider. Not much luck there, unfortunately. There's lots of stuff about the cameras themselves, but no one really uses a camera without making it visible to the user, and there's even less information about the possibility of sampling the colors from a camera. Besides all that, we'd need a way to gather the average color of the texture we're looking at and emit that, otherwise we'd get dust that's changing color constantly due to the textures not being solid colors. I also got a chance to finally test out the emitter variables using GUI sliders, and discovered that I can control the apparent thickness of the particle with the "energy" parameter instead of relying on an alpha level, but it looks like the "emission" parameter really doesn't do much. I found that moving it to zero, of course, turned off the effect, but anything above zero had the same appearance. There doesn't appear to be any sort of scale parameter that I can find... yet... so there's not much chance of being able to make the effect bigger for things like the mole tracks, but that should be easily worked around now that we can emit from all of the colliders in a multi-collider set.

My question was specific to the KF source. The next release of the KF package will include dust effect emitters for the wheels and repulsors, which also means I'll need some way of detecting water repulsion so that the "dust" can be made liquid-ish.... ish... - - - Updated - - - Yeah, I was just having some trouble figuring out when it's all active or not. Would you be opposed to me adding an "isActive" boolean that I can call up in the repulsor dustFX module? I don't see any easier ways to do it. EDIT: On second thought... I can't even see where, anywhere in your code, you're checking if the collider is even necessary. Are those things always running the water colliders when active, and not just when over water? That would sure put small monkey wrench into my proverbial fan.

Hey, lo-fi, do we have any easy way to find out if the water repulsion is active or not? In the current dust system, the water biome exists, but the scraping with the ground would only work if I was scraping the bottom (aka. the landscape below the water). My idea to get around this is to send it a fake collision state when the water slider is active, but I can't find any sort of boolean to grab.

Ah ha. That reminds me, I made a KF category for Filter Extensions that I should share sometime.

Nope, didn't miss that you were going to do that, but I don't have access (or don't know where to go) to the new repo. Part grouping? I'm lost...

So, I noticed you removed the source from github. Are there plans to enable my access to the new location for said source?

I'm trying to remember the movie... the name is not coming up. I hate my memory sometimes. Anyway, it features a guy who is upset because his co-workers keep stealing his staplers. He refuses to accept that he's been fired, and so they just move him into a basement room and tell him he's being "upgraded" all the whole he keeps muttering about his stolen staplers. I have this fleeting memory of the entire building being burnt to the ground later on in the movie, and I think it also features some guys trying to get rich by shaving off fractions of a penny from all the transactions being handled by their company's server farm all the whole not ending up in prison. It's been a while, but what I can remember was that it was hilariously awesome. - - - Updated - - - My words, literally, upon seeing that were "holy craaaaaaaaa...." and I think I sat there with my mouth open for at least 3 seconds before recovering. That is exactly what we need. Still gonna be a beast to figure out how to get KSP to accept that it's not as huge as it seems when retracted, but visually that thing is awesome.

possibly even .23.5 or earlier. I've never known it to do anything different.

Yeah, it's not well documented, but if certain parameters in the scaletype definition are missing or using an old format, the scale implementation for that part completely breaks. I suspect that a few default values for the parameters in the DLL would fix that issue, or at the very least a "final" layer MM patch to apply default values to scaletypes that lack a definition for that parameter would do the trick. It's not my problem right now though and, try as I might, the developers in that thread are really slow to investigate and fix problems like that. It probably stems from a feeling of "and who do you think you are telling this awesome individual how to code his successful plugin that is beautiful and smells sweetly." It's a "battle of the lost staplers" event waiting to happen. By the way, you do get the reference in there don't you? So, I was looking at a few misbehaving mods in ILSpy today to see what's going on in their code and, as usually happens when I'm doing this, I started browsing through other mods. I came across this little beauty in a mod that implements suspension-based auto-balancing for landing legs (not the best implementation due to it relying on the length of the suspension instead of creating a leg with multiple joints which can adjust itself further than the main spring-suspension of the foot, but it's the best we've got so far.) From what I can tell, it uses a stock method that allows the part to update it's drag cubes. I immediately thought of the problem we've been having with tracks appearing to be inside a fairing, but burning up as if they were not, and my idea about a dummy retraction state for the wheels that would mimic a "shielded" state on the part and, as a side effect, pull all the suspension into a tight "fully retracted" position for easy fitting. I'm sure you've probably seen this already, but in case you haven't, it might be an interesting place to start. If not, it's just one of my uneducated discoveries that I felt like sharing. Anyway, the method I'm going to post below is a custom method in the mod called "AutoBalancingLandingLeg" (at least, it lacks and spaces or dashes in the code decompiler): [COLOR=#0000ff][B]private[/B][/COLOR] [COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]setDragCube[/B][/COLOR]([COLOR=#ff0000][B]float[/B][/COLOR] [B]value[/B]) { [B]base[/B].part.DragCubes.[COLOR=#191970][B]SetCubeWeight[/B][/COLOR]([COLOR=#0000ff]"DEPLOYED"[/COLOR], [COLOR=#00008b]1[/COLOR]f - [B]value[/B]); [B]base[/B].part.DragCubes.[COLOR=#191970][B]SetCubeWeight[/B][/COLOR]([COLOR=#0000ff]"RETRACTED"[/COLOR], [B]value[/B]); } It could be of interest to check it out. the "SetCobeWeight" method is found in "Assembly-CSharp.dll -> DragCubeList" Of course, it goes without saying that you'd probably have to look into some custom drag cubes for your parts... but that's another story altogether. - - - Updated - - - To chime in on this one, a bit late as it is, you should always expect that something unexpected will happen. That's why it's unexpected... y'know... cause you don't expect it... except that you should be expecting it... I'm not making any sense now... -explodes- Anyway, I'm curious as to how you can drop a craft, with these parts on them and at orbital velocity, and still be able to do anything with them at all? I understand the parts themselves will probably be intact to a certain degree if they are really that hard to damage, but the rest of your craft is going to be trying to reconcile their existence at the atomic level... and failing miserably. If you've managed to do this, in practice, I would love to see how you did it.

There are ways to automate those things. I'll look for an example when I get back to my computer. - - - Updated - - - by the way, tweakscale is behaving again with my revised scaletypes. You'd better update it for your install to make sure it still works for you. I'll be looking into reducing the exponent sets after some testing and further integration with tweakscalecorrector.

Still, a version display of some sort would be helpful. I personally don't keep any ".version" files, but it would help in debugging.

Yes, we know we are awesome. It's an awesome way of existing. - - - Updated - - - Uh oh... I both hate it and love it when lo-fi says something along those lines.

I suppose, without the internal, creating a scaletype with three scale factors that are all identical to the default scale, and creating an explicit exponent modifier for it, might work. However, I'm unsure of the exponent modifier system can set exact numbers like that. I also do not think TweakScale can modify strings in that way. I would probably look into grabbing the source for one of the fuel switchers and trying to rewrite the code to handle crew capacities instead of fuel.

That sounds rather... violent. At least copy the sources you intend to rip apart first. I've kinda grown fond of those files. I mean, considering what I started with, getting this far is quite the accomplishment as it is. Well, it would be if it wasn't for the fact that I actually didn't write any of it on my own. Okay, fine... rip it up... lets see what makes this thing tick... and then make it scream! I disturb myself sometimes.