Ruedii

It would be good if Achievements are put into the game to do so using an abstracted library. This way all the different platforms, including Squad's own KSP Forums could be supported equally using the same set of achievements. The current list of online achievement platforms is growing, and we all know how the Squad devs feel about locking into any one achievement platform, due to their response to the request to have Steam Achievements. The best solution would be to call any and all achievement libraries set up by the user from the main Squad achievement library. This way you can have achievements for every distribution platform, without having to change the game binary. Furthermore, mod developers could utilize listeners to this abstraction library to provide all sorts of added functions, for example, the Final Frontier mod could have it's code greatly streamlined, or a Stat tracking mod for multi-player servers could compare the various stats of players and even publish them on the server's web-page. Of course, I'd also like to note, that no official achievement system should be made until after the game is at it's final state. This is because the balance of the game will likely change drastically before the final release, as it has already.

I was thinking. You might want to replace the NASA logos with the "flag decal" stamp that uses whatever the player's mission flag is. I definitely like those smaller nuclear rockets that have built in thermoelectric generators. Is there a way you could make them run on just liquid fuel or a custom fuel just like a real nuclear rocket? This might require real-fuels or KSP Interstellar to get the ISP Curve right, and you will definitely need custom tanks. As a note, did you make sure the generator in the nuclear rocket was a generator element, and not an alternator? This way it's power generation is fixed rate, not based on fuel consumption.

It was a tough choice on my vote. I ended up choosing Cpt. Kipard due to balancing blending well with stock, while maintaining excellent style. The following ones were on my "short list" with reasons stated: StarVision: Great stockalike design, and the bottom attachment nodes are a nice touch. Themorris: Nice design, very stylish Orionkermin: Pretty and shiny. BahamutoD: Simple and understated, while maintaining detailed styling. Also, it fits on a probe. I notice that by the votes my short list matches with other people's.

It would be a cool mod to replace the new NASA-Mission in-game asteroids with these things.

We need a grumpy cat one. Also, make sure the backgrounds are all transparent so they work as decals in 0.23.5!

Is there a way you could make it automatically add other fuel types by detecting fuels added by other mods? The other thing, is there a way to make a procedural service module that has battery charge, RCS and Fuel/Oxidizer?

Are these working with the latest update to Procedural Fairings?

Is there a way you could make a "blow off" cover over the nozzles on the perfectron separation boosters? (A cover with a red spot over each booster nozzle with text that says "Warning: LOADED") They are nice as they are, but that would make them even better.

First the "nuclear powered" one should be a nuclear decay thermoelectric. (You aren't going to fit a full nuclear reactor in a rover, no matter how tiny.) It should have either a heat sink-ridges on the surface or a perforated surface because of this. (I recommend the perforated surface.) This can be implemented with parallax maps, or normal maps, so long as the surface details aren't too deep. Second, I agree on making one with more battery capacity than the stock one and a built in probe core. Additional things to throw in are science storage and a wielded on pilot's seat.

It would be nice to make electrolysis capable fuel cells (can turn the water back into hydrogen and oxygen), chemical conversion cells (can convert liquid fuel, or if-applicable kethane into hydrogen and convert oxidizer into oxygen) and auxiliary water, hydrogen and oxygen tanks as well as give a right-click-menu command to "dump" excess water into space, similar to the fuel-transfer function.

Yeah, I'm getting this too. The debug window shows a null-reference-exception when you attach certain engines, and then the delta-v stats window stops updating. p.s. Sarbian said it's fixed in the most recent update, so I'm going to try that now.

Pulling is definitely optimal, as having the center of mass towards the back, it reduces it's effect on the craft if it is not on center. You could try dotting it with a large number of "control tugs" These are relatively small tugs with RCS ports and reaction wheels. You can also put parachutes on all these control tugs if you want to try to bring the asteroid down to Kerbin.

What do you think about the other S2 crew tanks. You could theoretically use the same interior under the basis that they are "multi-cabin." The other option, if it is possible, is to simply modify the design.

Could you try doing a 3D plot of thrust, weight/mass and ISP? Also make sure to place both ASL and Vacuum ISP. This would give a clearer picture. Additionally, ones that have clear advantages and/or disadvantage should have that noted. For instance, ones that cannot be place as a second stage, or the case of the RAPIER which can substitute air for oxygen.

Your modern smart phone has more processing power than most super computers from the 80s even. Too add to that, the average gaming rig has more computation power in it's graphics card than a cutting edge supercomputer from the turn of the millennium.

On all these notes for making improvements. According to the license you don't need permission to fork or release third party patches, however you need to give attributions and not imply that your patch is the official release. So, making a "Taverious' Pizza and Aerospace Continued" fork while Taverious is too busy is not an issue. The same goes for B9 Aerospace. (I imagine the same team can do both.)

Thanks a lot. I really could use the gimble range control, as I've had issues with engines with wide gimbling range interacting badly with MechJeb.

Glad to hear they fixed the bug. In that case, have you compared uncompressed or minimally compressed PNGs to compressed PNGs. The loss to CPU time may not exceed the gain in disk transfer reduction on minimal compression, but heavier compression may certainly cause problems.

I noticed on some of the threads in the plugin info pages that loading of PNGs is a little slower than it should be on KSP. Either switching to uncompressed PNGs or TGAs for the cache should reduce load time significantly, as well as reducing the memory footprint when loading. (Decompression of PNGs can be a memory heavy operation.)

Yes, also note that Kerbin years also have a different time scale.

Do you need someone to write module manager files so this can be installed in it's own directory?

It would be nice to have whatever April Fools joke you installed available as a toggle permanently. (Yearly adding an additional prank module every year is always fun, so long as the modules are small enough not to cause bloat.) p.s. For a nice prank next year: A giant Jeb Kerman Head parade balloon pops out instead of the parachute.

Yep, All the mod makers will have to be adjusting their settings to balance for the new stress physics. Otherwise, many things won't break, and others won't break when and where they are suppose to. (For instance, you could wind up ripping your rocket in half instead of tearing off a solar panel.)

One thing to note on TGAs and PNGs: KSP does not support palleted TGAs and PNGs. When I tried using palleted ones in the past, it caused massive graphics corruptions. I have not yet tested 16bit or 15bit true color, however I wouldn't hold my breath on those either. In any event KSP imports all images as 32bit RGBA, so it doesn't save memory. However, as a note, RLA compression on TGA images WILL reduce load time, as the decompression cost on that algorithm is next to nothing, and it saves on hard drive access time. PNG compression will not, under any circumstances reduce load time as it's decompression is far higher cost. Even when the slowdown issues are fixed, it will be slower to load than TGA. If someone would like to report tests on uncompressed PNGs (which are very similar in format) or if NovaSilisko or any other person with insight into the inner process of KSP's texture loading could fill in the details on the bottleneck, I'm sure it would be useful. This is especially so, since many tools (such as many Linux image viewers) are unable to load TGAs directly as they are considered archaic compared to TIFF.

Thanks for the clarification, so it's suppose to go on the pod, but not the hatch. You might want to add that detail. As a note, what do I do about it being visible on the craft since 0.23. I was thinking it might be ideal to simply reduce the size until a better model can be built. That can be done in the config file. That might be something that it would be worth learning modeling to build a model for. The question is what it should look like. I'm thinking a small module with a compressed air cylinder and a big warning label.