Deadweasel

I'd just like to note that even at fullscreen, you can still mouse out of it. I have multiple monitors, and if I rotate the camera too far, I can still let go of the button, watch the game minimize itself, and a context menu pop up in whatever other window I happened to let go of the button in.

The logic with this suggestion is essentially flawed. Just because something becomes paid, doesn't necessarily mean it's going to work perfectly every time. Look at all the Apple and Google Play store apps that crash often, even though the apps cost $2.99 (or sometimes more!) Shoot, look at the operating systems themselves! People complaining all the time that all of the major OSes are crap because they crash for them a lot. Usually it's just a case of a user who doesn't know what the heck they're doing, but that's beside the point. >_> Money is not the great motivator to make something work, and it's still not a guarantee that something will for for you. At the end of the day, the modder who feels passionately about their project will step up to the plate to fix a bug in their code all by themselves, but you have to realize that even that won't be enough to overcome issues that you might be actually causing for yourself. Take a look at why the game is crashing. Is it really because of a bug in one of the mods, or is it possible that you're running TOO MANY mods at once? Have you tried running one of the memory reduction mods that exist for this game? They really do work, IF your problem is based on running out of memory. Is it a bug in the mod itself? Do your logs point to a major error the game is throwing when it dies? Bottom line is that if you're going to make changes to the game on your own by installing mods, then you need to acknowledge the fact that you're responsible for tracking down where things went wrong. SQUAD have developed a game that works, and works well. They charge money for it, and as such work hard to listen to the players and address bugs that might exist in their code. However, they are a full-fledged company, already set up and configured to deal with the myriad legal aspects that earning an income from their work will create. Modders are doing what they do because they love the game, and want to see their own idea work with it. SQUAD doesn't pay them to do this, and modders can't really ask for money for their work themselves anyway, as they'd be profiting from work that is based on somebody else's intellectual property. You see, there's this little thing called "copyright" that keeps that from happening.

For those who aren't yet aware of them, there are some mods that help memory usage by compressing any textures to formats that are easier for video cards to work with, and reduce the actively-used memory footprint as well. For those who would like to use their own custom textures to replace the planets, skybox and kerbals: Universe replacer Texture Replacer For those who use the stock textures (including those delivered with parts pack mods) Active texture management The first two will help to reduce memory usage, while opening up the capability to replace the stock imagery in the game. Of the two, I've found Texture Replacer is a bit better at reducing RAM usage, while requiring a bit more effort to get the new textures in place. The last, Active Texture Management, is a bit more purpose-built, and is a "one shot" mod, in that it handles the compression on a more permanent basis, rather than doing it on the fly during loading. The results may be worth the "destructive" nature of the beast for some players. That said, let's not forget that there are two major classes of issues that people see in this game Crash-to-desktop (or CTD): Occurs most often when the current 32-bit Unity engine is trying to use more than ~3.2-3.4GB of RAM, due to overhead introduced by mods. Having a 64-bit Unity engine running underneath it all would likely help drastically reduce (if not eliminate) the frequency of this issue, but would not necessarily be a straight cure-all, due to the reasons stated previously. 64-bit Unity itself would require more RAM just to get up and running. If a player is experiencing CTD and has "only" 4 or 6 gigs of RAM installed, going 64-bit would not likely help the issue very much at the end of the day. Frame rate lag: Unity's physics calculations are primarily done on the graphics card's processor. Going 64-bit would not really have an impact on performance with 600 part ships in the scene, and this especially true for video cards that weren't meant for major graphics applications. Most of the integrated graphics adapters found in laptops, low-profile desktops or "value" desktops like Compaq or eMachines fall into this category. By and large, the main benefits of 64-bit in this case would be access to more RAM (so we can install even more of those oh-so-tasty mods!), and potentially slightly faster load times. That's about it. Folks running the experimental Linux distro can offer some perspective, but Windows and OSX users should be cautious about accepting those cases as universally applicable facts, due to the fact that Linux is so much more intricately configurable and adjustable, compared to OSX or Windows, where drivers and memory management processes are concerned. Linux folks can compensate and tweak core-level settings to get around glitches and leaks, but anybody not running Linux will simply have to wait for Unity to get things working from their end. We simply don't get that kind of configurability with our drivers, unless somebody is enough of a code wizard to write their own driver patch.

I know not everybody works in Windows, but one thing that is generally accepted across nearly all operating systems is that "Apply" means apply settings and leave the window open, and "OK" means apply settings and close. I suggest that the game settings buttons be renamed from "Apply" and "Accept" to "Apply" and "OK" instead. It's a very minor gripe, sure, but more often than not, because "Apply" is first of two buttons with similar (at a glance) labeling, I click it without realizing that it won't close the window, so I have to then click "Accept" in order to finish and back out. The Unity UI engine doesn't try to accommodate usability standards, so it's left up to the designers to compensate with familiar labeling. As it stands, the current labels are a slight deviation from the standard that is observed in nearly everything else, from the OS itself to interactive websites. Does anybody else notice this, or is it just me? Again, I know it's extremely minor, but it does give me a virtual flick in the head whenever I stumble into it.

That has to be the shortest troll attempt I've ever seen.

Oh that's quite sneaky right there. Also appropriate! Thank you!

*headdesk* TOTALLY forgot color settings are related to brightness (intensity) too! So, yeah. What (she?) said. Exactly that. Channels ®ed, (G)reen, (B)lue. 1 is full-on for a channel, 0 is full-off. Adjust each channel downward until you get the color and intensity you're after, and you're good.

Wow. It even wiggles like a proper KSP craft.

Ohhh.... Well in that case, not really. It looks like the other mod essentially gives some of the stock lights more "glow" by adding emitters to them, or changing the base shape of the emitter object. Aviation Lights will definitely put out a pretty nice glow, depending on how many you place, and where you place them. They have a pretty heavy additive effect, so enough lights in proximity to one another will bloom like nobody's business... But individually they will glare on surfaces *behind* them more.

Well bear in mind that a lot of the B9 wings have mad lift, certainly more than just about any stock design that isn't using a crap-ton of clipped components.

Not sure why you'd need that mod specifically for this one... Though, thanks a bunch for linking that! Because I didn't have to go looking for it, I just clicked, read the description and realized why all the lights on my ships always seemed to be canceling each other out! Can't wait to up the pixel count limit when I get home now.

You aren't really trying to have a realism discussion about this game, are you? Because, well... Kerbals. >_< But, just on the off-chance you are trying to make a case for the lights being unrealistically bright, may I present Exhibit A (notice the ground under and near the wingtips): and Exhibit B The purpose of navlights on aircraft is to make the craft visible to as many other aircraft as possible, as far away as possible (within reasonable limits, can't be blinding pilots immediately nearby!) The reason you don't usually see them lighting up the wing surfaces so much is because in real life, nav lights are directed, like a flashlight beam, to guide as much light in an outward arc as possible. Lighting up the wings themselves would be a waste of available light, as it's assumed the pilot already knows where his plane is. That said, KSP deals with lights as spheres or cones. To have these lights using cones would make the light project outward like the spotlights, but would otherwise have little effect in helping you to see your own craft better from a distance, because KSP can't display the glare of the light itself. Those glaring lights you see off the water tower at the launch platform, on the runway and on top of the air traffic control tower? Fakes. They're images "painted" onto transparent 2D shapes. The light emitters they contain use either the standard spotlight shine (on the launch tower), or the spherical emitter (on the runway guide lights). Allll that having been said, it is possible to dim the Aviation Lights, but you'll need to either modify these lines in the source code (I think; BigNose can set me straight if not): private const float INTENSITY_GLOW = 0.33f; private const float INTENSITY_OFFSET = 0.67f; or, we can ask BigNose to mod the mod (heh) to allow for more legible values to be used in each light's .cfg file. So instead of the "0.33f" values, we could use values from 0.0 to 1.0 to set up our own light intensities.

Just my two cents here, but what would be really cool would be to have recordable surface track data. That is to say essentially a GPS locator with persistent trails that can be toggled for a given craft, so that a ground or (relatively) low altitude mission path can be shared with others later.

LRC TranStar Goliath .craft file Requires these mods: B9 Aerospace (All hull components) KW Rocketry (Engines) Fueltastic Aviation Lights (this is where the blue and white lights on the DV-103 come from) Infernal Robotics Goliath's action groups are limited, as I wanted to keep slot conflicts to a minimum when other ships are docked. As it is, since the fuel converters don't involve any moving parts, "9" is used to toggle them on and off. I also usually include one amber light as an indicator that the converters are running (they will suck the power down fast!), but this current hull is only a testing design, not yet completed and ready for final deployment. Beware, those fuel converters are not only power-hungry, they are dog-slow. They will not keep the engines lit all by themselves. They'll refill the tanks, but it takes a lot of time. Goliath is intended to act as a service platform for other, smaller ships, and eventually will become the central processing platform for kethane mining operations (which will of course necessitate further design changes down the course). I also don't have a properly-functioning launcher for this ship yet. Eventually I will, but for now, the only way to get her up in orbit is through filthy, dirty cheats (first flight was primarily for maneuver and stability testing).

Whoops! Great find, I totally missed that!

Good luck getting those lip prints off the inside of your visor! Jeb's going to be looking at you funny for a while now.

DV-102 Sherpa, unable to maintain lateral flight in atmosphere with a payload, was in need of a replacement Today, a replacement was finally in sight. DV-103 Dromedary, with its variable geometry wings and engines, completed its first successful ascent from an atmosphere with payload Just in time to intercept new LRC TranStar Goliath to begin mission equipment assembly for a planned exploration deployment

Sent up DV-103 Dromedary with a Hexapuma rover. It made orbit, barely. The Juice Boxes were slurping every bit of power the engines generated, and then some. It was really hairy for a few minutes, trying to keep the payload balanced under thrust and the engines supplied with fuel, but once she got up to 20km above the densest portion of the atmosphere, the solar panels could come out to assist, and the wings dropped in-line with the CoM. She's currently orbiting sedately in standby while the LRC TranStar Goliath takes up her own parking orbit at 500km. With Goliath's deployment activities nearly complete, Dromedary will proceed on its intercept and delivery maneuver.

*snerk* You broke it then. It's doing wonders for saving RAM on my system, though admittedly I'm not swapping out any of the textures. I'm using it specifically to compress the existing textures with all the mod packs, and it's doing a fine job with that alone.

Given the new parts sneak peak Bac9 tossed out a while back, I'm not surprised he's taking quite a bit of time to release another update. Undoubtedly there's a lot of new animations and textures that will be coming along with them, and there's probably quite a bit of work to do to ensure that they're not only fully compatible with every other existing part in the pack, but that they don't also create some kind of headaches with other packs as well. Case-in-point: the B9 landing gear themselves have a pretty big "hitbox" around them, so if you're looking edge-on at a deployed gear in the SPH/VAB, attempting to click just behind it will result in you picking up that gear anyway. You have to rotate the camera and possibly zoom in beyond that gear so you aren't accidentally interacting with it. I can imagine there are lots of interesting little adjustments to avoid even more drastic examples of issues like that. Given what he's produced thus far, and that (with a couple of minor tweaks) everything can work just as it did before the 0.23 update, I'm content to kick back and play while waiting for him to drop the virtual bomb on the entire community once again.

True, but I'm not familiar with MM enough to create a script for that. I'll contact the author of the control surfaces tweak and ask if he'll add that in though, making the change easier for folks down the road.

Alright boys and girls, I got your back on this one! I can't deploy the part files themselves without violating the license, so here's all you need to do! Open the relevant .cfg file with Notepad, Notepad++, or ANYTHING EXCEPT WORDPAD OR WORD, and replace everything in the file with the following: FOR H50.cfg PART { // --- general parameters --- name = B9_Utility_Leg_H50 module = Part author = bac9 // --- asset parameters --- mesh = model.mu rescaleFactor = 1.25 scale = 1 animationName = leg_h50_toggle2 PhysicsSignificance = 0 // --- node definitions --- node_attach = 0.0, 0, 0, 0.0, 0.0, 0.0 // --- editor parameters --- TechRequired = advLanding entryCost = 6700 cost = 1250 category = Utility subcategory = 0 title = H50-A Landing Leg manufacturer = Tetragon Projects description = Landing leg for excessively heavy landers. We aren't sure how you got things like these into space in the first place, but this thing will help to get them back onto the ground. Probably. This model extends vertically and should be attached to the side of your lander. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 0,1,0,0,0 // --- standard part parameters --- mass = 0.2 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 120 maxTemp = 2900 CoMOffset = 0, 0, 0 breakingForce = 250 breakingTorque = 250 deploySpeed = 1 retractSpeed = -1 randomSpeedFactor = 0.05 MODULE { name = FSanimateGeneric animationName = leg_h50_toggle startEventGUIName = Deploy endEventGUIName = Retract toggleActionName = Toggle gear availableInEVA = True EVArange = 10 } } For H50P.cfg PART { // --- general parameters --- name = B9_Utility_Leg_H50P module = Part author = bac9 // --- asset parameters --- mesh = model.mu rescaleFactor = 1.25 scale = 1 PhysicsSignificance = 0 // --- node definitions --- node_attach = 0.0, 0, 0, 0.0, 0.0, 0.0 // --- editor parameters --- TechRequired = advLanding entryCost = 6700 cost = 1250 category = Utility subcategory = 0 title = H50-B Landing Leg manufacturer = Tetragon Projects description = Landing leg for excessively heavy landers. We aren't sure how you got things like these into space in the first place, but this thing will help to get them back onto the ground. Probably. This model extends perpendicularly and should be attached to the underside of your lander. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 0,1,0,0,0 // --- standard part parameters --- mass = 0.2 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 120 maxTemp = 2900 CoMOffset = 0, 0, 0 breakingForce = 250 breakingTorque = 250 deploySpeed = 1 retractSpeed = -1 randomSpeedFactor = 0.05 MODULE { name = FSanimateGeneric animationName = leg_h50_toggle startEventGUIName = Deploy endEventGUIName = Retract toggleActionName = Toggle gear availableInEVA = True EVArange = 10 } } If you're currently running the game, back out to the Space Center scene, and hit Alt-F12 to open the debug window. Select Database, then click the Reload All button. When the mad scrolling stops and the display returns to the master database info stats, hit Alt-F12 again to close the window, then dive into the SPH or VAB. You should be able to tweak the gears just like the wheels. ENJOY!! EDIT: All that's necessary to really change is the initial MODULE call near the top of the file, changing it from "HLandingLeg" to "Part", then adding the final Module FSAnimateGeneric section in the above code snippets to the end of the file.

Sadly, while there is a tweakables fix for the wings, there is nothing so far for the H50 legs that I've found. In fact, I (and at least one other) have noticed that the legs don't respond to direct controls (right-click and extend/retract). They do work with the general gear key (G), but don't seem to have any interaction in the VAB/SPH or direct click control.

That would be the Infernal Robotics mod, which I use to create VTOLs with much much more reliable flight profiles.

*shrug* Best get used to seeing more like this, from what I can tell. There can realistically only be so many unique and "interesting" topics, but everybody's going to keep looking for an opportunity to create the next big "Awesome Pics" thread.