Gaalidas

I was thinking, while reading the first post, that these "rocks" could possibly be scraped up from the planetary surface using something like lo-fi's bulldozer. I don't believe it was ever released anywhere, but it was basically large bulldozer surface that, when scraping along the ground, spawned miniature potato-roids in front of it.

Sorry about that, I'm the reason for that. SharpDevelop said it would work perfectly, but I guess it was wrong. I actually intended to simply suppress that suggestion instead of committing it. Maybe it's time to see if SharpDevelop has been updated again... In other news, the first pass of updating the assets to DDS has been committed. Give them a try lo-fi, see what you think. The rover body has mips on it, since the texture is so huge, though I think it also got cut by 50% of it's total dimensions in the process as well. I was actually thinking about it while trying to go to sleep last night and thought that maybe a smaller texture that makes use of a more brushed metal look for the main hull of the rover body might be a better look for it, cause right now if you resize the texture down to reasonable dimensions some of those small lines disappear and the diagonals become aliased. A few of the normals were left in PNG format because the DXT5nm format also reduces the detail to the image along with the vertical flipping and the color bashing into that pinkish normal map.

This is indeed a nice fix for such things, even considering I've never had this problem with rockets before. Now, I have had this issue with runway craft that needed launch stability before, which is rather annoying. With that in mind, I'd probably have made this into an optional toggle on the part itself, or made a separate clamp that featured this. But... this is a good quick fix as it is.

Well, then... by all means, impress us.

I see it a lot, but never bothered to figure out what it meant. You'd likely be amused to find out how long it took me to figure out what "brb" meant back in the days when that three letter shorthand made its first appearances. From what I remember, I spent at least two weeks trying to figure it out before I finally asked someone. On top of that... when they told me what it meant I thought they were telling me, literally, that they would "be right back" and would explain it to me when they returned. Great Jebediah... I'm getting old... that was a long time ago.

Depends, how long have you been away?

Good to know. So now, when we have something that we're working on and is still in the testing phase, we can put a bunch of the log calls into a separate log file and get all the information we want, even if it's a spammed message or something, without cluttering up the standard KSP console log. That could definitely expedite finding information about something that's getting really screwy. I might even think that anything logged under "debug" (as in KFLog.Debug, or however you're calling it) could be defaulted to go into the separate file and could probably omit the mod name from the formatting. In fact, anything going to KF.log could leave out the mod name completely. Anyway, you take care of your hard drive and we'll talk about enhancing this stuff later. For now it works well enough to leave it alone until we release 1.9. - - - Updated - - - I think you mean to use "guiActive = true" so that it shows up in the flight scene, right? Also, it's starting to drive me nuts. What does "TL;DR" refer to? As for brake lights, I used to love setting up those tiny B9 surface lights to a red hue and mapping their toggle state to the "brake" instead of the "lights" group they default to. Works amazingly well.

Actually, I have yet to really test out that. Nothing's been changed as far as those are concerned, unless those model updates that lo-fi has been doing to fix the arrow showing up in the icon are making the icons get larger. On that note, I've been meaning to ask you how the heck you managed to get a node to respond from the part file like that without having to define it as a module. As far as I was aware, before seeing this, unless it was a module definition the node/parameter had to be a part of the "PART" list of supported parameters/nodes, otherwise it would bug out on you. - - - Updated - - - What kind of code was that? Also, quick question for you, in the case where the log call is intended to go to the separate file (should not default to that, by the way) where is that log file going to be placed?

I'll include my modified normals with the rest of the textures if you don't mind. I've been using them in-game for a while not without issue. I'll also include a few alternate textures I created however, without enough knowledge about what object names to use for the FS texture switcher, I was unable to set them up for use properly. Mostly they consist of darker versions of certain things. What's wrong with the part icon fix, Aqua? I didn't see anything messed up there. - - - Updated - - - The repulsor wheels never really made it out of dev status as far as I'm aware. I always envisioned an advanced set of animations where a thinner, but larger, wheel would turn in place, a series of curved panels would wrap over the tires, the entire wheel would then be pushed outward slightly, and then the repulsor plate would descend from the center of the wheel and begin doing its thing. But, that's beyond my ability at this time.

Needs a transparent pod setup, even if the IVA is a simple dummy IVA. Otherwise, not bad. Oh, and the wheels could be attached in the correct places so they're not floating. In the upcoming Kerbal Foundries 1.9 beta release, I've included an MM patch that not only converts all the stock wheels to the new modules, but also adds stack nodes to all the wheels for more precise attachment. If you add stack nodes to the correct positions, the wheels can then be snapped into position properly. Something to think about for the future.

If the outside of the window is blue colored, what do you expect to see from the inside? Blue of course.

Crud, you're messing with my logging utils? That class name was a feature you know, and if you didn't specify a class name it would simply not include it. Everything was optional. Though, to be fair, I was considering scrapping them since lo-fi doesn't use them at all and they're a pain to set up all the time. I really wish it was easier to simply set them up so we could call them from any of the other class in the project the same way you use the simple "print" method. Oh well. Also, I never really got the main planned feature of the utils created, which would have allowed for any log entry being sent to the console to be put in a separate log that could b e put either in KerbalFoundries\Logs, the root directory of the mod, or in KSP_Dir\Logs like I've seen some mods do. I got too busy with DustFX to finish the logging system.

Hmm... so sorta like the surface tracks except a thinner profile, a wheel instead of a track, and a slight compressional suspension in the arms. - - - Updated - - - Well, to be fair, I don't believe 1.8 had the TT tracks or those BV tracks you've got in the assets right now. Another thing to bring up: are you interested in getting all the textures converted to DDS? I have a reliable way to produce non-mipped DDS files from the originals so you don't get the blurry effect when you have half-sized textures enabled in the KSP settings. I would probably keep the rover body texture/normal mipped since it's so freakishly huge though. I also noticed a few of the normal maps do not match the diffuse for the track surfaces and have been using Gimp to re-map them based on the geometry of the diffuse texture. Unfortunately the conversion to DDS, which includes a vertical flip, seems to eliminate some of the details so I tend to leave them in PNG format. Still fiddling with using a manual conversion to DDS to keep the details fresh. Either way, I can try to update github with the textures converted over if you're open to it.

Theoretically it should be possible to even make a tweakable slider, even a set of sliders, to modify how the struts work which could include maximum length. However, in my experience, the struts seem to have near unlimited length compared to the maximum side of a craft in the editor areas. I've never had an issue where a quantum couldn't connect to a part no matter what length. What I could wish for would be a more precise way to connect the quantum, similar to how standard struts are connected. Sometimes getting the right angle for the strut origin can be a major pain. I guess I'll have to do some code digging again. I never did look at the quantum source.

actually, there is one more undocumented issue to deal with. We've done a number of updates to how DustFX functions, but I don't believe the repulsor version of the module has been updated to match. We need to either update that module to match the changes to the rest of the dust system, or finally merge the two back into a single module. As for 1.9 not feeling much different... it really isn't a whole lot different other than DustFX and our global configuration system. This is more of a functionality update, and less of a content one. that reminds me, better add to the patch notes that a complete reinstall of the mod is required, not just a copy-over, since we've changed the entire directory structure.

I doubt it's anything to do with TS itself. Probably a bug in the various new stuff we've done lately.

I'm not even sure "wrote" is the correct way to say it. I basically copied another config and renamed a few things. I've had it for quite some time too, just never got around to sharing.

Already did. the "Filter Extentions" config is in the "Parts" folder, and the two icons for it are in the "Assets" folder. I did the research and discovered that I don't need to give the entire icon path to the config as long as KSP loads it up as a completely unique texture, which I believe that are right now. This allows us to distribute it within uor own folder without needing to supply a "Filter Extentions" folder in our release package. The parts themselves are categorized in the same way that KSP does that itself: by the category assignment. The category for KF will be a stand alone category (that is, not within the manufacturer category only, though it is in there.) and will contain subcategories mimicking the stock categories. To split the parts up further, you simply need to decide what kind of part they are and set the part configs up accordingly. I am unsure if there is an easy way for me to add a completely new category, or split the parts up further than stock category assignments, but I'll look into it if required. EDITS: Icon Scales... That's promising. However, I'd be curious as to how that will work alongside the icon fixer mod, if the end user has that too. Also, I'm unsure if it actually fixed it, but I was pretty sure the scale visualizer was working right under PartIconFixer... can anyone confirm this? If so, it should be possible for us to fix it as well. It just seems like we are reinventing the wheel (okay, lo-fi already did that, granted) by implementing it ourselves and, considering PartIconFixer doesn't even need an entry in the part configs, it feels like a step backwards. If the two mods start to conflict, then we'll at least need to do some reflection work to make sure that the offending mod does not interfere. I'm going to reiterate this as I think it got missed due to posts after my last edit... Just something to consider. - - - Updated - - - I'm unsure if the place for that is in the persistence manager, since that was supposed to house save and load routines, wasn't it? I'd have made a new class to handle part icons.

Think we're ready to do a thread in the release board for this next update? I also wonder how large a specific thread should be before we try to lock it down and start a fresh thread for the dev stuff.

I wanted to weigh in on this. Yeah, it does look great (needs its base to be assigned a texture though) but there is one problem with it: the thrust. Granted, it produces an extremely small amount of thrust, however I have had some trouble with several flight assistance mods where I had to disable certain features because the APU was being taken into consideration when calculating the thrust of the craft and was limiting the rest of the engines to match. This fact alone is a good reason to at least switch out the module within it to something that runs independently of the engine module. It shouldn't be too hard to assign a sound, and even a tiny little particle to an exhaust pipe or something, to run along with the fuel-to-power conversion. It also shouldn't be too difficult to add an intake air/atm requirement for a fuel-cell style module attached to the APU model for the up side of not needing oxidizer.

Okay, looks great... now make the track circle the entire KSC without requiring any end points and I'll be impressed.

I think we'd probably want something higher than 5% if we're using it to power repulsors. Depending on the power storage capacity of the craft, you could easily burn off 5% of your power reserves in a second or so. I would likely configure mine to kick in at 20% at the least. I'd really like to be able to program small solar panels to activate and start powering the craft at a 40% mark if not already active, which would make the APU truly a last ditch effort. If you're using near-future capacitors as well, it would be awesome to configure those to automatically discharge when reaching 5%. But, that's all independent of this mod. Just things I wish for sometimes. Hey, I had an idea a while back and I keep forgetting to mention it. Your rover body is pretty good (not counting the super oversized texture of course, which really needs to be resampled or something. I'd hate to see it simply resized and loose details) but it's pretty limited as far as it's size. I was thinking, if it could be separated into three parts (a front part, a middle part with the cargo bay, and an end piece) then it could be made to any size needed for someone's rover needs, and different middle pieces could be made to suit different needs then. Sorta like a simplified version of the other rover bodies you were working on a while back. If the cargo bay portion lacked end pieces too, then the cargo bay could be stretched to suit the user's needs. You could even provide half-length portions and such. The great thing about all this is that since you'd simply be cutting up the model you should be able to use the exact same texture for all the parts, thus reducing any need for extra texture memory consumption. I don't want to add this to the next release obviously, since we're rather close, but it would be something to add to the to-do list for afterwards. I might even tackle it myself if I ever learn how to do unity.

Honestly, I kinda like the inked Kerbal.

I have always been bugged by this. It looked like she was tempting death to come explode her face.

In the last release, I believe the heat production while running was still set to something like 450, which was a pretty normal average amount for a full size engine. Obviously something that produces no thrust and is as small as the APU is should never be generating enough heat to explode nearly so fast especially since it's just an auxiliary unit. I have a custom MM patch I run which corrects some of these things for my own game, but I'm unsure what the end result should look like. You'd better take over answering this one, lo-fi. It's your baby after all.