keoki

I upgraded to 1.2.2.1622 win64 a few days ago after not using KSP much for a while. I decided to install Interstellar Extended, and eer since I hae been hammering on one problem, trying to make a reactor do *anything*. I build a simple ship, a pod, a small generator, a small fission reactor, a radiator, and a couple dozen MK1 lights to act as a test load. I'e watched every tutorial, read dozens of web pages, and I hae several years of KSP experience... It should be working, yet it does nothing. I turn the lights on, battery reserves drain to zero, the lights turn off. This is after launching a dozen orbital missions. I have tried nearly every reactor and generator, and I finally stopped wasting time and have been building ground based tests to get something working. By not working, I mean the right click panel on the reactor does nothing. The generator shows it's battery reserve drains, but zero waste heat, zero reactor fuel consumption, no depeted fuel, just nothing from the reactor at all. The only thing I can report that is odd, is I have to turn both the generator and reactor upside down most of the time for the attachment points to work in the VAB. I think that is normal, as I hae seen other parts that have directional attachment points, so I shrug that off... So I decided there must be a mod conflict, so I installed an unmodded copy of 1.2.2.1622, with only the Interstellar Extended mod. All fresh last night. So for most people this just works, but I do see people stuck like me, and I never see any answer that fixes it. Clearly I'm missing something simple, what is it?

About 6 years ago, Jedediah was on Duna, with a large team of engineers, to receive a large cargo of construction supplies being delivered by a very large mining and fuel production rover. As the rover arrived, it was decided to take a break from a successful landing of something far too large to be landing in one piece. Upon resuming the game, when the physics kicked in, the huge rover burred itself in the sands of Duna, paused for a moment, then entropy ensued. The attached picture is 6 years later. The cargo ship has disintegrated, but it's load of struts is still exploding. The explosion ripped a hole in space and time, and time is nearly stopped for everything within 2.25 km in all directions. Landing on the site is not possible, as time grinds to a stop before you can touch the ground. Scientists back at the space center think Jeb is having fun being tossed around on the end of a strut, and estimate it will be 65,000 years before he is ready to stop horsing around and place an order for a new load of supplies. The other engineers don't look like they are having as much fun as Jeb...[IMG]http://i.imgur.com/idpoPcv.png[/IMG]

So after seeing several people land asteroids on Kerbin, I decided to try. So after pulling an all-nighter, I landed an E-Class asteroid in time to take a shower and head to work. But much to my dismay, it disappeared a few seconds after the landing. The landing was rough on the main ship I had used to fire engines during the last state of the landing... The ship was knocked off the rock, and was partially destroyed... But the rock rolled off the ship, teetered for a second, and came to a rest. I then zoomed in on the ship to check the damage, and when I zoomed back out, the rock was gone, and a couple seconds later I was back at KSC, and tracking had no sign of the ship I had landed the rock with. Both the rock and the main ship survived. The other ships that provided parachutes disappeared with the rock when it vanished, but they had survived in tact... Well, till they disappeared... Dang! I didn't even have time to take a screen shot of the landing... <sigh>

Yeah, you are helping make my point. I have done exactly that... and more. And the results were awful. Pretend that your post is the only information I have. Pretend I have never seen a joystick or flight control before. Is that /really/ enough information? You sum up the information I am looking for without providing any information. You walked me up to the door I've already been /through/. Almost as if you only skimmed my first post without reading it. I appreciate your spending the time to answer, and I get what you are trying to say. But my questions were about what I should do AFTER I click settings and select the control tab. And I don't mean how does the settings UI work, I did in fact set-up my stick. But the words pitch, yaw, roll, etc... I've heard those words before, but they may as well be words from a foreign language. There is a TON of information on these words when you google them, but that doesn't translate into what axis they should be applied to. Obviously I haven't found the page I'm looking for yet, because 99.9% of the pages that talk about this stuff don't display a mapping of those words to a flight stick. If I'm lucky, I'll find a page that mentions pitch and illustrates it... So I have that ONE. Roll and yaw seem interchangeable, in fact some pages talk about swapping them. All of the discussions start from the point that the controls are already mapped, OR the person reading has mapped controls before. One post here looked really promising, he covered pitch and yaw, and followed that with "and so on..." . I need the "and so on" part. The next almost promising post (from a different game discussion I googled into) put yaw on a completely different axis, and the next one discussed switching yaw for roll, but didn't relate either to an axis. Most resources talk about it, providing little more than the "and so on" with regard to specific details. I'm just looking for a documented starting point that includes the words used in the settings UI, so that I'm not left just guessing. Obviously I should start gaming with a game that already has a basic mapping done. Everyone has to start somewhere. The problem is I'm starting HERE, and have no interest in games. I'm here because the orbital dynamics simulation is interesting, not because I want to play a game. I'm posting this because landing something is rather difficult without a joystick, and using the landing mode of the mechjeb totally avoids me having to learn flight controls (and doesn't always get good results) And I understand it from the experienced person's point of view as well, I used to have to teach people the use of vi. vi comes naturally to me, but only because I've been using unix for 35 years...

So I'm /not/ a gamer. I'm an engineer nearing retirement age, and I have been playing KSP long enough to have completed a dozen career modes, and in general I know my way around KSP pretty good. I've been building/designing computers longer than most of you have been alive. I'm here because KSP is the first game to attract my attention. But I don't know beans about joysticks, or flight controls. I got my first modern joystick today. I got it because the keyboard sucks for many types of maneuvers. At least that is what I was thinking when I purchased the joystick... But now the joystick is taking the joy out of the game... I've searched the forums on the subject of setting up a joystick, but I mostly see people talking about it, but not actually explaining it. It seems most of you have been around joysticks for a while, and this is not the first game you have ever tried to map to a stick. So when someone starts a thread talking about it, there are few specifics discussed, only that it is easy, and several tools are out there to improve things so they are even better. Googling this subject, and it seems most games have the stick pre-mapped, so most people are only changing the defaults, not creating a mapping from scratch. Mapping from scratch is a tall order, when you don't know pitch from yaw. Is there a good resource out there for someone that has zero joystick experience? I went through the configuration screens, but I've managed to make flying from a keyboard seem easy compared to the stick... So clearly I got started on the wrong foot. I have an extreme 3d pro (based on recommendations here) but I really need a basic, but mostly complete guide on what mappings to configure as a starting point. I'll save the sophisticated tweaking and third-party tools for the threads that already exist... I'll get to that next week after I master basic flight controls with a stick. If there is a file with the basic mappings that I can just get a copy of, I can probably use that as a good starting point... But starting from scratch is difficult when there are no defaults at all. I'm /not/ asking for flying lessons. I only want a starting point for an initial mapping.

First rock was a cakewalk, almost regretted the work I put into the ship design. The second rock had an off-set center of gravity, so pushing with my large engine was a no-go, just put me in a spin that took half an hour to damp, good thing it was a single axis spin... But my ship had a secret weapon, Reverse! It is better to pull the asteroid than to push it, it seems. Same asteroid was easy to control in reverse. Just reserve enough fuel to do something useful. Both of my missions had to cheat on fuel to finish, so they don't count. You may want to have a fleet of robotic craft in orbit and fueled up for quick intercepts. Get them to orbit, and park them, then ferry up fuel to fill em all up

Yeah, signal delay would be more realistic... but what does that mean? So like I'm at Jool doing a mapping mission, I upload my map data, and have to wait two hours before I see the acknowledgement of my transmissions? Or worse, I have to wait two hours and search logs to see what failed so that I can retransmit? Of course a realistic scenario might be a computer display showing the packet queue of transmitted packets, with a update showing that some packets failed and have to be resent. And that status message might be coming from the nearest store-and-forward relay satellite. So I guess you send out com relay satellites in advance of any missions to a planet, or just drop one off in orbit... and if a relay network is needed to get all the way back home, you could establish a constellation of off-axis or intermediate orbit com satellites... Reading up on the mod, it looks like you have to select the relay, and it has to be in range, but you don't have to establish actual line of sight... So the realism stops before it gets actually difficult from the sounds of it. Yeah, I'll probably deploy that mod soon... I restarted my career mode in .23, just because a co-worker implied I was cheating the science. Funny thing, I'm getting through it faster this time around... I skipped over the easy stuff and went straight to fly-bys of the local moons, and the nearest planets to get enough science points to unlock the important parts of the science tree... I do need to get some sleep at some point though....

I'm able to scan at maximum time warp with no gaps... I have heard people talk about being conservative about using time warp with ScanSat, but I've been able to deploy my satellites, go to max warp, scan till I'm either done, or till I see a pattern that isn't clearing so I reposition my birds and warp some more... Now I see temporary gaps in the display, because the display scans the page slowly, so your satellite paints an empty trail until the next page update refreshes and fills the trail in... but that isn't a scan gap, that is just the way the map refreshes. Are you sure you are seeing gaps? the author stated that you can use warp with no problems... at least that is what I remember reading about three times.

Actually I had weak joints, that is why I had to create trusses. If I had used a mod to stiffen the joints, I wouldn't have needed trusses. A truss is where you create a triangular section to reinforce a joint. The reinforcement comes from the strut array creating tension in opposition to any attempt to flex the joint. The more stiffening your joint needs, the more radial trusses you use. Start with three, go up to 8 if you need them. A rocket that would snap in half if you attempted a maneuver under light load could do cartwheels under heavy loads once fully trussed. But it adds to the parts count, I would put a set of 3 to 8 fins between two weak joints, then struts from the leading wing tips and trailing wing tips to the sections just past the weak sections. In doing this I created stuff joints with stock struts. To further brace the weak sections I would strut from the other direction as well. I can do the same thing now with girders, but it is ugly, and doesn't add any control surfaces, AND girders weigh a LOT more than winglets. The science behind the trusses I was using comes from the grain elevator pipe truss. his structure, a pipe that would bend while under the weight of the grain passing through it, is made stiff when a triangular skeletal tension structure is created outside of the pipe. The larger the triangular sections, the more stiffness is imparted to the otherwise weak structure of the pipe. In the case of a sectional pipe, such as a rocket ship, it adds a compressive force at the joints, and braces against any side to side forces you might encounter during extreme maneuvers. I would rather use engineering concepts to overcome a problem than software cheats, especally if the engineering is fairly simple. I don't know who invented the truss, but it is really old, the Egyptians used them to erect their monolyths... I remember getting KAS to build a skycrane, I didn't realize it enabled the kerbals to pick up parts... That is good to know, makes sense. That doesn't really seem like a cheat though, it seems like something that manned flights were meant to add to space exploration, repairs, assembly, reconfiguration, and construction. That should be part of why they are helpful to bring on a mission. I do I remember discussing joint reinforcements in the forums, but I didn't get the mod that provides that. By that point I was building 900+ part ships and running out of memory, and I was removing mods rather than adding them. Thanks for the great answer re KAS...

In .22 I was able to move parts around, perform rudimentary repairs, , prepare the rover for specific missions, etc. I would have several items that were attached in a flight-ready storage position, low on the lander to keep the center of gravity low. When on the surface, the Kerbal would walk to within a couple meters of the item, and I could right click it, causing the Kerbal to stow the item on his back. I could then deploy those parts as needed for rover missions. Have the action-keys changed for this, or had this feature been disabled? It is pretty nice to know that when you have a bad landing, and your ship is damaged but not destroyed, you have a chance to repair it using the Kerbal. Or that the Kerbal can do more than plant flags and take soil samples. being able to perform VAB tasks in the field is a REAL duty of manned flights, there is no substitute for being able to get out and turn a wrench. My Kerbal can still fix a flat tire, but I seem to have lost the ability to do anything else. I'm hoping it is just because these functions have been moved to a set of keys, and I haven't found them yet... Now I did fully unlock my career mode under .22, and for .23 I did a clean stock install with no mods... I suppose it is possible that I was using a feature from a forgotten mod under .22... if so that would be handy to know. I also noticed that my stock method of stiffening large diameter ships using struts and fins to form trusses also no longer works. I can no longer attach struts to winglets, so now if I want to create a truss, I can't use something pretty, I have to use an ugly girder. It isn't the end of the world, but it means some of my best designs cannot move from .22 to .23. .23 is a wonderful improvement in terms of performance for high-part-count craft, though I have yet to build a 900+ part craft yet under .23, so I have yet to see the full impact of the speedup. None of my previous designs of heavy ships can exist in .23, so I have to design a whole new fleet. That is too bad, I kind of liked my ships... If I can't strut the winglets, I can live with that I guess, I'll weld something together to replace them. But not being able to reconfigure and repair while away from the VAB, well that is a step in the wrong direction!!

This is really nice.... I can't wait till I have all of my research unlocked and can try my heavy lifters again.... But so far it feels really smooth with all of the settings maxed out. Thanks Squad! The best Christmas present of the season!!

Yeah, the time estimates are a bit wonky... They sometimes have errors in either direction. For the first half of career mode, I didn't use quicksave, so I lost a lot of time when I overshoot something... And you can't just drop a maneuver point out there, it can end up on your next orbit, and you can warp past your encounter. Most of my gameplay is between midnight and 5am, so I snooze, and Jedediah looses... The upshot is I've been at this for about a month, and career mode for about three weeks... I have a fully unlocked tech tree for my career mode, while a co-worker with two years experience hasn't even unlocked his solar panels yet. I'm not even a gamer, I stopped playing games 20 years ago... It took KSP to renew my interest. It took something resembling real physics, that appeals to the engineer. Kind of looking forward to .23 coming out with what might be a more challenging career mode. I still have a lot of stuff I haven't done yet, I am in no way an expert... but I mapped all of jools moons in one mission, generating about 2000 to 3000 units of science per moon just in an orbital, no-return mission. Too bad I can't give some of that science to my friend at work... I don't need any of it... He just needs some solar panels. But I did tell him how to solve his power problems... turn the batteries off before you warp... and keep some spares, turned off, in reserve... At least till you can unlock enough parts to charge them. I was disappointed to discover that I didn't need to build a data network to get my weak signals back, as the specs for the antennas implied I would have to do... But that is coming in .23 I think.

Everything sinks? No, everything floats. Kerbals float, and they can swim. My all metal rover floats. No buoyancy mods here... Driving into a shallow puddle will get the rover stuck, I have to get out and swim my kerbal behind it to push it till the wheels touch bottom, about a meter deep. In the ocean, that would take months to get to shore. In a shallow sea, if I could sink, I could probably drive to shore on the bottom. Don't need to build a boat, just need an outboard motor.

KSP is a 32 bit game, but it needs the ENTIRE 32 bit address space to handle large ships. Your OS will need some memory as well. I would recommend a 64 bit OS, and at least 6 gig of ram, so that KSP can have a full 3.5gig all to itself, and your OS can have another 2gig to run in. From there, the faster the machine, the better your experience will be. I run with ships approaching 1000 parts. But I have a fairly nice engineering workstation, not a PC. Most of the time a ship sits on the launch pad with a large number of parts, and the number of parts reduces as you progress through the mission, so I'm starting to think that the most enjoyable gameplay is to start the game with the graphics turned all the way down for liftoff, then as soon as my craft splits off into smaller mission sub-craft, I should save the game, and restart with the graphics settings turned back up. To avoid crashes, try to keep memory consumption of the game to below 3.3gig. Keeping in mind that some activities will boost memory consumption. turning graphics from highest to lowest rendering levels will make a 900 part ship mission go from a constantly crashing 3.5 gig of memory consumption, down to only 2gig memory consumption. But even parts that are not on your ship consume memory, and the textures used to give them realistic form can take up a lot of memory whether you use the part or not, just having it installed in the game uses memory. I haven't tried this yet, but at the beginning of this thread there are hints on how to reduce that, and I will be looking into that myself.

So I'm enjoying crash-free gameplay, now that I have cut memory consumption. But I'm noticing a lot of dropped characters in the user interface, protractor, mechjeb, even in the setup screens. It is to the point that if I didn't know what it said beforehand, the screen would be unreadable. I have to restart the game between each tweak, so it would be helpful to know the answer to this... "Which setting did I adjust that is causing these dropped characters?"

Yeah, I don't want to dis the Squad team... it will probably take a major from-scratch re-write using a different game engine to fix this. That isn't going to be fun, and may well be impossible without an influx of cash, and sticker-shock when the game price jumps. On the other hand, I did some reading in the unity forums, and it seems that 64 bit support isn't (much of) a problem, and being multi-threaded is a matter of having some code that you can hand-off to other processors. I'm no multi-threading expert, but it seems the issue is having real-time-like events that need to be aware of each other in real-time-like contexts must generally occur within a single thread. Otherwise things probably get bogged down with inefficient inter-process communications issues that cause the threading to slow things down rather than speeding them up. Basically any task the game can launch a different program to perform, and have that data come back later without synchronicity, can be easily offloaded onto a different core. the problem is there may not be very many of those things, or it may be difficult to design those things into the game without creating gaping holes for new bugs. Especially if allowing third parties to contribute to the design. But that doesn't mean I can't wish for it. One improvement might be to learn a lesson from the guys from Ubio Welding. If a welding-like optimization was done as parts were connected together, you might be able to get the software to see fewer parts as the game was manipulating the joined object. Obviously you are no longer doing as much physics between each connected part, so to simulate reality you would have to continually analyze the cross-object stresses, and when certain thresholds were exceeded, the joined object would need to be partially un-joined to display the results of the physical stress. And by the way, this set of tasks could probably be performed as processes off-loaded onto different cores. It might mean that there would be a slight delay when you do something to make your rocket break in half, but it would mean that more complex rockets would fly with better frame-rates. But this would probably come at a cost, When you built a new craft, it would probably take longer to show up on the launch pad. Another way to use threading, which wouldn't help any of us, would to put other solar systems on other cores. But let's see what we get with .23, where I read that we will be seeing a lot of effort to improve efficiency. My fingers and tentacles are crossed for that one holding some big improvements...

So I turned all of my graphics down to the lowest setting, and I saw zero improvement in loading or play speed (I have a really fast engineering-workstation-class machine running with a raid 10 ssd filesystem, and 32g of fast ram). However what it did improve was memory consumption, I went from always being at 3.5g for KSP to about 2g. So that means the game has stopped crashing all the time. It would be nice to see a multi-threaded game running in a 64 bit address space. That way we can use all of our cores, and more of our memory.

The game is single-threaded, so it runs only in one core.

Only problem with merging parts is you loose many characteristics, such as heat dissipation, and ability to mount tanks correctly on parts like the TT-70. Welding mostly works on stock parts, and doesn't work on most parts from third parties. It is great for many things however.

I have a quick question... Is there a UI to browse the map data library, so that I can review the maps for mission planning purposes? Right now I need to plan missions to remap everything I didn't get with the "HI" antenna, since I only recently earned enough science to finish unlocking all of my career mode objects. Now that "big science" missions are no longer the focus of my career (until .23 comes out), I want to focus on exploration and skill honing. I know I can view a map while I am in the vicinity of a planet, I have been cleaning up my game mission debris trying to get it to crash less, so I haven't been leaving probes behind... I'm starting to think that I should have left one small satellite in orbit around every mapped object, and use the tracking station as the UI to the maps. Also, it would be cool to have a control panel for the network of satellites in orbit above a planet. What I do is fly a craft in, and drop off several passive probes in various orbits. The probes are simple, I start with a small tr-2v stack decoupler, a small okto2 control pod, stack a battery and a couple of pb-nuk's on that, then a small girder segment that I can hang the scan antennae onto, as well as some optional science modules and a transmission antenna or two... The transmission antennas and science modules depend on the purpose of the mission, once I have exhausted the science, I start leaving the science gear off. These passive probes are lightweight, and they stack, so I can carry a lot of them. My Jool mission has 8 probe laden rockets, each with three drop-off probes, as well as a full set of science and SCANsat antennae on the main body of the craft. Essentially I carried more craft than I have objects to scan, so that I can have some mishaps without having to start the mission over. The probe craft doubled as final stage boosters, as this is a heavy ship, and I refueled them as I use them from the mothership tanks. My tentative plan is to see if I can take any leftovers from that mission, and see if I can budget the DV's to visit Eeloo with a probe craft.

I launched a multi-satellite launch platform that separated into a total of 21 different mapping probes. The concept is that I launch to Jool, use aerobreaking in multiple passes to get into a reasonable Jool orbit, deploy probes to each moon, and map the system in one go. My first pass worked pretty well, but only two of the 21 probes has engines, the rest are passive drop-off satellites. The two powered ships have 3 and 16 passive probes each, as well as being probes themselves for a total of 21. That was the first design. There are places where the design has efficiency, and places where it was inefficient, or at least came up short. I've already unlocked everything in my current career mode, so I have all the parts at my disposal. I'm thinking the passive probes were good, but 16 is too many for any one ship. One ship has plenty of fuel for a single planet/moon mission, in general, so for each planet/moon you need one powered ship, then as many probes as you would like to use to make scanning faster. This is particularly important for planets/moons that are hard to scan without a lot of orbital changes to cover the whole surface. For example, I found moho difficult to fully map without a lot of orbit changes, my orbits tended to follow the same ground path regardless of how high I was, so I got coverage by shifting my inclination. So a basic plan would be to drop off a probe with a polar orbit of 750km for the HI SAR Then another at a 300-350km orbit with the rest of the S.C.A.N line of orbital antennas. Then, depending on the object you are scanning, I would deploy additional 300-350km satellites at varying altitudes or varying inclinations... Whatever it takes to get scan coverage of 100% of the surface. Of course the powered craft also has enough science tools to take advantage of the science opportunities, if you still need the science points. The SC9001, the goo, and the gravioli detectors are great for orbital science collection, log their results at every altitude multiple times. You should be able to pull in ~2000 science points for each object you orbit. My 21 probe ship weighed in at about 100 tons by the time I left Kerbin orbit. I'm thinking the next design will weigh twice that since it will have multiple powered craft, and be carrying a lot more fuel and engines. The passive probes weigh almost nothing.

So of I'm in "orbit" (even though I'm going way too fast to be in actual orbit) why I don't get to see my periapsis flag, I end up having to shift to using different tools, because adjusting a maneuver node for a aerobraking maneuver is impossible without something that can tell me the resulting altitude. I mean I have found work arounds, but in many instances when you are on approach from a long transfer, or a transfer to an object with low gravity, having most of your tools suddenly stop working when you have only seconds to make adjustments and maneuvers is annoying. I mean I understand what you are saying, but it is bunk. The SOI isn't a finite sphere in space that suddenly changes physics close to a planet, it is simply the threshold where the planet is the dominant source of gravitational influence. Every planet's gravity can reach across the entire solar system, the only thing diminishing the influence at that distance is the presence of stronger influences. I understand that in the game, the SOI is a point where the local influence is strong enough to where representations of your relative vector is better expressed locally rather than in the context of the SOI of the sun. But in the game, the SOI of the sun seems to be partially ignored. Speaking of the sun's SOI, how come it doesn't count as an SOI for any of the tools? Many of the tools refuse to work because you and the target must be in the same SOI, when in fact you and your target are both in orbit around the sun. I realize that some this has to do with the modal way different aspects of gameplay are being represented for simplicity. But in orbital dynamics the modes are not exclusive, and one doesn't stop when the other starts. But I guess that there is a lot about the orbital dynamics that have been simplified in order to make the math appear to be able to run in real time. To make people like me happy, the modally exclusive tools that use the word "target" should shift to using the name of the SOI central object, and should continue to work in the new mode, even if their function is now somewhat limited by the fact that the target is assumed. Perhaps not all of the tools could keep working, of course, but they shouldn't all stop working. I get it that for usability, the game needs to simplify physics, and ignoring external factors outside of the SOI is a way to economize the math. But I disagree with the tools simply stop working because their "home mode" is no longer in play. I'll just remind myself that this is version .22, and we don't even have aerodynamics yet... So there is an implied 78% of the software roadmap missing from the game, based on the idea that version 1.0 is the first "complete" version. I found that you can sometimes use orbital tools instead, but sometimes the orbital tools assume you are in an actual closed orbit, so they can do really bad things to you, or apply math that produces the incorrect result. Flying by hand is fine when you have a simple ship and everything is working in real time, but when you are seeing half a second of physics per frame, flying by hand simply does not work for finer movements, the tools are the *only* way to produce fine grained results when it takes .1DV of change, and the 3 seconds it takes for the ship to respond to your throttle up and down can yield results ranging from 0 to 20DV. Only using the tools can I get that small adjustment to get my interplanetary heavy cruiser packed full of parts packaged for multiple moon destinations around Jool into the correct aerobraking altitude, so that I can save the bulk of my mass for the fuel needed for other maneuvers. I can and do use the orbital tools for this, but I have to inspect each action, because half of the time an action will do the opposite of what it is supposed to when my orbit is still open. I realize I'm just a beginner, the people that have been doing this a while had to spend a lot more time without the tools in the first place. I'm also causing some of the problem, because when I fly a ship with 21 mapping probes, my parts count is about 4 to 6 times the parts count that I see people complaining about in the forums. My engineering workstation is able to make the game work slightly beyond to the limits of the software, and I'm exceeding those limits enough that gameplay is difficult. Sometimes after I load my ship in the VAB, the VAB can't finish drawing the walls, but that is mostly for big missions like the Jool mapping mission. Once I complete my first aerobraking maneuver, I break the ship up into smaller sections, and gameplay is normal once again when the mission vessels are far enough apart from each other. But at some point, I may want to build a space habitat, for colonization or galactic travel. Exceeding a couple thousand parts that can't be welded into single assemblies is likely on such a vessel. So I'm hoping that the game's part matrix efficiency can be improved over time. The point is I realize I'm my own worse enemy, and I could avoid some of the bugs and needing the tools as much if I stuck to smaller craft. But there is no challenge if you make everything easy. Not really expecting any answers here...

I'm trying to tune my approach using mechjeb, to a planet I'm trying to aerobrake on, and I can't do that once I'm inside SOI. That seems like a bug to me. You should be able to have the object you are within the SOI of as the target, otherwise half of your tools stop working right when you need them most.

I know the one you are talking about. After finding a couple of the easier to get to anomalies, including a fairly interesting one that probably has an Easter egg, or at least a way to make use of it (I have seen someone using it in a youtube video), this one I sort of gave up on. I did look for it under ground, and didn't see anything interesting. I found another anomaly that way that looked pretty cool, but I didn't really find any science of note, or any other game advantage... But yeah, I blew up a half dozen rovers working my way through the mountains trying to find that thing. I'm guessing it is on top, but you are leading me to believe that perhaps it is more inaccessible than that. I did get a name for it, by flying in low over the suspected location. That is one of the reasons I gave up on it. when I tried to see it from below, I didn't see anything. So it you find it you should pm me and tell me how you did it. The other anomalies I've been able to find by getting sort of close, then using my camera angle to zoom out from the rover over the spot to find it. or to zoom the camera into a hill to get an inside view of the terrain. I look inside of things all the time... So when you get close to an anomaly, such as when you pass low over it when you try to drop in with a rover, your BTDT scanner will usually give it a name. But interestingly the most technically compelling anomaly I found still has no name that showed up on the scanner. At first I thought it was an old abandoned object, until I realized it was still functional. I just don't know how to use it. I guess I could go try to find a game cheat discussion, but it is more fun to figure out things on your own. I've only got a couple anomalies left to visit, but I'm thinking of saving the time to spend on off-world anomalies. But yeah, so you drag all your science gear out to a really interesting find, and your bucket of goo tells you that it is bored... Who has more brains, you or your bucket of goo?

So it looks like the snow-out was unrelated to the grey-out. I reset the map data at one point after I crashed, and after fiddling with my orbits. I was too high to collect data. I guess my inclination change increased my altitude, and I didn't notice... Oops!