Ictiv

Honestly, what I'm most excited for (as I understand) isn't even part of the main Early Access launch. I'm honestly most curious, about the Interstellar element, and how it will be handled in terms of the scale. I know some stuff about this was already said, but trying to balance the scale of interstellar travel with the normal space agency operations in the local system, will be nearly as tight in threading a needle, as actually reaching another world, as one of the devs pointed out in an old promo video. Well, that and seeing the rapid partially-planned disassembly of trying a couple dozen kilometer deep airbreak through the nearest gas giant. Maybe eventually doing that with an interstellar vessel going at potentially relativistic speeds. All hail to the Kraken!

Ah, okay, got the two mixed up, thought CurseForge is the one that updates CKAN, and saw that it already had the latest version.

There definitely seems to be some sort of issue with CKAN when it comes to this mod, because CKAN has recognized once more that a new update is available, but thinks that that latest update is 1.0.1.0, rather than 1.0.2.0, and downloaded the previous version.

Oh yeah, I forgot to say specifically, but Orbit Display Mode is in fact that setting I was describing, however, I thought Patches Ahead also did part of what I was looking for, only to be proven wrong. I remain utterly clueless as to what that number actually does, as both of my ideas as to what it could mean were disproven as I kept experimenting with it. EDIT: Actually, now that I wrote that out, maybe it would be worth taking a look at Custom Barn Kit's code. Since the changing of the patches ahead option didn't seem to give any results for me, it might be possible that it's a bug with Custom Barn Kit itself, where it doesn't actually apply the changes to that variable... Either that, or I had a mod left in my load order that reset the patches ahead variable without me noticing? A lot to test considering how long my load times are.

@zer0Kerbal Took a bit of time, but did a bit of testing on a new save. Best as I can tell, unless "orbitDisplayMode" is on 3 for a given level, "patchesAheadLimit" does nothing. As an example, I launched my first probe toward the Mun, and though later it would intercept the Mun, this is what its rajectory looked like up until actually entering the Mun's sphere of influence: The configuration here, was a Tracking Station of Level 4, which in my test configuration meant that the "patchesAheadLimit " number was supposed to be 1, however the Display Mode was 2, meaning the game wouldn't render the upcoming transfer to the Mun. I tested some more using a save leading up to that point and got the following results: Ahead Limit at 1, Display Mode 3 (so same as before, but Mun Patch displaying): Ahead Limit at 2, Display Mode 3 (Orbit going back to Kerbin now visible): What this made me realize, is that I had the idea of what the "patches" meant completely wrong, and I now thought what it actually means, is how many orbits the game thinks ahead. I.e. if you're going to encounter another celestial object, but only on your second time going around from where you are right now, then you'll need a higher patch. If I was right previously, the orbit around Kerbol should have been made visible, but it hadn't been. For example, on my assertion, I did a bit of an extreme approach on the Mun, and got this: Brought up MechJeb's orbit info, so you can see that the orbit period is only ~8 days, but the game notes I'll get closest to the Mun this way in 24 days, which appears to be the third orbit from where I am. To test this, I tried one more time, this time with Display Mode still on 3, and Patched Ahead on 0, getting these results: So yeah. I've got nothing. I've concluded that I've absolute no idea what the Patches Ahead variable does. Absolutely zilch.

What I find quite spectacular, is that upon installing this, and half expecting the game to start having a bad time (as I'm running a sizable mod load as is), I found it instead improved my performance and decreased my memory use. Jus wanted to say: Well done, you glorious stand-up guy! Hopefully you'll never turn to use your fell sorcery for evil! EDIT: I was unaware this forum had word filters, but I guess that makes sense. Don't think illegitimate child is that bad of a word, but it's fine. Just wanted to clear up the weird word choice.

Actually, I'll definitelly have to do some extra testing before I recommend this be implemented, so I'll skip the feature request for now. I get the feeling I misunderstood what some of the stats mean, since on second look, orbitDisplayMode being on 3 should be what enables patched conics, but the separate patchesAheadLimit is what specifies how effective it is. However, your current config only sets orbitDisplayMode to 3 on level 6, while patchesAheadLimit goes up to 1 on level 3 and up to 2 on level 5, which would seem useless, unless they somehow ignore orbitDisplayMode. Frankly, up until now I never really paid attention to this (partially because I didn't pay too much attention to the Tracking Station being overwritten in my game by that patch, partially because I tend to stick in the early game to IVA/ProbeControlRoom, using RPM and stuff like that for orbits. Now however, I'll need to see how it all behaves level by level properly, so I can give more meaningful feedback. The orbitDisplayMode/patchesAheadLimit might be a geuine oversight and a benign bug though. Will report on results when I have them.

No worries, didn't even realize it As a side note, one recommendation came up in my mind about the Tracking Station, which I think I'll 'patch' in on my own version for a bit of playtesting. Namely, I kind of like in stock how there's a stage when you can see your current orbit, but not any extra info like the Apoapsis, etc at the beginning. This never really happens with your version of the tracking station, since Orbit Display gets updated to 2 (the point at which you can start seeing your vessels' orbits) at the same time as Patched Conics being raised to 1. (Incidentally, I think my math on the Duna example was off by one in the earlier post.) Because of this, you never get the 'white orbit' of stock with Komplexity, which feels like a shame, since with 10 levels of upgrades, there really is plenty of room to include it. On my copy, I'll change the Patched Conics line to @patchesAheadLimit = 0, 0, 0, 1, 1, 2, 2, 3, 3, 4. That way, on level 3, it will behave like stock on level 1 in this regard. This might cause issues with Tracked Objects, so I might delete the level where one can track 12, and just move the entire progression of that up one level too. This is mostly to my taste, but it would be worth giving it a thought on your end too, as it would make more of the initial unlocks feel like milestone steps.

Well, it's less the "OPM version", rather JX2 has a small number of patches for various mods, one of which is for OPM, that retracts OPM's own tinkering with the Tracking Station, which extends Tracking Station's power. It's only that one file. The contents of the whole file are this small. Outside the patchesAheadLimit, and DNSRange, there is not much difference between it and what Komplexity does, from a balance standpoint, and to my understanding, the only point of this patch is to balance gameplay (Commented in Komplexity's for easy reference) : @CUSTOMBARNKIT:AFTER[OPM]:NEEDS[!GEP_CommNet] { @TRACKING //Comments are Komplexity { @levels = 3 //10 @upgradesVisual = 1, 2, 3 //1, 1, 1, 2, 2, 2, 3, 3, 3, 3 @upgrades = 38000, 150000, 563000 //38000, 15000, 20000, 30000, 50000, 75000, 100000, 125000, 200000, 300000 @patchesAheadLimit = 0, 2, 3 //0, 0, 1, 1, 2, 2, 2, 3, 3, 4 @trackedObjectLimit = 0, 8, -1 //0, 0, 1, 2, 4, 8, 12, 16, 32, -1 @DSNRange = 2000000000, 50000000000, 250000000000 //500000000, 1000000000, 2000000000, 5000000000, 25000000000, 50000000000, 100000000000, 165000000000, 250000000000, 500000000000 } } If I'm no mistaken, patchesAheadLimit determines how many orbit transfers the map mode will render (i.e. gravity assisting from the Mun then be put on a trajectory to Duna at 4 would let you see your approach from Kerbin, your path in orbit of the Mun, your path out of Kerbin's orbit, and then your path through the Kerbol system, and your orbit change from your approach on Duna, but not what will happen once you shoot back out of Duna's orbit, since that would be the 5th orbit past your current one. That setting I don't think should cause incompatibility issues with either mod since neither of them do any autopilot logic stuff to my knowledge, and I think the balance change of it being only 3, is probably just a result of copying OPM's file, and deleting one column of stats, rather than it being relevant to the vision of JX2Antenna. DSNRange might need to be adjusted to max out at 250000000000 so it's in line with the balance imagined by JX2's devs, but OPM's own setting is 4 times that of what Komplexity's max level is, so I think it's probably fine, as Komplexity still technically nerfs OPM's OP settings considerably. P.S.: On double checking my version for the bug report which I just posted, I realized that the version CKAN downloaded is actually one patch behind Github, however, CKAN also seems to think that 1.0.0.0 released on April 19th this year, which is when 1.0.1.0, the latest version released. This could be the result of a mixed up attempt to update the CKAN register perhaps? Or could be the registry for some reason fetches the latest release's date from Github, but for some reason can't see the latest version itself? As I'm not familiar with CKAN's programming, this is just a guess, but 1.0.0.0 was the first to include the special apostrophe and <>-s in its version title, so I can see some chance of it driving CKAN nuts and also blind to the existence of the latest version through some unhandled issue in its innards. Might be worth taking a look. Unless of course it's just that you haven't gotten the chance to update CKAN, in which case please do so at your earliest convenience!

Hey, just wanted to report a double compatibility issue, which is to say, a compatibility issue with two mods, of which one only causes compatibility issues if the other is present too, in case anyone else has issues with the Tracking Station. The offending mods are OPM with Patches/OPM_CommNet.cfg (which may not actually be a problem on its own) and JX2Antenna, which comes with an OPM patch, Patches/jx2_OPM.cfg (where the issue lies). In my loads, OPM always patches before Komplexity, I'm not sure if this is incidental or intended by some measure in either mod or how MM works, but it might not cause issues. However, JX2 always loads after Komlexity for me, so some measure might be neccessary to implement, especially since Komlexity's settings (as best as I can tell) already accomplishes what the JX2 patch hopes to do. So far, for me simply deleting the two files mentioned from my own installation was enough. If I knew more about the way CustomBarnKit and MM works, I might have tried something brave like adjusting the jx2_OPM.cfg header to include "NEEDS[!Komplexity]", but I didn't want to experiment too much, and the delete hammer solution seems simpler to me for now and works. Since JX2Antenna's development ceased ~4 years ago, and based on the load order, OPM might not be an issue at all (plus neither mod really is a place people would look to try and debug this issue) I chose not to report this there yet. I think a possible patch could be to have two copies of the TrackingStation.cfg's contents of this mod, one with or without "NEEDS[!JX2Antenna]", and one "AFTER[JX2Antenna]" in the header, however this is just my amateur guess of how MM and CBK works; assuming AFTER requires the specified mod be loaded. There's likely better solutions, but just wanted throw something out.

Just a note: "Skipped frame because GfxDevice is in invalid state (device lost)" is something that gets spammed into the debug menu if you alt+tab out of the game, because the game technically runs in the background, but has no access to, well the GfxDevice. (Basically, it means that the computer doesn't bother accepting its display output, since it's in the background.) The output_log in your KSP_Data (or KSP_x64_Data if you're running the 64 bit executable) folder would probably hold more answers. Of course, it could be that something else also causes the GfxDevice error, but since you mentioned that you looked into the Task Manager, I'm assuming your checked the debug log afterwards.

I'm kind of a sucker for Isaac Asimov, so the first of my additions might give that away. Also I mostly add prefixes, since it seems there are less of those than Suffixes at the moment. Prefix: Star's, Kerlington's, Hitchhiker's, Night's, Marak's, Taylor's Suffix: End, Dawn Additionally, you might want to put in a few of the planets'/moons' names into the Prefixes. I don't know about you, but I personally like to think that the Kerball planets were named after mythological characters aswell, and it would make sense to have those names pop up in geographical locations.

I'm going to assume you're probably using Remote Tech, or some other mod that either has to do with energy generator parts or docking ports. With me, Remote Tech was the issue. Having looked at the source code, this plugin decides that you meet the requirements by manually checking if there are parts with the correct modules on your ship. However, Remote Tech 2 for one removes the stock communications module, and puts in its own module instead. Because of this, the current iteration of this mod is not compatible with Remote Tech (or any other mod that does this kind of thing). At least not when it comes to parts that are affected. If you like, you can test if this is the issue, by going into your Game Data\Squad\Parts\Utility folder and making a copy of the longAntennae folder. longAntennae2 for example, then edit the part.cfg inside so that "name = longAntannae" reads "name = longAntennae2". (I haven't modded parts like this too much, but I think it also works if you don't create a new folder, just create a copy of the part.cfg and do the same inside it. But I'm not sure.) EDIT: Also after this, you could launch the game (or "Reload all" in the debug menu if you don't want to relaunch) and a new copy of the stock antennae should show up in the VAB. Replace your ship's antennae with this one, and it should be ticked as correct on the launchpad. This worked for me. EDIT2: I think that this issue could be fixed without further problem from Remote Tech 2 by simply altering the code that it checks both for "ModuleDataTransmitter" which is the stock module for the antennae (and the dishes) and ALSO for "ModuleRTAntenna", and consider it fulfilled if either is present. EDIT3 The Revenge of the Edit: See, this is the problem with me getting used to mods. It didn't even conciously register for me that the remote tech thingy was there under the MET timer. Of course you're using Remote Tech

I agree, but there's a difference between a mapping plugin, and one that only has to keep track of a couple of coordinates relative to the rover. Let's say, you activate it at coordinates 4879, 4335. For simplicity, it reads it as 4880 and 4340. It logs "4880, 4340" as visited, and keeps track of coordinate change. If the new coordinates turn out to be closest to 4880, 4350 out of those divisible by 10, then it also marks that as visited. While the coordinates are closest to a "visited" point, it doesn't expand the list of visited coordinates. Once x number of coordinates are marked as visited, it completes mission. ScanSat is much more complex than this, and I think it might take more effort to get relevant information out of it, than to just keep track of visited area in this fashion. Of course this isn't absolutely precise like this, but it does give leeway for exploration in whatever way the player wants to explore. Plus, this could let the mission do more frequent sub-completion notices (even without rewards), so the player doesn't need to drive 5 minutes to be told that now they are half way there and may turn around, on a longer haul.

This is just a thought, but in a later update, if you decide to fine-tune these exploration contracts further, you could involve something similar to ScanSat. Now, I'm not saying that there should be an actual satellite feed window, or anything of the sort, but in the background you could run a similar simulation to that which unlocks portions of the map in ScanSat. You could include a module that lets players "begin exploration" and with that, in a ScanSat fashion, a background function would keep track of what areas have been visited by the rover since that module was activated. Instead of an X km requirement in the code, it would keep track of the area considered to be visited on the surface, and announce completion based on that.