kujuman

Are you by chance using the Elevon5? (The angled one?) It may have some issues with pitch inversion, but it's not easy to replicate. Another user's had this issue.

As well you should. KSP is already multi-threaded. I'm taking bets on if this myth will die before/after the heat death of the universe. More seriously, I'm not sure if I've already responded, but having CoT, CoM, and CoL indicators in flight would be invaluable for debugging shuttles. Additionally, I'd love a gimbal range indicator. Behold my mighty MS Paintâ„¢ mockup!

I do agree about manually being able to invert surfaces selectively. Even if it's not for solving bugs like this, there are times when being able to manually set things is nice. Which control surfaces were you using by chance? I've had a few issues like that with the elevon 5s (the slanted ones), so it may just be bugged parts.

I assume so, but I don't know how right now. I'll look into it.

Huh. Could you provide some screen shots of what's going on?

The exception is that the file specified doesn't appear to exist. This is probably due to the plugin not being installed in quite the right folder. Check to see that KSP_025/GameData/KerbalScienceFoundation/NavInstruments/PluginData/NavUtilLib/ is an actual folder path and that hsi_overlay.png (and some other .pngs) exist there. If the folder path looks okay and there is still a problem let me know

0.5 RC 2 is released for testing. It should be a drop in replacement if you already have 0.5 RC installed. It features minor bug fixing and a new internal prop by nli2work. The easiest way is to get a vessel at the spot you want the touchdown spot to be and then to use the in game custom runways editor to add a runway. Then you can use the settings saved in the custom.cfg. Otherwise: yes, gsLat/lon is the touchdown spot for the runway, and the origin of the glideslope. The LocLat/LocLon is the location of the localizer beacon, and should be some distance past the touch down spot to keep it from getting overly sensitive. For the KSC runways and Island runways I set the Loc coordinates as the same as the glideslope coordinates of the opposite heading runway. Otherwise 500m, 1000m, 1500m past the gs should be fine. What I would use is go to this page http://www.movable-type.co.uk/scripts/latlong.html and go to the "Destination point given distance and bearing from start point" and use that calculator. Make the distance fairly large, maybe 6-12km (since it's scaled for earth, not kerbin) If you want to keep it simple, loc coordinates can be the same as gs coordinates.

Wow, I actually remember this from long ago! Very different from Build. Fly. Dream. but also very good. Them kerbals just wanna space so hard!

At high speeds, yeah, but at lower speeds it may very well improve things. There's a lot of inertia if you're moving something and because of the way KSP joints work, it will be undershooting while you're applying a force and will overshoot just from the joints springing back to their rest state. It's hard to know for certain unless we try it out

Lazor arms have two speed settings. When you're in fine control movement is 1/10th normal speed (or thereabouts). Do you mean by "proper speed adjustment" that you want rotation to have some inertia and not just be a binary state?

I can't say about what code this is using or how it works, but this is "normal" behavior on the stock rover wheel code. Max speed means zero torque regardless of direction.

I don't have the game on this computer so I can't check, but I think by default the gimbal module only AGs "Toggle Gimbal". I'd really like to see "Start Gimbal" and "End Gimbal" (there are probably better names for it). For "Start Gimbal", I think it needs to force activate the module, which may mean force activating the part. This'll solve the issue of using an AG to start an engine but then the gimbal never starts, leaving the player with less control.

That's a brilliant idea. Stealing... Additionally, I'm planning on writing some nodes (get variables) for my NavUtilities mod. I expect this'll be at version .5 or so by the time I can get around to it (a few weeks). After that, I'll try and write a few other nodes. Autostaging is a bit difficult because it doesn't seem to handle sepretrons being on the discarded stages (they still have fuel); at least that was the case the last time i tried (.2.5). I know actually testing for when to stage is very difficult because of all the edge cases, but I'll see what I can come up with, if it hasn't been handled by then.

Interesting in theory, not sure how well it would work in practice because it seems hard to balance. Most of the time Kerbals are doing things in space they're just waiting. Correction burns are far and few between. So to make the system actually have an impact on gameplay, it would have to be scaled to fatigue quickly. Different activities would fatigue at different rates as well. There are two times I could see this being a simple (relatively) case: after attaining orbit and after landing (if not just dropped on chutes). The shuttle wasn't really scheduled to do anything for a while after it got to orbit (at least the few mission timings I've looked at) and after landing the Apollo astronauts had rest. "Fatigue" could be a catch-all for both tired-ness and having to readjust to new environments. But it should be something that's easy and fast for the player. If I have an hour, I can easily do a Mun mission if I already sorta know what my objective is. On my good days I can design and launch, and dock a new station module in LKO in about 30 minutes. I don't want to have to spend extra time waiting for my Kerbals; if that were the case, I'd just attach a probe to get around the fatigue issues. A gameplay feature that just ends up getting circumvented by players is not something worth doing.

Haven't tested, but it will probably be fine (at least the tanks and engines).

http://forum.kerbalspaceprogram.com/threads/85353-0-25-NavUtilities-ft-HSI-Instrument-Landing-System-v0-4-3-%2AOct-12-2014%2A?p=1370290&viewfull=1#post1370290

I had this same thought. Might require some serious thinking to make sure all of the current models work well with it though :/ An example. Green is attach nodes. Red outline is of the boat tail part (2.5 m on one side, 1.25 or .626m on the other side). Yellow outline is of engine itself. Then an engine could look good on different size tanks as long as you had a few boat tails. It would also allow bicouplers and such (especially if you add a floating attach node to the boat tail below where the engine nozzles would end; that way you could have one big fairing around a bicoupler) I'll be sure to post a pic of my new shuttle (designed today ) with 2x poodle power. It's a winner. Full Size

What's this? The poodle has a less dumb name and fits on 1.25m parts? Kujuman is happy. Oh yes. So very happy. Second thought: And because it has a high gimbal, it may be very useful for shuttle style launchers. Kujuman is oh so even happier.

;_; Mine is a victim of the Great Forum Crash I do know I went on a posting spree to get out of moderation so I could PM KospY a few hours after the original KAS thread went up. I think that was in November of 2012? My first remembered forum post

To several of the first comments, especially those about controls: had you read through the "Input" tab in the Settings menu? If so and the labels didn't make sense (at least not without the context of having played), that's one thing, and different from not looking up the key bindings (of which we are all guilty ). Were you aware that probes required electric charge (1.7 EC/minute or whatever) on the expanded VAB part menu? 1) Career mode is very new, so there's only basic balance on it so far. It'll get better probably, but I think the intent is that career mode is more of a way to get your program up and running in a semi structured way, and late game it's basically sandbox with some cash and science. So contracts are a means to an ends, not an ends in and of themselves. 2) Absurd missions are fun XD Although occasionally impossible contracts have come up (not sure if it's still an issue in .25, but when contracts first came out, people might get contracts to test the launch clamps somewhere other than landed on Kerbin. Yeah, impossible ). 3) Drag's been a placeholder basically forever. The actual force of drag from a part is also partly mass based, which is why a ship of all .2 drag parts won't automatically orient during free fall. 3) Style 4) Since one gets 100% refund of any launch clamps (since they are landed at the launchpad), just always add a few of them until you get an idea for what won't need them. 5) There are mods to do this, otherwise you can do it by hand/spreadsheet. This is due to the game's design being more guess and check experimentation than exacting measures (boosters found by the side of the road and all). If Squad does think basic calculators should be in the final game (I don't know where that discussion is ATM), they'd probably wait until it's almost ready. No point spending time now adding features a few very well maintained mods already add. Further, with a bit of experience, you should be able to get a feel for what will work. If in doubt, add more boosters Addendum: they do currently have thrust ratings and fuel consumption. Not sure by what you wrote if you're familiar with the extra detail menu in the VAB. 6) See 5 7) They seem to do so because they do. The torque SAS modules are reaction wheels. So rotation about all three axis is appropriate since we can assume there is more than one wheel. The Mk2 Drone Core's (new in .25) model features the 3 axis' wheels.

After Action Report/Review Basically the who what when where why and how of a mission or group of missions.

To actually address the OP, kerbals have stats because they've always had stats. The three we have were probably always intended to be placeholders. That said, kerbal stats do affect the game somewhat: The kerbal's expressions are partly determined by their stats (as a response to things going on around them). Hence jeb's stupid grin.

It should be possible. One could probably program it all the way to orbit. I've not really read through the code, but I have a hard time imagining that for any program one is likely to make, that there's be any noticeable performance hit. Plugins tend to be nice like that

I wrote my first program in this just now. My "Hello, World!" Was an abort sequence that set throttle to 0, fired the abort motor, separated the abort motor, and staged the chutes (if decending). It is so much faster and reliable than using 3 action groups manually. I spend the last 30 mins blowing up parts of KSC with my rocket, never failing to save the crew

This list is from an earlier post. Bold items are as of this time working. -Simpler booster configuration process. Configure the burn time for the nozzle, instead of each segment. Interesting note: the reason segments have the burn time embedded in them is from a time before the GUI in the VAB...each segment part came with different burn profiles. -Support for symmetry in nozzles (this actually may be in there...I have yet to reread the code). -Better UI (, perhaps nicer graphs eventually. -Support for stock AppLauncher and blizzy78's ToolBar -An attempt at creating support for Engineer and similar mods -Changes to/removal of stack disintegration feature. More detail: Conversion to a stack-based thrust configuration from segment by segment is essentially complete. Some of the auto node modes have been rewritten, others have been abandoned. It's working nicely The UI is going to be simpler to navigate as one whole page has been removed, so most operations can be done on one page. AppLauncher support may be delayed in the interest of reducing time until a .7 RC is out. Engineer support right now is still unknown. I have a plan for how it may work, but it'd be sloppy. In that case, I may develop a simple vital stats page (.delta V, TWR, etc). Rather than a strict stack disintegration (which would be difficult to really simulate well), I've opted to introduce some...fun into SRBs. Currently this is a combination of cyclic Isp changes (with resulting changes in thrust) at about 2 Hz, and the thrust coming from a random location under the nozzle (restricted to be +/- 15cm left/right forward/back currently, will be configurable per nozzle), changing each frame. Combined these make launch a little more exciting without really affecting vehicle integrity or performance. Uncoded but planned is a "max pressure" limitation, wherein each segment has a max propellant burn rate, and if it gets exceeded for too long the segment will overheat. Specifics are still being worked out. Let me know if y'all have any thoughts on the above.