jofwu

I didn't see much more info on the website. Could someone lay out more of what this mod does exactly? What data can it track? Is the data only visible on the in-game graph I see or can it be exported to a spreadsheet for further use? I'm not a big fan of sticking extra parts on my ships for this sort of thing... I assume that the mod essentially contains a .dll for a module that records the data along with a part that uses this module. So is there any reason I couldn't use a MM config to just put this module into all command pods? Thanks!

Could anybody help me out with some pointers? (Having trouble designing something stable with the dev build.) I wanted to design a simple subsonic airplane to complete easy survey contracts near KSC. I'm relatively early on in a career so I don't have ALL the parts to work with. But I have the basics. My plane's body wasn't much different from Nerd1000's in this post. It was perhaps a bit shorter, and with the mk1 cockpit in front of the mk1 inline cockpit (wanted room for a passenger). So... the two cockpits at the front followed by 2 or three tanks, one of the inline air intakes, and the basic jet engine. A pointy cylinder with an engine on the back. From there, no matter how I positioned my various wings and such, I just couldn't get the thing to be stable. I've used FAR in the past and never had so much trouble. The biggest problem was that I couldn't get my pitching moment coefficient to be negative. Kept wanting to do back flips when I tested it. But I could go so far as to put the wings at the tail end of the craft and *still* have this problem. Am I missing something?

Looking for some help... I thought I'd give the new pre-release version a try, and ran into a brick wall designing airplanes. I never had this much trouble with FAR before... I couldn't get all of the stability derivatives looking decent for the life of me. So then I thought I'd grab some of the FAR airplanes from the current 0.90 compatible version and see if I could find some guidance. Turns out they're unstable as well. What gives? Surely the new FAR is not going to be so realistic that the old FAR ships don't work... The numbers look sad, and I tried flying a few without much luck. Can't think of any mods that might conflict somehow... Obviously I don't expect the pre-release version to work perfectly. But it sounds like other people aren't having this problem. Have I done something wrong? I grabbed this download and put the FerramAerospaceResearch folder into my Gamedata folder. I've got the current versions of ModuleManager and ModularFlightIntegrator. And if I'm just crazy, can anyone point me to a good guide on how to design airplanes for FAR, and how to make the most of the info it gives you? I only have a weak grasp of what the stability derivatives say, so I'm not sure how to correct the red ones.

Thanks for reviving this. I've missed it dearly. Wanted to point out a bug. I use it on the stock toolbar rather than blizzy's. Works great, but it shows up on the game's main menu screens.

Thanks for the pointer! Another question... Anybody know of any code which puts the TAC LS parts into a separate category? (still under "functions," not one of the user created custom things) Like what RealChutes does? Sure would be nice to declutter that utilities category list...

So... Question... Has anybody ever given thought to the possibility of some basic daytime city textures? I'm imagining a copy of the city lights code, just applied during the daytime instead of the night. Or perhaps always applied and just placed beneath city lights? You could take the city lights textures being used as a pattern (for where cities supposedly are) and just replaced the coloring with a cookie cutter satellite image of Manhattan or something? I don't think those textures are super hi res- I'm not imagining flying above birds eye views of real cities and making out buildings. I just think it might be fun just to see some urban looking browns and grays in place of the lights when the Sun's up. Doubt you could really make them out from high up, but pretty sure that's true for the ISS as well. Is this as bad of an idea as I'm afraid, or is it a possible and/or interesting concept?

Can anybody help me out with a MM config to put TAC LS resources in all parts that hold crew? That is, resources plus room for waste resources. Haven't played with MM configs in a while to remember how, and I'm not sure what amounts would be balanced. I think the Hitchhiker doesn't come with any. And I use Stockalike Station Parts which include many crew-holding parts but no resources. I prefer to store TAC LS stuff in these sort of parts and only resort to the "tanks" when necessary. As an added hurdle, I suppose I don't want to write over parts that already include TAC LS resources, and I suppose the in-line airplane crew parts should be limited or skipped. Any help would be appreciated.

For anybody who doesn't understand what he's talking about: all objects have a "specific heat" value, which tells how much energy you need to increase the object's temperature one degree per unit mass of the object. So maybe, for example, it takes 100 Joules of energy to increase a 1kg object's temperature by 2 Kelvin. It has a specific heat of 100/2= 50 J/K/kg. It takes 50 J to warm up 1kg by 1 degree. But what if we have a part made of this material which is 10kg? It will take ten times more energy (500 J) to heat the object by 1 degree. This should be fairly intuitive. When KSP calculates part temperatures it uses the FULL mass of the part. The problem is that damage from reentry heating doesn't work this way. You don't have to heat up the entire pod to a high temperature for it to blow up. You just have to heat up one little corner on the outside, and when it fails it will take more out with it. Reentry failure is generally an issue of local (small area) damage. Consider how Space Shuttle Columbia completely disintegrated because of a tiny bit of damage on one wing. The shuttle didn't fail because the entire shuttle got super hot. It didn't fail because the entire wing got super hot. It failed because one little exposed corner got too hot. In that case, you aren't interested in the mass of the full "part." Just the mass of this one little area on the surface.

How well are these balanced as far as tech/price go?

The fairings work properly?

Can anybody compare this mod with the new stock situation for me? I don't understand the technical details of either enough to know what I want. Maybe this isn't the best place to ask considering I'm sure you're all big fans of RealChute, but I'd prefer not to clutter my VAB parts list if I don't feel like I need to. I've used RealChutes in the past, so I'm sort of familiar with the mod. After two brief tests last night it *seems* to me that stock chutes (in stock atmosphere) open much more smoothly now, so that fixes my former biggest complaint about them. Has anyone else found this to be the case? All of the other RealChutes features might drag me back either way, but I just wanted to check. The interface always felt awkward to me, and they never seemed to be well balanced with stock chutes in the past.

Anyone tried this in 1.0 yet?

Well, for my purposes I was just trying to give the "No" crowd the benefit of the doubt. But I do think that it's possible this poll is misleading. It's not exactly scientific. For all we know, the link has been posted in places where "Yes" people are more likely to see it. For all we know, the people who would vote "No" might tend to be the sort of people who just goof around on their own and don't frequent online KSP communities. And their voice matters too, even if they're not vocal. My point is merely that we don't KNOW how accurate this poll is. That said, it's probably dead on, and I was being conservative.

If people want unrealistic aerodynamics (which allow for wild, unrealistic ships), then let the community build a mod for it. Those of us who enjoy realistic aerodynamics have depended on mods (FAR/NEAR) for quite some time now. It hasn't killed us. Even after Squad makes their changes, no matter what they do, there will probably still be a group relying on mods for even greater realism. That's okay. According to this poll, 10-15% of players want their old, crazy, unaerodynamic ships to work. That's just the active community... Let's be generous and say that this number should be 25% when you include people who won't come into contact with this poll. That means 3/4 of KSP players are completely fine (if not hopeful) if Squad implements an aerodynamic model which makes the old, silly contraptions obsolete. That tells me that the community wants realistic aerodynamics to be stock. And this is consistent with everything else in KSP. Are Kerbals quirky creatures that make you smile? Yes. Does stock KSP have a junkyard space center feel? Yes. Are crew reports funny? Sure. Are the contacts and strategies ridiculous sometimes? Definitely. But the physics in KSP are as good as it gets. The orbital mechanics are spot on. You can pull out a physics textbook to help you with the game. Why should this be different for aerodynamics? Shouldn't we expect something just as "real"? The primary concern seems to be "fun." And I think that's a very noble concern. KSP is fun. KSP is a game. I don't think anyone wants for KSP to become a hardcore space flight simulator. But that doesn't mean it can't be realistic and fun! Just look at the rest of the game as it already is. Within reason, space flight works like it should. It's realistic. It's physics. Does this prove difficult for new players? Sure. Does it prevent you from flying around the solar system willy nilly? Yep. But that has never stopped people from having fun. Heck, for many I believe that the realism is what makes KSP so fun and rewarding. Would a realistic aerodynamics overhaul change the game in a way some people dislike? Yes. But it's already in a state that people dislike, and those people have gotten along just fine with mods. Mods are one of KSP's brightest jewels. They support all kinds of functionality that most players don't care for. If you want unrealistic aerodynamics, that's totally okay! It's just that you might need a mod to get things the way you want. And there's nothing wrong with that. Meanwhile, it's time for KSP's aerodynamics to meet the standards that Squad has set for the rest of the game. If we're talking about fun, I for one believe that realistic aerodynamics would make it more fun. If a relatively small handful disagree, then let them find their fun in the form of mods (which the "pro-realists" have been doing all along, and will continue doing if the changes aren't sufficient).

Fuel Balancing They made some sort of change to this for 0.90 didn't they? Haven't heard much talk about it. Anyone know the details? Wheel-Brakes and Motors You can't already do this? I could have sworn that I've turned brakes off on my front wheels before... Action-Group-Timer / Connected Actions Interesting thought. I REALLY think there ought to be a stock way to edit action groups on the fly. Biomes in Mapview As much as I love ScanSAT, I think it's beyond the scope of the stock game. I feel like your concepts here are a bit more complicated than Squad would like. It would be nice if there were a button (right next to the info button) that could toggle a biome overlay in map mode. Maybe it would only overlay the biomes that you have "discovered" (i.e. performed a biome-specific experiment in). That way it doesn't reveal all of the mysteries and surprises right from the start, and you have something to work for. But you can still easily see where something NEW might be. "Object of Interest" in Mission Control Here here! New folks especially aren't going to know the names of parts, and it can get really unnecessarily confusing. Kerbal Professions Completely agree that Scientists and Engineers are underpowered! I do think that Scientists should be the ones responsible for cleaning Goo and Materials Labs though. There's plenty of other great ideas for Engineers, and that concept is in the realm of Science I think. I'd like to see the introduction of an experiment or two that requires a Scientist or two to stay somewhere long term. It would be a heavy part. Heck maybe, the lab could take on the role (it's also underpowered in my opinion). It could either generate a bunch of Science at once or small amounts over a long period of time. It should encourage space stations and bases. Perhaps it could be used to clean up leftover science? Right now you can go somewhere, say to the Mun and knock out some big experiments to get a bunch of science. But afterwards you have leftovers all over the place. And it's not particularly fun to go back and redo old missions (for less return). Why not plop a base down and let it scrap together whatever you missed over the course of a year? Maybe it has a range, so that it can reach every biome within a certain radius. Love the solar panels idea, though I think spare parts might go too far. I really really wish they had the ability to "weld parts together". In other words, construction out in the world. They can't bring up parts and place them wherever, like KAS. I just want to be able to bring two ships in close range of one another and then permanently connect them. This is sorely needed for some crazy late-game interplanetary business. Docking ports and all of the mod options I've seen are too flimsy or awkward. I want to come up with a concept for a big interplanetary ship/station and put it together in orbit over the course of a few launches. I'd really like to see Roles be modable. Don't know if they are or not, but I bet people could come up with some fun concepts if that is open to the community. This will put your Kerbals a little bit more to work. There are probably even more Possibilities. Communications So very similar to AntennaRange. Agreed. Crew Transfer Seems like a simple part variable could handle that, like fuel crossfeed

Seconded! Engineers really aren't that exciting, and I'd love if there were an option to require an Engineer in manned pods for the Flight Engineer data to come up. Is this a relatively simple thing to do? Seems like there must be a definition for all of the traits out there, and you'd only have to add the Flight Data module to the Engineer. Bonus points if you can restrict the available information based on the Engineer's level and/or building upgrades (when conics aren't even available, it seems cheaty to have so much info). But I'm guessing that wouldn't be as straight forward.

I wanted to make an adjustment to the powerCurve for solar panels based on the concept in this mod. But I'm not sure exactly how Unity calculates the curve to interpolate between the points, and I don't want to break anything. Here's the values listed in this mod's config: powerCurve{ key = 0 10 0 0 key = 13599840256 1 0 0 key = 27199680512 0.25 0 0 key = 40799520768 0.1111 0 0 key = 54399361024 0.0625 0 0 key = 67999201280 0.04 0 0 key = 81599041536 0.0278 0 0 key = 95198881792 0 0 0 } The second data point is simply Kerbin's distance from the center of the Sun, and all of the other points are multiples of this. So it goes from 0 Kerbin AUs to 7 Kerbin AUs (somewhere shy of Eeloo). It mostly follows the inverse square law, with Y=1 defined at Kerbin. X is distance from the Sun, and Y is the solar panel's efficiency (a percentage of its stated power generation). Great. Except I'm bothered by the first and last points. The function blows up to infinity at X=0, and it shouldn't ever cross Y=0 at that last X value (nor is zero a relatively good approximation). So here's what I'm thinking about using: powerCurve{ key = 135998402.56 10000 0 0 key = 6799920128 4 0 0 key = 13599840256 1 0 0 key = 27199680512 0.25 0 0 key = 40799520768 0.1111 0 0 key = 54399361024 0.0625 0 0 key = 67999201280 0.04 0 0 key = 81599041536 0.0278 0 0 key = 95198881792 0.0204 0 0 key = 108798722048 0.0156 0 0 key = 122398562304 0.0123 0 0 } I replaced the first point with two. The first is inside the Sun's radius (0.01 KAU), so I assume that will keep things accurate as far as close in as they need to be. The other (0.5 KAU) seems necessary to get better values at Moho and Eve. After the last point, I added two more, bringing the curve out to 9 KAU, beyond Eeloo. I also gave it accurate values at these, rather than ending at Y=0. Does anyone know if my changes to the beginning or end of the curve will cause problems? Does it NEED an X=0 and a Y=0 to work properly? Is there a limit on the number of points it can take? Thanks!

I would really like to reduce how much science you get for transmitting surface samples. For parts you can do something like this with module manager: @PART[*]:HAS[@MODULE[ModuleScienceExperiment]]:Final { @MODULE[ModuleScienceExperiment]:HAS[#experimentID[surfaceSample]] { @xmitDataScalar = 0.1 } } But @PART doesn't make this change in your Kerbals themselves. They still transmit at the stock 25%. Is there any way to make this change with MM? Or would it be possible to create a simple mod which does this?

Quick question... The tech requirements and cost/entry costs in RealChutes seems rather strange. In the MM configs I noticed that it changes the cost of stock chutes. Meanwhile, all of RealChutes own parachutes are marked as free. With strange entryCosts as well, I think. And it seems odd that the cone chute comes at the start, before you have anything which even fits it. I don't mind writing something to reconfigure all of this to something that makes more sense, but I just wanted to make sure I'm not missing something first...

Thank you Entropius. This has been bothering me to no end, and I'm not comfortable enough with ATM's settings to have figured this out myself. Just to clarify, if I need to apply this trick on a mod with parts (I think RealChute would apply- its toolbar image has been blurry for me), then I should change this part: FerramAerospaceResearch/.* so that it specifies the particular directory that the button images are in. Something like this: FerramAerospaceResearch/toolbarImages/.*? As for Blizzy's toolbar, what if you set "compress = false"? I figure that would tell ATM to leave those images alone completely? Given their size I assume they would have insignificant impact on RAM.

I'm having this exact same problem. I haven't had a chance to play 0.25 much, so I'm just now getting set for a fresh career playthrough. Clean installs of latest versions of x86 KSP, ARP, and every other mod. I set your button to replace the stock resource button, and at first it worked like a charm. But sometimes after scene changes or loading a different save it gets a little quirky. Sometimes Squad's button comes back and yours goes back to the left side of the bar, but in the settings it's still marked to replace Squad's. Sometimes there are two copies of your button. Can't figure a pattern, but it only seems to happen on scene changes and loads when yours is marked to replace the stock button. I'm not on my own computer right now, but I can upload my log next time it happens. Or answer any other questions that might help.

When I was trying to unblur my toolbar icons last night I noticed that the move from full res to half res made it worse. So I'm betting you that might be your problem. If you're down to 2.22 GB then why are you worried about RAM? Try going up to full res and see how it plays.

Ah! Thought I had. Apparently I last updated only a few hours before the most recent version was released. Thanks! Asheft is right- Mac supports x86 only right now. But in case that changes down the road... Generally it depends which version of KSP you run. Many mods don't support x64 right now due to bugs. Hopefully that won't be the case by the time they get x64 out to Mac.

I'm having two issues which I believe are being caused by ATM. Just wanted to check and see if these were common problems, and perhaps if there are common solutions. First is the quality of toolbar button icons. Images on both the stock toolbar and blizzy's toolbar appear quite blurry, with the exception of stock buttons. I'm guessing ATM is compressing those images, resulting in the fuzziness. I'd really like a way around that if possible. Is there a way to make sure certain files get excluded? Second is that on every flag selection dialog, I see two images of every flag. It's as if there are duplicate copies of every flag in my game folder. But I've checked and double checked. There's definitely only one copy of the file. Wondering if ATM is making a compressed version and the game is loading that in addition to the original? Is there any way to stop these duplicates from showing up? Thanks, and sorry if this has been asked a thousand times.

Got a strange question and not sure what to search to see if it's already been asked... Is there any way to disable the Flight Computer when a ship is merely under local control? I just tried out Remote Tech for the first time last night. I love the challenge that it presents, and I think building a network of communications satellites will be a fun exercise. BUT I rarely use probes and I rarely transmit science, which makes the my communications network mostly pointless. Kerbals are more fun to play with and they're better at getting science. They require bigger ships and I use a simple life support mod to add to the challenge, but I haven't found that those obstacles deter me from using manned ships. Just like Remote Tech, those problems are more like fun challenges you want to take on than obstacles that you avoid... I haven't played with MechJeb in a long time. Too many automation options turned me off. But I felt like the simple Flight Computer features were perfect. It doesn't do anything for you- only what you specifically tell it to do. (Well, aside from execute maneuvers without human error. No complaints there.) And the attitude control means I don't have to spend half my time chasing points on my NavBall. It's great. So I got to thinking, it would be PERFECT if my ship had to be connected to the communication network in order to use the Flight Computer. That would be JUST the incentive I need to build a network and keep all of my ships connected to it. I suppose it's not exactly "realistic." It's not like the Kerbals in command of a ship are unable to program their ship's controls without Mission Control's input. But it would really give Remote Tech a purpose where (to me, right now) it has none. The limit would only be that you can't open and/or utilize the Flight Computer. You could certainly control everything manually, just like normal, with local control. I don't suppose I'm lucky enough that there's a way to make this happen?