Gaalidas

So, in simple terms, it is how it is and we should really just accept it and move on. No easy way to make an engine take up less fuel without over-increasing the thrust and making a fuel tank that's unrealistically light and unrealistically full.

That's why, when someone put up a mod a while back that disabled that little popup, I grabbed that little bugger immediately. I can easily track my own mod versions and compatibility issues without KSP bugging me every time I launch it.

Or, you know update the mod only to find out it's still geared towards the last version of KSP and still reports incompatibilities.

That or get that mod that suppresses the incompatibility alert.

I convert all textures in my mod installs to png to avoid the tga issues. Also, for the issues with DX11, it should be noted that (as the OP states) this thing only really works in DX9. I hadn't heard anything about DX11 stabilizing 64bit. In fact, that really doesn't make a lot of sense to me. I have doubts that I could run anything in a stable DX11 on this barely-chugging laptop though.

That's what you can't stop me from doing. I upchuck crazy ideas like a bad illness, and those ideas drive your type of mind into an "I can do that!" mode.

Why stop there? Lets have a Puny-sized bubble for a kerbal with a HUGE battery attached to his back-end. EVA warping anyone? That would have made Manley's EVA return trip so much easier. (I watched that video for the first time yesterday, returned from another world solely on EVA in an earlier version of KSP that had no re-entry effects.)

Bah, too easy. I'm thinking a giant airbag strapped to a brick wall at the end of the runway mounted on some really big rotatrons that can be contacted via radio to deploy only when the landing aircraft needs to stop. Yeah, that's a much better idea that this "airbrake" idea. Are we Kerbals or not? lo-fi, you are one of a kind. I find something that I world like to have, and I do a search through all of the mods available at the time for that functionality. You see something you'd like to have, and before even looking to see if it's been done, you fire up your development software and pump out a new plugin like it was throwing a TV dinner into the nuke-box and calling it a balanced meal. Completely and utterly nuts!

That begs the question, how does one effectively slow down when "landing" means still having no friction with the ground in which to stop with? With these repulsors in use so much, it's a wonder that off-shore boat doesn't get smacked in the face more often. Guess that's why I'm in the design office and he's out defying death on a daily basis.

That was only half of it. The engine was a mainsail, and Jeb was at the controls, but what they didn't include in the report was the large tank of fuel hanging precariously off of a half-broken truss that Jeb apparently clipped a type B asteroid with. This thing was ready to fall off at any moment, and it was structurally compromised, so the chances of a catastrophic fuel leak, or worse an explosion, were pretty high. I won't estimate the damages, or any fatalities, at this time... lets just say the VAB is safe for the time being, and Jeb is napping in the corner surrounded by debris from the cleanup. The ground keepers are gonna be royally displeased.

By "disrupting parts of the ship outside the bubble" I do hope you intend on implementing some way that we could expand this bubble to properly cover the entire ship, maybe with an energy requirement per some unit of measurement for sustaining the bubble outside of the intended size. Otherwise, we're limited to the bubble size and shape in which to construct our craft unless we accept the possibility of our ship being torn asunder by the limited bubble size. Now, I would love to see something where it not only causes fluctuations in the space around the bubble, but has the ability to rip away parts of surrounding crafts that get their bits caught in the bubble when the ship uncorks the bottle, so to speak. I also wonder if combining the warp bubbles of several ships moving together (such as with that burning-together mod (or whatever it's called)) to create a shared-bubble of some sort. Okay, my imagination it going nuts. Just continue as planned and disregard my crazy brain.

if you dipped into the modding scene, you could probably make it relatively easy to mix and match the parts while pulling off some custom parts to make it fit together. The trouble is that the Andromeda Ascendant was a pretty large warship. We're talking about a huge crew capacity, the capability to take on some of the meanest bullies in several galaxies of space, retractable defense systems, and a state of the art AI capable of commanding the vessel competently in the case of overwhelming crew loss. In KSP sizes, this thing would still easily dwarf the entire region that the KSP is built in. These things were never "launched" in the traditional means, but rather "built" in orbit (of the local star, not some unworthy planet) and navigated in the scale of star-clusters instead of how we navigate KSP, which uses planetary bodies as locational markers. This is simply not a ship that could even be lived up to in KSP. Now, within that universe of ship designs were several smaller, similarly constructed crafts, which might be constructable within the scale we're used to without falling flat of the real deal. Okay, so maybe I was a bit in love with that ship. The show kinda fell flat after that whole alternate-reality crazy-nutty thing they did in the last season, and that whole "rebuilt the commonwealth, and now they don't like us anymore" crud was a bit hard to go along with, but otherwise a good series. That other craft, I don't have any clue what it is. It looks pretty, but rather inefficient. It looks to me like they grew it rather than built it. I could sneeze on that thing's bridge and break the navigational equipment. What happens when a stray micrometeorite hits the hull? Think about a pile of leaves in Fall. Now imagine jumping into it. That's what I see happening here.

I had a feeling while reading this thread that it would come down to resource density at some point. So the question, for us mathematically challenged out here, is this: To make less fuel be consumed per second of maximum thrust for a given engine be to reduce the resource density or increase it? A similar question exists for fuel tanks. How will this affect the amount of fuel we can carry with a given tank? In the end, with the same size tanks, we may end up still using the same amount of fuel compared to the maximum that you can carry. I am curious to know if there is any real benefit to changing any of these numbers to increase fuel efficiency without sacrificing performance at launch time.

Wait, does that mean you have a life outside of Kerbal Foundries? I'm shocked.

Wow, I delayed looking at this thinking it was just another new model for the KSPI mods and it's various iterations. Stand-alone sounds awesome though. I always hated that the other mods of this type were always so complicated compared to the usual kerbal simplicity that makes KSP so easy to jump into and mess with.

then it becomes an assisted suicide platform.

In time, however, we must all move on and come to realize that this mod may never be released. I have wasted too much time and energy waiting for releases that were never going to be finished enough for a release because it just isn't worth the effort on the developers part to finish. I'd be happy with an unfinished product that the community could wrestle with and figure out how to fix, but if he's unwilling to release anything that's not finished enough to be fully functional, then we're just wasting energy trying to coax him into coming back to a thread that he may not even be looking at, ever. It's a real mystery as to where that line between "encouraging" and "wasting time" is. A perfect example is me writing this message. I'm wasting my energy and time right now writing all of this in a thread that may or may not even be monitored by the person I hope is still out there. I still hold on to that glimmer of hope that this guy will suddenly stop by any day now and have a complete package with all the bells and whistles perfectly fixed up for us to consume. I just choose not hold my breath while holding on to it.

That's the danger of code diving other people's work. You always need to fix everything.

I hear you on the updating of specific parameters for the scale factors. That was the main reason why people had problems making IR parts larger than they were intended. I fixed that on my local install by adding another set in their exponents for the ExtraLarge scale factor I wanted to introduce. Without adding another set to the exponents I'd have been stuck with a really slow joint for the extralarge parts. Though, I must admit that after all that trouble to fix everything for that larger size, I've never actually used it. So, in reality... In this you are absolutely correct. It'll work, sorta, but it'll be really wonky in some situations. It's just something to keep in mind, lo-fi. You've got your hands full already with all the crazy stuff you're developing. I wouldn't write anything off and a no-go just yet. Lets get these babies into a beta stage before we worry about making them compatible with other modifications. The important thing is that they work with their natively intended scales and configurations.

if all else fails, you might be able to dig into it the old fashioned way... force open it in notepad++ and sift through the goop. Sometimes these things have a fair amount of plain text you can look over though.

Note, I edited my last post with a lot of useful stuff, some of which might help explain what is being discussed about super-brakes on turning and whatnot.

Emissive always seems to add another level of complexity. For instance, when using KerbPaint, if you use anything other than the EmissiveBumpSpec shader, your emissive will fail to appear no matter how it's implemented (painted or not, just having that shader applied cuts the emissive out.) Would be worth a try, however, to just add it to the list of types that it will animate and see what happens.

You can define your own exponents in a separate config. That's the nice thing about these custom nodes, you can define them anywhere (inside or outside of a part, below a part in the same file, a completely separate file, an MM patch to insert them into the official file) it really doesn't matter at all, as long as the formatting is done correctly. For instance, if you look at IR they have some specific code for their use that makes use of a Tweakscale redistributable and they have their own exponent definition file, plus some separate exponent definitions in a few of the specific parts. These are sometimes defined as a separate node in the part config, and sometimes they are defined in the tweakscale node itself. I've even seen two of them in one part file, one for generic exponents and one for a specific module. On the other hand, there have been a lot of weird things to happen and it's a bit hard to track down if you do not have all of your tweakscale modules in a single MM patch, and your exponents in a separate config on the side. It might be a good idea to look into the ways that a plugin-writer can interface with tweakscale as well for your more complicated needs. Also worth noting is that Tweakscale is being actively developed. They recently updated it with compatibility for the FS fuel switching module. On the topic of symmetry issues, I always find it a good practice to remove my symmetry one I am happy with the product and ready to launch with scaled or painted parts. I use "PartWizard" to switch off, or optionally re-group, my symmetrical parts to ensure launch stability. I even took at 8x symmetrical arm-piece and separated it into two 4x symmetrical groups to aid in creating a probe out of the PunyProbe parts which had four prop engines and four monoprop engines staggered around the central core. The reason I had to use PartWizard to pull this off was that I was using a modified thrust plate adapter (tweakable node size/number/offset on a flat plate of tweakable size itself) to provide stack nodes to attach the arms to. In an 8-node configuration I had a node for each of my two sets of four engines. When placing different connections to those arm pieces, I was being forced to use 8x symmetry. After re-grouping them I could create the two sets separately while still, technically, arrayed in 8x symmetry. Normally, I would have had to rely solely on surface attachment do pull this off, which is sometimes unreliable. I may not be an ingenious pod-racer builder but I do have some mad skills with all these little tools and such. EDIT: Okay, so I took a look at your config updates and I've decided to write up some example configs for you. Note: all of this can be defined in the same file, and even put into the part configs. I like to put them in separate files for modularity. First is our scale type: SCALETYPE { name = KFWheel //or whatever you feel like calling it. freeScale = false //you can imitate free scaling by providing lots of specific scale options.. scaleFactors = 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 2.75, 3, 3.25, 3.5, 3.75, 4, 4.25, 4.5, 4.75, 5, 5.25, 5.5, 7.5, 6 minScale = 0.25 //minimum scale factor. maxScale = 6 //maximum scale factor. scaleNames = 0.25x, 0.5x, 0.75x, 1x, 1.25x, 1.5x, 1.75x, 2x, 2.25x, 2.5x, 2.75x, 3x, 3.25x, 3.5x, 3.75x, 4x, 4.25x, 4.5x, 4.75x, 5x, 5.25x, 5.5x, 7.5x, 6x defaultScale = 1 } Yeah, writing all those scale factors is a pain but at the least it's consistent between different parts. Free scale is limited by the size of the slider and the lack of configurable scale increment size. You could hit a spot where you get 1.14 scale factor with one part, but with another part you may have only 1.19 or 1.11 to select from due to the limited space and the limited pixels you can click on within the selection bar. With some experimentation, you might be able to expand on the tweakscale implementation to allow for a Procedural Fairings style incrementation slider which allows you to set a base incrementation for the arrow buttons, while still allowing use of the double-arrow buttons to increment a static amount, and then using the slider you can increment to the factor of 0.1 on the base scale incrementation setting. This allows for the ultimate in scale control without needing to find a way to make the context menu super huge or frustrate users with free scaling. Next is the Exponents section. TWEAKSCALEEXPONENTS { name = KFWheel //the name of the module being manipulated along with the scale module. <your parameter name here> = <your desired factor here> <etc.> = <etc.> } This is another way that exponents can be defined in the part itself, or the MM patch to plug it into the part: MODULE { name = TweakScale type = IR_RoboticDocking TWEAKSCALEEXPONENTS { mass = 0.0125, 0.025, 0.05 } } In this example, the mass has three values which correspond with the first three scale factors defined in the scale type. This way specific exponential factors can be defined for fine tuning performance for a specific scale. I believe this can be done in the previous example as well. Then, finally is your own implementation for the part itself which comes in the simple form of: MODULE { name = TweakScale type = KFwheel //corresponding to your scale type defaultScale = 1 //for specific scale-settings that override the scale type. } You can override any values in the scale type, and even the exponents as shown in the IR example, by placing them in the module for the part. The most common is "defaultScale" for parts that fall in line with traditional scaling factors for stack rocket parts. In the KF situation, it might be useful to set the really large wheels to default at scale 5 or something, since you'd want to give users the flexibility of scaling those down a ton, but don't necessarily want to account for KSC-sized super-wheels when they are scaled from 1 to 6 where 1 is equal to their current size. I believe tweakscale scales all the other values that control scaling as if the default was actually at the value of 6, and doesn't simply scale the part to 6x upon being loaded. I have not confirmed this, but it seems to not do anything weird when I set up my own custom scale factors. Hope this helps somebody out there. Also worth noting is that repulsors of both types seem to function out of the box with tweakscale, but you may want to look into any specific factors on their functionality you might want to tweak with their scale. Perhaps you could scale their max/minimum height range based on their scale, and energy usage as well. I believe that scale exponents can attach to anything that is definable in a part config, as long as you specify the module that it is manipulating.

What blasphemy is this? (nah, I mess around with that one every once in a while. KSP lacks some of the immersion factor that many of us are looking for.) EDIT: Okay, I just heard that KerbPaint has been mentioned in here. That's one that I've been looking into for a while. One snag I found with it is that the APU model has a fair number of surfaces that do not seem to be textured. Fortunately, the application of KerbPaint is pretty simple when following the directions on the KerbPaint OP. You just need to create a color mask for the part you want to color, put it in the folder with the rest of the KerbPaint masks, remove the file extension from the file (so that KSP doesn't try to load it, allowing the plugin to import the data itself) and either add the module information to the part directly or make a MM patch for it. I sorta stopped trying to get it all configured when I realized that the part textures could change at any moment. That and, after getting B9 (the new release) completely re-done for KerbPaint, I was pretty burnt out. Guess it's about time I looked into it again. It's crazy too, KerbPaint is the least updated mod in the last year (actually, it hasn't been updated at all relatively recently) and still works as intended. It doesn't even pop up version incompatibility. The only parts I could not make work without issues have been the ones in the IR rework. I got strange texture flashing issues on the part surfaces when using KerbPaint on them, regardless of whether they had been colored.

Hey, you're allowed to have your moments of quiet inactivity. Within reason that is... go away for too long and we will find you. We're geeks, we can find anyone and make them get back to work. [insert maniacal laughing sound clip here] Don't believe me? Ask yourself "why haven't we seen any new releases from Alexustas? (the ASET guy) That's right, we've got him... and it isn't pretty...