Jump to content

salajander

Members
  • Posts

    108
  • Joined

  • Last visited

Reputation

24 Excellent

Profile Information

  • About me
    Bottle Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The devs, when they were working on things, had been tracking 4.0 features here: https://github.com/Kerbalism/Kerbalism/projects/2 Obviously I wouldn't think of any of these as any sort of promise, if they're even done at all.
  2. CommNet Constellations seems to be working (so far as I can tell) with my existing save, and has solved my Duna rover connectivity problem.
  3. CommNet Constellation does exactly what I need, and seems to work well with all the other mods in my save to boot. (And thankfully my non-Kerbin-system relay satellites all have multiple relay dishes.)
  4. I have a rover on Duna with an antenna just barely strong enough to connect directly back to Kerbin. I have a big relay satellite in a tundra orbit around Duna. If Kerbin's not visible, the rover connects through the relay with a pretty good signal is transmitting data back at close to 1 kb/s. When Kerbin comes into view, however, the rover chooses the more direct path and connects directly to a Kerbin DSN station, with a much lower strength and about 0.2 b/s throughput. Is there a method I can use to force the rover to use the relay satellite all the time? Or choose the stronger signal over the more direct one, I guess.
  5. I have a rover on Duna with an antenna just barely strong enough to connect directly back to Kerbin. I have a big relay satellite in a tundra orbit around Duna. If Kerbin's not visible, the rover connects through the relay with a pretty good signal (and, I'm using Kerbalism, is transmitting data back at about 200 b/s). When Kerbin comes into view, however, the rover chooses the more direct path and connects directly to a DSN station, with a much lower strength (and about 0.2 b/s throughput). Is there a method I can use to force the rover to use the relay satellite all the time? Or choose the stronger signal over the more direct one, I guess?
  6. Linked in my post, but perhaps not obvious: https://drive.google.com/drive/folders/1k72IULcWbG381QRC4ag32zPuPLINU2vk With parallelization, moho2.mat was giving me that first "Finite difference derivatives" error and moho1.mat was generating "Subscript indices" error.
  7. Hi there - great mod! Been using it for some time, but as my ships are getting complex I'm hitting some FPS issues. I notice in the "Ways to improve performance.txt" file, you suggest removing scatterer. So, I did, but now Kerbin is covered with a thick blue haze. If I add scatterer back, things go back to normal. Is there a step I'm missing? Thanks! Edit: Running KSP 1.8.1 on macOS 10.15, with Spectra and dependencies updated with latest versions from earlier today. Edit: Nevermind. Hilariously, I had StockVisualEnhancements sitting in my GameData folder all this time. Moved that out of the way, and I think things are ok. I wonder what other bizarreness that caused? Good times.
  8. Hi there, I'm testing v1.6.6 PR9 for Linux. I'm having some issues when enabling "Parallelize Script Optimization" in Mission Architect. I had a basic .mat (didn't save that one) with a poor initial DV maneuver, and was looking to optimize to find a Moho encounter. With parallelization enabled, running the optimizer would give an error: Finite difference derivatives at initial point contain Inf or NaN values. Fmincon cannot continue. Turning parallelization off made things work. (I don't have the .mat for this; I'll try to recreate it.) After getting a Moho encounter, I tried to enable parallelization again while optimizing for maximum spacecraft mass. It failed with: There was an error optimizing the mission script: Subscript indices must either be real positive integers or logicals Disabling parallelization again allowed it to proceed. The .mat file for the second error, as well as ksptot.log, are both here. (I downloaded PR9 from the link in your PR9 announcement post; I assume that's still the valid link?) Edit: Both .mat files are there. The confusingly named moho1.mat is the second error, and confusingly named moho2.mat is the first.
  9. (Late!) There were some issues with KSP AVC versions earlier than 1.4.1.3 and KSP 1.8 that was leading to updates never actually being checked. I noticed that after running 1.8+various mods for some time I never got any updates for mods I knew had newer versions. Turns out there were issues with threading in the early 1.4 releases. It should all be working now.
  10. I've seen the AutoStage option, but I still believe there's a bug here, because it will stage if _any_ engine has a flameout, even if there are others still working.
  11. Now that I've Read The Fine Manual: I guess I set inclination to 6 and select Descending Node.
  12. Hi there, If an engine fails while using the To Orbit autopilot, TCA will immediately stage, even if there are other working engines in the stage where the failure occured. I'm playing with Kerbalism, which among other things simulates engine reliability. This means that engines have a MTBF rating, and a limited number of ignitions. Most launch engines (at standard reliability) have MTBFs of around 5 minutes, so failures, while rare, aren't unheard of. Also, it would be nice if TCA had an option to limit re-ignitions when coasting to apoapsis - currently it will pulse the engines now and then to keep the Ap at the right altitude, which will use up remaining ignitions. One more thing - I can't seem to input a negative inclination, either by typing directly or using the -5/+5 buttons. Nor can I fake it by using, say, 354º to get -6º
  13. Yeah, as I mentioned in my post above, something is up with ksp.spacetux.net and it's serving up very old version information. I believe it's on @linuxgurugamer's looooooooong list of stuff to have a look at. Also, some older builds of AVC were simply not checking at all due to timeout issues, though I think your version wasn't affected? I've lost track of what works somewhat and what's broken. The current build of AVC is working well, though - it's successfully checking and offering downloads for any mods that have URLs that are reporting correct version information.
  14. @linuxgurugamer Tested 1.4.1.3 and things seem to be working now! Thanks so much. I now have 4 mods listed that have updates! Thanks again for sorting this out, and for all your work. As I mentioned above, I am still seeing old information coming from ksp.spacetux.com, however, which I think may be hiding other updates. For example, KSP-AVC is claiming 1.2.0.7 is current: $ curl http://ksp.spacetux.net/avc/KSP-AVC { "NAME": "KSP-AVC Plugin", "URL": "http://ksp.spacetux.net/avc/KSP-AVC", "DOWNLOAD": "https://github.com/linuxgurugamer/KSPAddonVersionChecker/releases", "GITHUB": { "USERNAME": "linuxgurugamer", "REPOSITORY": "KSPAddonVersionChecker" }, "VERSION": { "MAJOR": 1, "MINOR": 2, "PATCH": 0, "BUILD": 7 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 5, "PATCH": 1 }, "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 5, "PATCH": 1 } } I manually changed the KSP-AVC.version file in my GameData/KSP-AVC directory to claim it was version 1.4.0.0, but was not prompted for an update to 1.4.1.3. I haven't manually verified all the data that ksp.spacetux.com is serving, so I'm not sure how widespread this is.
×
×
  • Create New...