meyerweb

That would be pretty sweet.

I can verify this memory. I was recently trying to do “smart staging”, where the code would check to see if there were launch clamps and then activate first-stage engines appropriately. When I unleashed it on rockets I’d built and rebuilt, everything went insane, for exactly this reason. I was amazed to discover that the parts shown in the staging UI didn’t actually pick up the stage numbers shown there. I certainly am!

Glad to know it’s not just me! After I posted that, I remembered that 1.2.x has performance monitoring built in, but I’m not sure how to interpret the numbers. Anyone know which of the three numbers mean what in the line graph?

I’m also seeing some sluggishness in OS X El Capitan in 1.2.2 on a similar-era machine. For example, the main menus have a noticeably low framerate in animating the text swoops. Interestingly, it seems like they smooth out when I open the “Continue Saved” dialog, though I’m not sure how much of that is real and how much is due to it being the slowdown part of the animation (or how much is just faulty human perception). Interestingly, inside the game itself my framerates aren’t so bad—not super-smooth, but completely playable. That might be due to the low part counts on my craft, since I’ve been playing career and haven’t gotten to the “build complex science and refueling orbital stations” part of the game yet.

I started a new career game in 1.2.2 and as soon as I embarked on the KSC science tour, I realized how much I miss this mod. Any plans for an update?

Just as an FYI, AnyRes seems to have fallen out of CKAN. Updates to it have, anyway: the last AnyRes version my CKAN registry file shows is 1.3 for KSP 1.1.3. Not sure what happened or how to fix it, unfortunately.

I filed an issue: https://github.com/KSP-KOS/KOS/issues/1861

Sounds perfect. Really looking forward to it. One thing I did notice from the 1.2 release notes was the change of orbital anomaly values: As I had just gotten to working with those kinds of values before I had to put KSP aside for work, I’m very curious if kOS will translate the new values into the old scheme to keep scripts from breaking, or if this will be a bite-the-bullet change, or if there’s another solution in the works, or what.

This alone makes the update worth it to me, even with single-character support. Fantastic work as always, kOS team! Looking forward to the 1.2 compatible release, since as far as I’m concerned, 1.2 isn’t really out until kOS works on it. (Please don’t read that as “hurry up already!!1!”—I’m so buried in work right now that I’m intentionally not upgrading to 1.2 until probably after Thanksgiving, because if I do it any sooner I’ll get sucked in and fall even further behind on the work I’m already criminally behind on…)

I’ve started to think about stage-independent actions. This is where my Kerboscript scans the entire ship for parts like launch clamps, engines, decouplers, and fairings, and manages the lighting of engines and ejection of clamps and stages and fairings. Building lists of parts, I can do. Once I have those lists, are there reliable ways to tell which part is which, short of naming them ahead of time? For example, how to tell which engines are on the first stage, so that I light those to get off the pad and not, say, the engine on the probe I’m lifting to orbit. Similarly, if I’m sending a landing probe to Eve, is there an easy way to tell which fairing is on the probe (which I don’t want to eject until I’m in Eve’s atmosphere) and which is on the lifting vehicle (which I want to eject at ~50km altitude during launch)? I do know about the STAGE command, but I’m just thinking about ways to do things that don’t rely on having a specific staging order. I can post a specific vehicle file if that would help, though I’ll have to build it first.

WOOHOOO! Thanks, mhoram!

I think the first question is: have you read about or tried to implement a PID loop? What you’re trying to do will very likely rely on a PID loop or two.

I’ve poked around the documentation, but haven’t seen this addressed: what are the conditions under which KSP will refuse to add a maneuver node? It seems to be dV-bound, but I’m wondering if there’s more to it than that. For context: I’ve been experimenting with a circularization script that uses the eccentricity value as an engine throttle, and I’ve gotten it to the point that I can get within 5 meters’ difference between Ap and Pe on the first burn (at ~79km altitude). If I run the script again on the same craft, I can get within a 1m Ap/Pe difference (same alt.). So I ran it a third time on the craft, just to see if I could get the Ap/Pe difference down to a few centimeters, because why not be ridiculous about it? The program worked as expected, except no node was added. I checked, and the calculated dV for the node was 0.002m/s. So I can see why KSP would just refuse to participate in such insanity, but I was wondering if anyone here knew its outer limits for such things. And also if there’s a way to get KSP to recognize such a problem, or show a returned error code, or some such, if KSP does in fact return an error. Basically, a good way to tell in-script if an attempt to create a maneuver node will fail/has failed, so the script can exit gracefully or go to fallback code or something.

…well slap my hams and call me Porky, there it is. I see it in Blizzy’s toolbar in the map scene, and I can call up the settings screen without incident. I had no idea this was a thing! Thanks, Deimos.

Yeah, definitely seems to be a Heisenbug. I have one thing to add: Trajectories does seem to be working now that the config.xml has been regenerated. I had a suborbital launch show impact forecast. It just doesn’t show any toolbar buttons.

I hand-edited it to read: <xmin>1</xmin> <xmax>301</xmax> <ymin>1</ymin> <ymax>301</ymax> Then I launched KSP and tried to get the button to appear in a toolbar. It still didn’t appear in either Blizzy’s or stock. What interests me is that I quit out of KSP (by quitting out to the main menu, then hitting ⌘Q) and opened config.xml, and it now reads: <xmin>1</xmin> <xmax>2</xmax> <ymin>1</ymin> <ymax>301</ymax>

I’m having the same problem. I can see that Trajectories is set as a visible button in Blizzy’s, but it doesn’t actually appear; see attached screenshot. It also doesn’t show up in the stock toolbar. I deleted the config.xml file, and the plugin recreated it when I relaunched KSP, but the situation stayed the same: no Blizzy’s, no stock. Also, no trajectory forecasting in flight. CKAN shows the version of Trajectories as v1.6.2, as does the Trajectories.version file. This is the config.xml file that was created by the plugin: <?xml version="1.0" encoding="utf-8"?> <config> <bool name="DisplayTargetGUI">0</bool> <bool name="DisplayDescentProfileGUI">0</bool> <bool name="DisplaySettingsGUI">0</bool> <bool name="UseBlizzyToolbar">1</bool> <bool name="DisplayTrajectories">1</bool> <bool name="DisplayCompleteTrajectory">0</bool> <bool name="BodyFixedMode">0</bool> <bool name="AutoUpdateAerodynamicModel">1</bool> <rect name="MapGUIWindowPos"> <xmin>0</xmin> <xmax>1</xmax> <ymin>0</ymin> <ymax>0</ymax> </rect> <bool name="GUIEnabled">0</bool> <int name="MaxPatchCount">4</int> <int name="MaxFramesPerPatch">15</int> <bool name="UseCache">1</bool> </config>

No, that doesn’t work either. 2100 UTC-5 would be 10pm NYC time, because UTC-5 is currently the US Central time zone, one hour behind NYC. Even if they meant the Eastern US time zone under DST, as it presently is, 2100 is still 9pm, not 5pm. Further, the top-of-post time given is 2100 UTC, not 2100 UTC-5.

Something’s off with at least the American times listed: 2100 UTC can’t be 1800 NYC, as that’s only a three-hour difference. Currently NYC is UTC-0400 (and it’s UTC-0500 in winter), so if this really is happening 2100 UTC tomorrow, it will be at 5pm New York time. LA is similarly off, more likely 2pm than 3pm. Not sure about the rest.

Confirmed. I just installed it successfully, and the version is 'All Y'All 0.4' (alternatively: `AllYAll 0.4`). No 'KSP_Version' in sight. Thanks, 5thHorseman!

Ah, that’s probably what did it. Might take CKAN a while to figure out there’s a new version.

I’m unable to upgrade (or install fresh) the latest version of All Y’All from CKAN. When I try a fresh install, I get: …to which I say Y, and then get an unhandled exception: Downloading "https://spacedock.info/mod/628/All Y'All/download/KSP_Version" (libcurl) 0 kbps - downloading - 0 MiB left - 100% Installing mod "AllYAll KSP_Version" Unhandled Exception: CKAN.FileNotFoundKraken: Trying to install AllYAll KSP_Version, but it's not downloaded or download is corrupted at CKAN.ModuleInstaller.Install (CKAN.CkanModule module, System.String filename) [0x00000] in <filename unknown>:0 at CKAN.ModuleInstaller.InstallList (ICollection`1 modules, CKAN.RelationshipResolverOptions options, IDownloader downloader) [0x00000] in <filename unknown>:0 at CKAN.ModuleInstaller.InstallList (System.Collections.Generic.List`1 modules, CKAN.RelationshipResolverOptions options, IDownloader downloader) [0x00000] in <filename unknown>:0 at CKAN.CmdLine.Install.RunCommand (CKAN.KSP ksp, System.Object raw_options) [0x00000] in <filename unknown>:0 at CKAN.CmdLine.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0 [ERROR] FATAL UNHANDLED EXCEPTION: CKAN.FileNotFoundKraken: Trying to install AllYAll KSP_Version, but it's not downloaded or download is corrupted at CKAN.ModuleInstaller.Install (CKAN.CkanModule module, System.String filename) [0x00000] in <filename unknown>:0 at CKAN.ModuleInstaller.InstallList (ICollection`1 modules, CKAN.RelationshipResolverOptions options, IDownloader downloader) [0x00000] in <filename unknown>:0 at CKAN.ModuleInstaller.InstallList (System.Collections.Generic.List`1 modules, CKAN.RelationshipResolverOptions options, IDownloader downloader) [0x00000] in <filename unknown>:0 at CKAN.CmdLine.Install.RunCommand (CKAN.KSP ksp, System.Object raw_options) [0x00000] in <filename unknown>:0 at CKAN.CmdLine.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0 Essentially the same thing happened when I tried to upgrade the already-installed-via-CKAN version, except I didn’t get the Y/N question. I made sure to remove All Y’All with `ksp remove` before trying to install fresh from CKAN.

This mod has been let go by mhoram—see http://forum.kerbalspaceprogram.com/index.php?/profile/78756-mhoram/&status=2174&type=status—so if anyone’s interested in picking it up and maintaining it for 1.1+, the field is yours!

I got the same CKAN error message. When I looked in my mods directory, I discovered the EngineLight directory was still there, and contained the MiniAVC.xml file. I deleted the EngineLight directory, and was then able to CKAN-install without issue. Basically, what I’ve discovered over time is that when CKAN is used to remove a mod, it doesn’t always remove every last file that might have come along with a previous version of the mod, and then gets upset when you try to reinstall the mod later on. I’m beginning to understand why many mod authors are hostile to CKAN.