dewin

PilotAssistant 1.9.2 seems to have broken my current KSP installation: If I try to revert or do any other scene change after my first launch, I get a black screen -- which I can eventually get to become either a starfield or a sunless Kerbin, and this problem persists until KSP is restarted. Simply loading a craft and choosing Revert To Launch is enough to trigger this. Reverting to version 1.9.1 fixes this. I've already lost the relevant log file in the process of trying to figure out which of the ~10 mods I updated over the weekend broke this, but there was a mention of something like trying to access toolbar button 0 when there were only 0 buttons -- so I suspect it's related to the toolba mod support.

That'd explain the science issues I was having with RT2 as well that led to me uninstalling, so while I can't confirm the cause I can pipe in as someone else affected. Wasn't an issue for me in 0.90.

I just come up with a simple naming theme (and occasionally ask people on IRC for help). My current theme is city names, with the first letter changing each craft (Austin, Boston, Cambridge, Dublin, Edinburgh, Florence, Geneva, Hawthorne, Ithaca and Jakarta in one of my saves)

CKAN is an open-source KSP addon manager .. you use Linux, so think of CKAN like apt-get for KSP mods. It runs under Mono, so has the same cross-platform capabilities that KSP itself has. See https://github.com/KSP-CKAN/CKAN

LC_ALL is an environment variable that sets the locale used by various shared libraries -- it might, for instance, determine how certain standard libraries format dates and numbers with decimal points. The "C" locale has a set of consistent rules that might avoid breaking other things (e.g. locale-aware code might output a decimal number, which non-locale-aware elsewhere might read and expects "one and four tenths" to always be "1.4" and not the "1,4" used in some countries.) The only thing you get running KSP through Steam is the playtime calculations, iirc. (You might still get those running KSP directly, now that I think about it -- I still get some Steam notifications). Since I have ~5 KSP install directories on my Linux box, running the install I want through Steam is more a hassle than its worth. (I just let CKAN launch KSP)

Is there any chance that we could get additional stats on the resulting orbit(s) after the currently-being-edited maneuver? I like how this shows the new Ap/Pe (If I'm remembering correctly -- on my way to work at the moment), but it would be fantastic if it showed inclination as well, ideally for whatever body is focused. This would be particularly useful when trying to transfer from Kerbin directly into a polar Mun orbit, for instance. Love this mod and I still don't understand why it isn't stock yet.

The whole point of this is to be able to run 64-bit KSP, which only runs stable in Linux. (As for me, I realized all's I did on my home PC was play indie games that all have Linux builds and browse the internet -- and discovered I had an 80GB partition just set aside anyways.. so I just went to dual-booting. Haven't been in Windows for weeks, unless I'm at work.)

I think some sort of forum auto-censoring is being a pain in the rear and quietly mangling the OP, any way to fix that?

Most are. Some claim they're not, usually due to code checking for version 1.0.0 specifically rather than a more relaxed 1.0. Some might not be in case a 1.0.1/1.0.2 bugfix or change caused some behavior changes for the mod.

Sometimes I can get around the problem by moving the ship in the VAB so it launches on a different part of the launchpad.

Yes, it is more dV intensive -- and normally I've used other means (e.g. the single launch vehicle in resonant orbit with timed releases method), or only used my method after getting satellites 'approximately' right. It does work though, and it's also a viable method for correcting an existing constellation that's drifted. I'd love to be able to have something that can do the equivalent math to do it as part of the overall ascent/entry process though, and it wouldn't be too difficult to adapt my current method. Assuming a Kerbin constellation: Start with satellite #1 launched normally and in the target orbit Launch satellite #2 into orbital/suborbital trajectory with correct Ap. Determine what the phase angle between #1 and #2 will be when satellite #2 reaches Ap and construct the appropriate resonant orbit, burning at Ap. This is dV you would be using to circularize anyways, so it's not wasted. (If your launch timing is such that your spacing is already perfect, you'll end up with 360/360 = a normal circular orbit at the appropriate time.) Circularize at next Ap Time launches to error on the side of being "behind" your target position rather than being "ahead" for the most efficient results. For constellations around other planets or moons, follow the same process with all burns at Pe instead of Ap.

For RT2 placement in separate launches, I've found a reasonable way to adjust orbits to get appropriate spacing with MJ -- though all's you really need is a way to view orbital parameters (and phase angle to father) and a way to calculate resonant orbits. After circularizing 3 satellites, they need to be 360/3 = 120 degrees apart. So we take one satellite, target the satellite that is "ahead" of it, and compare phase angles. Let's say it's currently 150. 150-120=30, which means we are 30 degrees behind. To fix this, we need a faster orbit. Enter resonant orbits. If we set up a burn that gets us into a 360-30/360 resonant orbit (330/360), we will orbit 360 degrees in the time it takes our target to orbit 330. Circularize after one orbit (e.g at next Ap) and... We'll be about 120 degrees separated. Not enough dV for that? Well, you could also do a 345/360 orbit (360-(30/2)) and circularize after 2 passes, or 350/360 after 3 and so on. This works if you're too far ahead as well, just circularize at Pe instead. After spacing all of your satellites properly, go back to each one and get them all to have the same semi-major axis. This translates to the same orbital period, and is far more important to reduce drift than having a perfectly circular orbit.

Not at home so I can't check at the moment, but I thought one of the changes with 1.0 is the tech tree .cfg file being per-save (as well as being customizable at all). Something to keep in mind, anyways.

#kspmodders suggested I should bug you with this, so... I wanted to create something that altered the default categories for parts -- including adding new "Filter by Function" categories and altering some existing ones. Ideally, it'd be something that's easy to distribute and modify (i.e. not just me manually adding parts to a custom category -- which can't be placed under "Filter by Function" anyways. I see that MM can currently alter Part categories (RealChutes changes a bunch to None), but there doesn't seem to be a way to add them. (RealChutes does this in the DLL (relevant source), InfernalRobotics adds its own category as well). Would it be possible to add this capability to a future version of ModuleManager? In particular, my goal is to split Utility and Structural categories to add: * Power (Solar panels, Batteries, Generators, etc.) * Staging (Decouplers, Separators, possibly Fairings) * Landing (Parachutes, Landing Legs, Landing Gear) * Either removing the Parachutes category RealChutes adds, or renaming it to the above Landing category and extending it.

If you plan your maneuvers far enough ahead in advance, you can use the flight computer to execute the ones that happen while you're out of antenna range -- and your cone should be wide enough by the time you reach another planet's SOI. This is assuming you're not using the super-long-range antennas though. http://remotetechnologiesgroup.github.io/RemoteTech/guide/parts/ has a good list of what's ideal for which range.

You can save your craft, switch to the other building, hit Load and then choose the appropriate VAB or SPH tab on the top to load a craft intended for the 'other' building.

If you're running on Linux, you already are using OpenGL (DirectX is windows-only)

Just discovered this today, nice! One small request: I often deploy large networks by having a comsat 'carrier' with multiple satellites aboard and putting it in a resonant orbit such that all's I need to do is deploy a comsat and have it circularize at Ap (occasionally at Pe instead) every time the carrier orbits. It's an easy way to get spacing right and is particularly useful on networks at planets other than Kerbin. Any idea that we could add the heights of the appropriate resonant orbits to a later release? (For instance, 4 sats in a circular orbit requires either a 3/4 orbit (with the same apoapsis) or 5/4 resonant orbit (with the same periapsis) for this method.)

I didn't want to open a thread for each one of these, so here goes a list of mod ideas I've had Upgrade tree for buildings in Career mode Originally posted under Suggestions here, the idea is to split building upgrades into a tech tree of sorts of their own, unlocked using Funds rather than Science. Building upgrades could then be split into smaller pieces, and allow you to upgrade buildings in smaller chunks. ("I don't really need more than 255 parts in my VAB, but action groups would be nice", for instance.) Hopefully 1.0 makes building upgrades easier to mod (I hear it's not really exposed to modders at all currently.) I won't repeat the entire post here for brevity's sake, since I think the design there is pretty elaborate already. Science Research Time Add a time component to science -- so unlocking a node in the science tree starts a timer before that science is fully developed. I kind of like the idea of still having to design with older tech while the new stuff is in the "Scientists discover X, expect market applications in 3-5 years" stage. Research for a node dependent on other nodes could be queued, but the timer wouldn't start until those nodes are completed. Nodes that are all at the same level/not dependant on anything could be researched in parallel. Maybe part-testing contracts could favor parts in the 'in progress' parts of the tree, and reduce the amount of time remaining upon completion. This would be particularly useful with mods like Kerbal Construction Time and the various mods that make you lose rep for doing nothing -- you might need to launch some probes with old tech while waiting for new tech to finish. NASA can't exactly sit around waiting for the newest thruster technology to make it out of a lab, after all. Time delays might be omitted for the first couple nodes in the tree, and possible Strategies can alter the time delay. Futuristic mass-altering drive (Mass Effect-style) This is an idea I posted long ago (before a long break from KSP). The idea is a end-of-tech-tree device that, while powered and active, reduces the mass of every part of the ship by some fraction. (in Mass Effect, there's a material whose mass is dependant on the strength & polarity of electrical charge it's receiving). The idea is a technology late in the tech tree that: * Has a fairly substantial weight * Drains ElectricCharge extremely quickly while active * Reduces the ship's mass by a percentage. Possibly this reduction could exclude the device itself (and others sharing the same PartModule), with a maximum of removing a certain amount of mass. (The device could have "max effectiveness %" and "max mass reduction" attributes.)

I'm indifferent: I've never really used the donut (as neat as it looks), nor done anything serious with ion. (Ion engines need to somehow work through normal timestamp to be useful IMHO.) In my current game, the Oscar is completely worthless though: I get more dV, better TWR and lower cost with the small mono propellant tank and a pair of O-10 engines, at the cost of slight my higher weight -- in the same form factor. Plus I can add RCS thrusters for docking if I need to without needing another tank.

I thought the entire "105%" thing was more of a case of design improvements meaning they could get more power out of the engines, and rather than redefine what 100% was they opted to simply use numbers greater than 100%. (Source)

My original design calls for the building visual upgrades to simply happen on certain thresholds of total amount spent upgrading; otherwise it requires a lot of additional modelling and other complexities. But yes, it would be neat if your space center looked drastically different from someone else's based on the direction you went with upgrades.

heh, I guessed correctly at what Minimem does... And as a result, it could be beneficial for KSP's performance if your overall system is low on RAM in general -- but if you're running 8GB+, it's not going to do much for you (nor will it reduce KSP's memory usage.), and it's not going to resolve out-of-memory crashes regardless. As far as a process's address space goes, each 32-bit process has a virtual 4GB of memory. Paging to disk isn't going to reduce that at all, it just means that when it requests that chunk of memory it now has to be retrieved from disk.

You can solve #3 by setting an action group to turn off your air intakes, then hitting that just before your IntakeAir zeroes out. Jet engines take awhile to shut down, but no air = no boom.

I'm sitting here in my career game looking at my level 2 VAB and going "Man, I don't really need to go above 255 parts right now, but I'd love to have to have full access to action groups." Along similar lines at my astronaut complex "I don't really need more than 5 Kerbals right now, but EVA would be nice."... and it got me to thinking... What if -- instead of the current "Pay large sum of money for huge upgrade" setup, buildings had tech trees similar to science but using Funds instead of Science. The existing level-up system could still be used in such a way of "Once you've spent X amount on building upgrades, that building changes to the next tier's model." This could allow to make building upgrades overall cost more than they do now, but in more manageable chunks. Also, depending on how the UI is presented, it'd make certain 'dependant' upgrades more intuitive (Rather than R&D saying "Astronaut Complex Upgrade required for EVA Surface Sample", I might simply have a "EVA Surface Sample" node that has dependencies on other nodes in both buildings). It'd also allow certain upgrades to be more incremental, e.g. the current VAB goes from 30->255->unlimited parts; a tree system might have more 'steps' (30->60->120->255->unlimited, for instance)... so something like: (Costs and such totally made up and not balanced) Vehicle Assembly I -> Cost: 0; Can assemble spacecraft with up to 30 parts. . . Vehicle Assembly II -> Cost: 30,000; Can assemble spacecraft with up to 60 parts. . . . Vehicle Assembly III -> Cost: 60,000; Can assemble spacecraft with up to 120 parts. [and so on] . . Control Systems -> Cost: 50,000; Basic Action Groups Available . . . Advanced Control Systems -> Cost: 150,000; Custom Action Groups Available To still encourage players to fully unlock each building's tech tree, the final node can possibly require all previous upgrades -- i.e. you can't unlock unlimited parts until you've also finished out the action group tree, etc. Thoughts?