toadicus

Thanks for (perhaps indirectly) pointing out my omission of the "usage" section in the OP. Fixed!

As advertised, VOID is continuing development! New thread is up over here. Thanks Iannic-ann-od!

If you love at-a-glance information on your flight conditions, detailed information about your orbital dynamics or upcoming transfer maneuver, then VOID is a solution for you! Is it the solution for you? Give it a try and find out! I've long used VOID to fill the void (doh!) for detailed orbital, surface, and vessel information without adding any new functionality that other mods may focus on. As I find new data that I "need" for my missions, I've been slowly adding information to my own VOID displays and am honored to continue development following Iannic-ann-od's stellar release series. Many thanks Iannic-ann-od! As before, credit where it's due to code and/or calculations by cybutek, Younata, Adammada, Nivvydaskrl, mrenigma0, r4m0n, The_Duck, Cilph, and Innsewerants, used with permission and/or under license. This software uses VesselSimulator and Engineer.Extensions from Engineer Redux. Engineer Redux © 2013-2014 cybutek, Padishar, et al Used by permission. DOWNLOADS: GitHub for 1.1.0-beta: [zip] SpaceDock: [zip] Not SpaceDock: [zip] [tar.gz] [tar.xz] 1.0 BETA: [zip] [tar.gz] [tar.xz] CHARITY: Do you like what you see here so much that you can't imagine downloading it without first parting with your hard-earned money? If so, this specially-crafted PayPal donation button will help you to take the currency of your choice and make it my money instead of your money. More seriously though: donations are 100% optional and entirely at your own discretion. If you do choose to donate, I'll appreciate it! INSTALL: 1. Unpack archive into /path/to/KSP_folder/GameData. 2. ??? 3. Profit! USAGE: * Click the VOID icon, hopefully located somewhere near the middle-to-bottom left of your KSP screen. * Go to the "Misc" menu and "Change icon position" to move the icon to your liking. * Enable or disable other informational windows as you please! TODO: * Revisit transfer angle calculations. * Revisit pressure indication. * Revisit localization and find translators <insert trilingual, bilingual, American joke here>. * Revisit data logging. * Add HUD customization features. CHANGELOG: LICENSE:

Sure, here it is: http://pastebin.com/Squ1Ctib Based on a weekend-long playtest, that version works just fine.

No, I had never had the map zoom problem in previous versions.

New information: zoom behavior in the SPH seems to be fine. When I get a chance I'll see if there are settings I can copy to the VAB or something. Still stimied about the map zoom though!

I've found a couple of (frankly embarassing) maths errors that I believe were at fault. Resolved for now?

Has anyone else had weird issues with mousewheel scrolling in 0.22? I have one of those old-timey scroll wheels that "clicks" in 3-line chunks or so, but in 0.21 my zoom was nice and smooth. In 0.22 it's not, and tweaking the mouse wheel sensitivity doesn't seem to be changing anything. Some fun examples: In the VAB, mousewheel scrolling to change elevation goes in about 8 meter chunks per "tick" In the VAB, shift+mousewheel scrolling to change zoom goes in very large chunks per "tick" In the flight map or tracking station map, mousewheel scrolling to zoom in goes straight to maximum zoom level. TIA

I'm looking into adding biome detection to an informational addon. Looking through the API, the most straightforward method seems to be: Vessel V = Vessel(); CBAttributeMap.MapAttribute TheAttribute = V.mainBody.BiomeMap.GetAtt(V.latitude * Math.PI / 180d, V.longitude * Math.PI / 180d); The problem with that is that CBAttributeMap.GetAtt posts a debug message to ScreenMessageStyle.UPPER_RIGHT, which is ugly the first time and a huge nuisance when the UI is running at high frame rates. So, I took it upon myself to rewrite CBAttributeMap.GetAtt. I can't find what I missed... anyone else care to put eyes on this? Here's my code: http://pastebin.com/XWtLnnS9 TIA

Welcome! You can also press Caps Lock to toggle fine controls (for rotation and translation) without the need for holding a modifier.

I use Ferram Aerospace Research, so all of my rovers have to be mounted aerodynamically. So, typically it looks something like this: But... that's not very informative, so here's the important bits with the fairings off. This particular version lacks a CM because I was testing the rover proper, and used a lander designed for Duna on a Munar mission, so the lander had plenty of fuel left for the trip home. The lander has to go "pick up" the rover in Munar orbit after the injection burn; it winds up thus: And just for fun: regardless how carefully Seavin pilots the rover, you wind up losing a part or dozen.

I call this Icarus... I'm not sure why, as it really can't get anywhere near the sun. Exactly 100 parts, about 38t at launch. This is an older design; the latest revision moved the engine nacelles outboard some, and relocated the monopropellant tanks to make the door accesible, but I don't have any good screenshots of it. The docking port shown didn't actually work with my space station, so I had to move it forward a ways. It's almost all stock parts; I added a custom radial-mount drogue chute for spin recovery, but that's it. You can see them spent, just to the sides of the tailplanes, here. I can land it, but only on empty tanks. It doesn't have great pitch authority at low speeds on a full tank, though I think the problem is actually more with the structural linkage at the cockpit and the main fuel tank. It has a few basic problems. Its center of mass doesn't line up quite right with the aerospikes' center of thrust, so I wind up needing to burn RCS to hold the nose down if I need to thrust more than 25% or so in orbit. It's also nearly impossible to keep it straight on descent, and can't recover from spins without the spin recovery chutes. I've yet to make a successful reentry without the spin recovery chutes. That aside, it flies pretty nicely in atmo both full and dry, and glides well. My flight pattern goes something like this: 60 degree climb to 12 km; 10 degree climb to 1.2 km/s (usually about 20 km); rocket-assisted jet flight until flame out (usually about 22 km); 45 degree insertion burn. It's currently only functional as a personnel transport or as a lifter for comparatively light cargo (I've lifted a 1.5t probe with it, but couldn't manage to a 2.5t rover), and its range is limited to LKO. I feel like I'm missing some crucial bit on spaceplane design, or else I've fallen into some awkward middle ground between "tiny little single engine bits" and "giant planes as big as the runway with dozens of engines" that the stock parts don't really support. Ah, well; it was a fun development!

@ferram4 I've done some more rigorous testing and I think I've narrowed things down. This looks to be the fault of disk access during flight. I typically play off a thumb drive; it's USB3, but still not the fastest around, and the laptop I often use doesn't have USB3 ports, so I'm sensitive to disk-intensive processes. When FAR is installed, KSP.exe thrashes the disk while timewarping. When FAR is not installed, it only touches the disk when I get to a new craft or planet or something. To reproduce: Create a new save file. Put a part on the launch pad (I used a mk1 command pod) Timewarp to 50× or faster. You should see near-constant disk use, which will cause regular pauses on slow disks. All testing done with 0.20.0, btw. Just for giggles, I dove into the FAR source looking for the problem, and I think I found it. In FARControlSys.cs at line 1182, you save settings to FAR.cfg thus: timeSinceSave += TimeWarp.fixedDeltaTime; if (timeSinceSave > 15 || PauseMenu.isOpen) { SaveSettings(); timeSinceSave = 0; } At 1× speed, TimeWarp.fixedDeltaTime = 0.02, so SaveSettings is called every 750 ticks. By 50× it's up to 1, so it happens every 15 ticks. By 1000×, TimeWarp.fixedDeltaTime = 20, so from there on up SaveSettings is called every single tick. For installations on fast hard drives this isn't a problem, but on my little thumb drive, especially over USB 2, the disk just can't keep up. Guessing that every 750 ticks is more-or-less your intent, I've "fixed" the problem for myself thus: timeSinceSave += 1; if (timeSinceSave > 750 || PauseMenu.isOpen) { SaveSettings(); timeSinceSave = 0; } This way the file is only written every 750 ticks regardless of TimeWarp. Now, I'm not sure what the cfg file does, or why it's important to write to it quite so often during flights, so it's entirely possible that my "fix" is not actually valid for FAR's proper functionality. It looks to me like the file is only read when the GUI is loaded (so each time you switch to a new ship, I think?), so it doesn't seem like ensuring saves to the file happen consistently in Kerbal time is important. But, I just don't know... but maybe you do?

As a follow up: this may not happen in Linux, or it may be less pronounced. I've been playing in Windows to avoid the scroll wheel bug, and it has happened in Windows almost identically on three different machines of varying power (from a mobile i5 to a high-power overclocked i5 to an overclocked Phenom II 955 with a GeForce 560Ti). I had occasion to start up KSP in Linux in spite of the current bugs, and FAR appeared to be working just fine, and timewarps appeared to run smoothly, even in relatively low orbits. HTH

Should this just be installed on top of FAR, or should the stock parts be reverted to stock as well?

@ferram Does 160km count as a low altitude? I'm testing on an i5 laptop with graphics turned all the way down, and still get the stuttering at my LKO station. I even get the stuttering at a KSO satellite. It occurs whether I'm in map view or staging view. I think it is not as bad at higher altitudes, and higher time warps (>100) seem to suffer slightly less, though the effects wind up being worse (at 100000, I only see the satellite at two points per orbit). The laptop is fully capable of running the stock game without any performance hits. Let me know if I can help out with anything!

Is anyone else having trouble with timewarp? I've tried FAR on two different machines now, and whenever I try to time warp faster than 50x, the game stutters, pausing for a second or so every second or so. This is pretty much unplayable, but I'd really like to use FAR. Any thoughts? TIA