DMagic

Now that is weird, the only change made to the SCANsat code was a few access modifiers. If you don't mind, can you try it with this version: -------- Edit: No need to have another version floating around if it doesn't help anything.

Yeah, I know why it breaks it, I just don't know exactly how RPM detects the SCANsat map. There are probably simple ways to get rid of the minimized SCANsat icon without breaking RPM (or changing how RPM works), but I'll leave that to someone else.

I really like this framework idea. It suggests the possibility of other part types using the same frame, so you could have say, 4 fuel tanks, 2 batteries, and 2 of something else and they would all fit together nicely. As for the space in the middle, maybe some kind of label, like a flammable or toxic liquids warning. Cpt. Kipard Thanks for pointing at that bezier curve thing, I've always been making these types of things manually or with an armature, I'll have to try out this method.

I have no idea how Raster Prop Monitors uses SCANsat, from a quick look at the code it's not obvious to me. But that said, the default behavior is unchanged, the official version should still work as it always has and if my recompile is breaking things I can take a look (there seems to be some confusion over which version of .Net is being used by SCANsat and RPM's SCANsat module). Some changes were necessary to remove the minimized icon from the small map and to prevent a small window stub from remaining once the green probe icon was removed. There is probably a way to do this that doesn't break RPM integration, and anyone is free to figure that out and release it themselves.

Here's a picture from B9's article on creating the new space center. The sky is obviously just a backdrop, and from some of the other pictures it looks like only the launchpad and the structures around it are actually included.

Is that all three fuel types at the same time, or something that can take Mono or Liq Fuel/Oxi, but not at the same time? Or is it whichever we choose?

Oh yeah, they're pretty much all like that for Dres. I actually haven't considered communications parts before. That might be a good idea. Another idea is for a laser range finding mirror like the ones left on the Moon by Apollo astronauts.

Actually, a better solution is to try out StupidChris' Advanced Animator. It should work basically the same as ModuleAnimateGeneric but it gives you options for editor animations, among other things.

Definitely. The integrated GPU on that chip isn't half bad, so it should be ok. BuGLe is the only linux benchmarking tool that I know of, it can be a little tricky to use, but it seems to work well enough. You should be able to use the new, 0.23.5 version of the rocket in 0.23, but it might give you problems (saying something like "this craft doesn't match your version of KSP"). If you don't already have it, here's a link for the 0.23 version: http://www./view/v8ctnadz540l7d9/CPU_Test_600_v23.craft

Tweakables, at least animation previews, are very easy to setup in the VAB/SPH, but they do require a plugin, there's nothing in ModuleAnimateGeneric that can handle it (the source code for my parts is available, the editorDeployEvent(), as is a number of others'). It's also easy to make the changes persistent, so that a door opened in the VAB stays open when you launch. It's probably not worth making a plugin only for this purpose, but if you need it for something else it's easy enough to add on.

It's not about lining up a launch window to rendezvous with Moho, it's about launching at the ascending/descending node between Kerbin orbit and Moho orbit. If you do this right you can launch into a high inclination (20o or so), burn retrograde with respect to the sun, and come out of Kerbin orbit within a degree or so of Moho's inclination. The actual rendezvous is easier to setup later, more like an orbital rendezvous for docking, but you save the hassle of having to make a huge inclination change while in orbit. I'm not sure what the actual delta-v savings of launching like this are, but I've done it many times, and I think it's the simplest way to get to Moho. Of course it doesn't really matter so much for other planets, but it's still useful.

Yeah, it always bugged me that the timer didn't match up to Kerbin's rotation. It does seem like this should be something you can change in the in-game settings menu though. One thing to note is that a year is not, as the settings menu says, 426 days, it is 426 days and change. I don't know if they have any kind of leap-year system implemented, but as far as I can tell all of the orbital parameters are unchanged from their pre-0.23.5 values. So if there isn't any leap-year system the dates might eventually be off by a few days.

Are you importing the animations? Sometimes Unity will add a huge amount of unneeded keyframes when you import an animation, even on objects that aren't moving.

That's an untextured Blender render, so it's a little bit difficult to see what's going on. But basically the cover is made of nine wedge shaped pieces, each one moves down slightly towards the center then rotates back, as the first piece is rotating the next piece moves down and so on. That's the part of the model that needs the most work (and I've already spent well over half of the time on that model building the cover and animating it), but it will probably look a lot clearer once it's textured.

The part I showed above is actually another type of imager. I modeled after the Cassini imaging pallet, but removed most of the visual wavelength telescopes. I have some vague plans for including some type of actual imaging for this and the regular telescope, but that probably won't happen for a long time.

This should work, but it's not going to have anything to do with the regular drill animation. You'll just be able to click the collect button and get a report. Edit: well that was a waste of a 1000th post...

Another thing to add. If manually resetting the experiment is necessary you should be using ModuleScienceExperiment.DumpData() (or maybe the IScienceDataContainer interface's method) not ResetExperiment(). The latter is used for throwing out data, either through the experiment results page, the reset Event/Action, or the EVA reset. Dumpdata() is what is called after you transmit something and it will properly set the experiment as inoperable if need be.

The FOV is limited to 20 regardless of what you put into the cfg file

This happens because biomes have fuzzy borders causing the two to bleed into each other, which the game interprets as being another biome. So pretty much anywhere that the "shores" biome meets "grasslands" you'll get a strip of "tundra", but it happens in lots of other biome borders too.

How did you measure this? I was curious about this, and I actually do use some of these values, so I decided to see what the game spits out when I ask it. I told it to write out some of the orbital and physical values for each celestial body, this is what came out for the sun and Kerbin. Sun Mass: = 1.75656696858329E+28 Sun Radius: = 261600000 Kerbin Mass: = 5.29157926281091E+22 Kerbin Radius: = 600000 Kerbin Semi Major Axis: = 13599840256 Kerbin Semi Minor Axis: = 13599840256 Kerbin Apoapsis: = 13338240256 Kerbin Periapsis: = 13338240256 Kerbin Orbital Period: = 9203544.61750141 Kerbin Inclination: = 0 Kerbin Eccentricity: = 0 Obviously the sun doesn't have orbital parameters. But if you were to just glance at the values for Kerbin you might think something is wrong, the apoapsis/periapsis is significantly less than the SMA, which shouldn't happen with 0 eccentricity. But then if you take into account that apoapsis/periapsis is measured from the surface of the sun, not the center, you come back out with the correct numbers; 13599840256m for the SMA, and apo/peri. The orbital period from in-game matches the old value and when I calculate it myself I get exactly the same numbers. So either the game is spitting out incorrect values, they've changed the gravitational constant (which seems unwise), or maybe they're just fudging the numbers displayed on the MET timer.

I would be updating this but the forum doesn't seem to want to let me. It's probably safe to say that most of the mods listed won't have 0.23.5 specific problems except for those already noted. Parts mod should be OK except for those with incorrect connection node sizes.

The only-works-once problem is, I think, due to that "true" at the end of the "[KSPAddon" line at the top. I think that should be false, so that it loads up every time you go to the flight scene. The duplicate science problem might have something to do with how you're looping through every part to find containers and experiments. It seems like it might choke if it found the experiment before the container, or it might find multiple containers and send science data to different containers based on the part order of your vessel. I'm not really sure why any of this would send duplicate results though. Maybe you also need to clear out the data[] array after each transfer, too.

Ok, try this out: http://www./download/u5egmogu8nisctq/SCANsat_Toolbar_V0_2.zip Version with updated license info if anyone is interested (otherwise the same as above): http://www./download/eejxt14ae2hrcy8/SCANsat_Toolbar_V0_2_1.zip It should only load when your active vessel has a SCANsat part on it (anything with the SCANsat module should work if you added it to command pods, probe cores, etc...). There are three buttons, one for the main menu with options for all four windows, one for the big map and one for the small map. If you don't want any of them just turn them off in the toolbar config. Installation is the same as before. You must have the latest official version of SCANsat installed (or one of my two releases). Copy the four files from the SCANsat folder in my package to the main SCANsat folder, overwrite the existing SCANsat.dll file and make sure the three icon files have been copied over. The main SCANsat folder must be in the correct location for the toolbar icons to function (/Main KSP Folder/GameData/Scansat). As with the last release, this is provided as is, with no guarantee of working or compatibility. I'm not taking requests or suggestions and I have no further plans to modify the SCANsat code. If anyone finds any bugs I can take a look and try to figure it out, but I make no promises. Blizzy78's toolbar plugin must already be installed or this version of SCANsat won't work. The only way to open the maps/windows is through the toolbar buttons. *Warning: Does not work with RasterPropMonitor

You probably need to go back to a clean install and try this again with the last official version. This kind of thing probably doesn't have any other simple fix. People can pick and choose which icons to display on the toolbar right? Maybe I'll just put in buttons for the menu, the small map and the big map. That way people can use whatever combination of buttons they want. Maybe, though I'm a little reluctant to do anything unless the mod is actually broken in some way. And also, SCANsat's code is so cleanly laid out that adding in toolbar support is trivial. Protractor's code looks like it's almost all dumped into one main file, though it's still probably pretty easy to setup toolbar support.

Is this a new thing, or was it just never spotted before?