DMagic

To be clear, nobody can run the game with 1000+ parts and not have a significant drop in performance. Some computers can handle that amount better than others, but everyone slows down at that level, the difference is how much people are able to tolerate playing at such low framerates. That said, the CPU is the biggest factor for KSP. Newer generations of Intel CPUs handle it KSP about as well as anything, the i5's give the best compromise between cost and performance. Xeons and i7's don't really offer anything that KSP can take advantage of. You might want to check the ocean terrain tweak thread also, that might help when you get low performance during reentry and while looking down towards Kerbin's surface: http://forum.kerbalspaceprogram.com/threads/43253-Default-Terrain-Quality-Without-most-of-The-Lag%21

I'm not sure that decouple is the right function. I think that is what is used when a docking port is connected to something other than another docking port. Undock sounds like the function you're looking for, though I'm not sure if changing values for that in the .cfg file will work either.

Just imagine the possibilities if we are able to make user generated contracts. You could specify where and how you want the deed done.

I'm not sure if it's been mentioned before, but you have a typo in the Eve.att file. Where it should say "Poles" it says "Ploes" in the Basic folder of the 1.4 download. It's listed correctly in the crowd sourced file though.

You mean that you just want to change it from a .txt file to a .cfg file? Just open it in notepad, go to file, save-as and type in sciencedefs.cfg (or whatever you want to name it, just add the .cfg at the end).

They always show up at different times in different places, but eventually they get posted everywhere.

There's a bit more info in the other thread, but here's a newer shot. I don't care for the way the lights look, but otherwise the modelling, texturing and animating are basically complete. I'd like to get some particle effects working, but I'm not going to delay too much just for that. It's meant to be a multiple use part; it can store three samples for return and transmit up to six. My plugin seems to be working, I can store multiple reports in a single part and recover them, and I can transmit and collect more results without affecting the stored results. I still have no idea what will happen when this part meets a science lab. There are lots of other rough edges to work out, and I need to get all of the animations working together nicely, but it should be doable to make the part work how I want it to.

Thanks, ThePsuedoMonkey. Were you using the old, pre-0.23 version of the rocket? Your performance levels look ok, but the total run time seems too high for that kind of framerate. I can still use the results for the CPU comparison chart (whenever I actually put it up again) because it doesn't affect performance during the first stage, it just makes it difficult to compare the framerate graph to others.

Thanks, pictures are always welcome. Nothing says space probe like a giant boom (6m I think, assuming the scaling works right) sticking out from the side. My new part is coming along. I might try to release it sometime this week for testing in the WIP thread. I'm not sure about how the plugin is going to work, and it will probably have some issues that need to be worked out.

Try out hoojiwana's RLA stockalike parts. It's a really great probe part pack that seems to fit what you're looking for. They aren't stock, but this is the kind of part pack that I can see being added to the stock game, maybe not all of them, but at least some of them. And I hope they do get added at some point, they really make probes much better.

Do you mean making it so that an image of Duna from Kerbin orbit, or the Mun, or Eve would all count as the same experiment, making it so that each planet could only be imaged once (or perhaps a more limited number of times)? This is possible I think, just not when inheriting the ModuleScienceExperiment like your plugin does. You would need to use IScienceDataContainer and recreate the experiment that way. Using this method you can point the module to whichever planet you want the science experiment to apply to. Normally you would just use something like vessel.mainBody, but I don't think there's any reason why you couldn't just always point the experiment towards Kerbin, so that every experiment thinks you are in Kerbin orbit, regardless of where you actually are. You can check out the SCANsat or the Tarsier Space Tech source (or mine if I can ever get it working right), those are the only two that I know of that use this method, but there are probably others. It's a bit more complicated to use IScienceDataContainer, but it gives you a lot more flexibility in how you can set up your experiments.

It sounds like you're looking for something like Infernal Robotics. It has hinges and extendable parts that let you launch a compact craft then deploy it later.

Part count based performance is highly dependent on the CPU, and the physics calculations used are limited to a single CPU thread, so high end, multi-core CPUs don't perform as well as you might expect. There are also some graphics issues that can cause slow downs, the terrain thing is one, but you could try lowering the AA settings too. If you want to get a current part count for your vessel go into map mode and click on the little "i" on the right side of the screen. This will give you some info about your craft, like part count, mass, etc...

I've been working on my next part, it's meant to be a sample core drill used for biological analysis. There are already plenty of surface sample experiments, drills, scoops and so on, so I'm making this part more specialized. It's based on some of the Viking experiments and the proposed ExoMars rover. The drill is made with two primary animations that play based on the part's orientation with respect to the surface. This way you can use it on landers or rovers without looking weird. The orientation check in my plugin seems to be relative to the surface, not the vessel or the terrain, which I think is the best way to do it, though this cause problems on steep hills. It has some issues, and I need to test it more, but I think it works pretty well. I'll add an animation like this to the laser too if this works out. I'm also trying to change the way science parts can work. Instead of running an infinite number of times or only once I want this part to be usable for a limited number of times before being returned or reset. Currently I have it set to allow for six uses with indicator lights showing how many remaining experiments can be run (the primary indicator lights aren't animated yet, they only show green). There are also three sample containers that can be used to bring back samples for full science value. Storing samples also counts against the six experiment limit, so you can store three samples and transmit three more, or transmit all six, or any other combination. The sample containers in the picture above aren't complete, they are just untextured boxes, and they need a filling-up animation (some of the other animations need tweaking too, as you can see with the drill tip sticking out). The size of the part is comparable to the laser, it's a bit bigger now, but I'll probably resize it a little so that it fits better on a rover body. Other than the sample containers the model, texture and animations are mostly complete, it only needs some minor adjustments here and there. The plugin needs a lot more work though. I can't get it to work right by inheriting the ModuleScienceExperiment like the other parts do, I have to use IScienceDataContainer and recreate the stock science module functions. This is because I need to intercept button pushes on the experimental results dialog page (the thing that shows the science report and lets you transmit or keep the data) for my limited-use setup to work correctly, and I can't find a way to do that with ModuleScienceExperiment. I also need to figure out a way to store multiple results and still allow the part to be used. I'm thinking that maybe I need to a make a separate module, maybe using ModuleScienceContainer, and transfer stored data from my primary module to the container module, that way I can store multiple results and continue collecting more. And I have no idea how any of this will react when it interacts with a science lab, that will require a lot of testing and figuring out. More updates to come as I progress with this part.

Yep, the one in his signature.

The temp scan works from different biomes on the surface or flying low, but not in space or flying high.

I have a part that I want to have play different animations based on its orientation. So one animation plays when the part is placed on a horizontal surface, like a rover body, and another plays when placed on a vertical surface, like the side of a fuel tank. I haven't seen this done anywhere, but I'm wondering if there is some standard or common way of determining a part's orientation. So far I've come up with what seems to be a mostly working solution. [KSPEvent(guiActive = true, guiName = "Deploy Drill", active = true)] public void startDrill() { findrot(); if (rotz < 30 && rotz >= 0 || rotz > 330 && rotz <0 || rotz < 210 && rotz >= 180 || rotz > 150 && rotz < 180) { deployDrill(verticalDrillName); } else { deployDrill(animationName); } } public void findrot() { rotx = this.part.transform.eulerAngles.x; roty = this.part.transform.eulerAngles.y; rotz = this.part.transform.eulerAngles.z; } Basically, I have a part with two animations on it and an animator method that can call either one of them. The findrot method determines the part's rotation (seemingly in reference to the planet's surface, not the vessel, or the terrain) in Euler angles. Then I check if the part is within a certain range. The z axis (that would be the east/west axis on the planet's surface) seems to be telling me what I need to know. I've given the method some range, so that anything within 30o of vertical plays the vertical animation (vertical parts have a rotz of around 0 or 180o depending on which side of the z axis they're on, horizontal parts are around 90 or 270o). This seems to work, with one obvious problem. Any part directly lined up on the z axis returns a value of 0o, so I lose the ability to determine orientation based on the z axis in that case. This is easy to do when you're testing it on the launchpad, but not so easy in real situations. So I'm thinking that I could leave it that way, or make a special case for rotz == 0, and do a second check using quaternions, but I'm not sure I'll be able to figure out such a simple method for that. Does anyone foresee any other problems with this method? Or does anyone know of a better way to do this (or maybe how to check this using quaternions without giving myself an aneurysm)? I'm also not sure if something like an Infernal Robotics hinge would play nice with this or not.

From what I understand this is relieving mostly graphics related CPU slow-downs. The CPU has to feed certain info to the GPU, which means that low power CPUs can really bottleneck a high power GPU. The CPU bottleneck in KSP is very different though. It is primarily the physics calculations that are slowing things down, and until Unity gets around to updating its severely outdated version of PhysX (the fact that this technology comes from Nvidia further complicates things) I don't think we'll see much improvement in this area. Moderate increases like we got in 0.23 might be possible, but I don't think Mantle would really have any effect in relieving the kind of CPU related issues that KSP and Unity have.

You'll definitely need to make separate animations for each door and put them all on the same part. There are a few ways of doing this. Making animations in Unity would probably be the simplest way, I think there are some tutorials on these forums about doing that. It's also possible to import multiple animations from Blender, if that's what you're using. Unfortunately I don't know of any simple way to do this. You can do it using armatures (using invisible "bones" within your model to rotate objects), but that isn't always so simple, and I've had some issues with importing armature animations into Unity. The other option would be to create your model in Blender with all of the doors closed, then make the animation for one door only. Import this and the single-door animation into Unity. Then do the same with the other two doors. You can then copy the animation clip from each model in Unity and combine them into one model. I'll try to add a picture demonstrating this later, it should only take one to cover it. That way you would have a single model that could be exported into KSP with three different animations. Then you can move on to figuring out how to get them all working together.

All you need to do is click on the _EmissiveColor window and choose the color you want and the emissiveness (?), the lowest slider in the window, which should be at 255 (max) by default. So if you don't want to change the color, or change the brightness you shouldn't need to do anything beyond setting the shader.

I know that the stock parts all behave like that, but it really doesn't make any sense in this case. The fluxgate magnetometer, the one in the middle, records current moving through a wire. The helium magnetometer on the end records infrared light absorption. Neither of these measurements would be any different if they were retrieved by hand or by transmission. The same goes for the other instruments. Surface samples would obviously count for more if they were returned, but the laser doesn't actually collect anything. It only records light emission from the vaporized samples. I will consider lowering the science values though (I've already lowered them once), as those numbers can really pile up, especially when they start adding more biomes. And my next part will be much more limited and will return higher science values for returning the samples. Though I plan on making it more versatile than the stock system, not just use once then require a reset. More about that later. Thanks. The magnetometer was the reason I started this mod. I wasn't happy with the two that were already available so I decided to make my own. The other ideas came later.

Are you talking about using a plugin? I guess you could try multiple ModuleAnimateGeneric modules with multiple animations, but that doesn't seem very elegant and I don't know if it works. You also don't have much control over how animations work with the generic module. For a separate plugin I think the easiest way would be to make three animations and have three [KSPEvents] to toggle them, and presumably something to make them work on EVA too. It's probably also possible to make one really long animation with all of the possible door combinations then make your plugin call the animation at different time points, but separate animations is probably easier. You can check the source code for my BTDT scanner, or a find some other part with multiple animations (Kethane has some parts, and Majir released a code snippet related to setting up animations that might help) to get an idea of how to setup the plugin. My part and the source code is available here: http://forum.kerbalspaceprogram.com/threads/64755-WIP-DMagic-Orbital-Science-New-Science-Parts-V0-5-%281-31-2014%29

I'm thinking that money and contracts could effect mod packs even more so than stock. I assume they will never make stock career mode too challenging, but a lot of big part packs don't have any extra science instruments. If Squad adds both cost for using parts, and cost for researching individual parts in the R&D center, then progression through modded tech trees could really be effected, more so if they are using higher nodes than those available for stock parts. What's also interesting is the possibility of opening up contracts to mods, though I've never seen this mentioned anywhere. Instead of using parts only to collect science you could also use them as a basis for contracts (i.e. go to planet X with such and such science instruments and return, or stay for 1 year). That could make parts like mine serve a dual purpose. It'll be interesting to see what they come up with.

I don't think KSP actually supports Unity 4.3.3, I know that it works most of the time, but there are obviously still problems. They've mentioned in the dev notes that they are still testing the latest version. So my guess is that we'll have to wait until at least 0.24 before we get updated part tools.

That looks like a death rattle, at least that's what I call it. Supposedly having parts clipping into each other can cause it, but I'm pretty sure that I've seen it even when being very careful that. Sometimes just reloading can prevent it, sometimes there is something inherently unstable about your design and it will always do that.