MisterFister

Is this mod still actively supported / developed / maintained?

Is this mod still alive?

Is this mod still alive?

Is this mod still alive?

How does this mod interact with TimeControl? Do they do the same thing, such that having both is an unnecessary redundancy? CKAN seems to be ok with me attempting to install and run both at the same time, is this wise?

Sad that this is a dead CP, as fun was had in abundance with it.

Does the mod author here have any preference for or against listing this mod on CKAN?

Thank you for this info. However, does this mean to convey that there is no receptiveness to incorporating a manual-suppress feature? My reason for asking is that I run multiple parallel copies of KSP, side by side. Each one has its own modlist. Having the new-in-repository feature reset every time I close or run CKAN deprecates the net effect for me and others in my usage scenario. Allowing a user to manually toggle the visibility of specific mods on a per-KSP-install basis would turn the default function into something much more useful, whether or single-copy users or multi-copy users.

Feature request: Can we please make it possible to flag or de-flag mods listed based on whether they were previously selectable at the last session? Or, can we manually hide mods that we affirmatively decide we won't want to consider installing? Whenever a KSP version rolls over, the mod ecosystem takes weeks and months to catch up. That's fine, that's the name of the game when you're dealing with volunteer modders donating their time and expertise for free. But the only way to start a new virgin-install copy of KSP and simply periodically check for all of your favorite mods to be updated is to manually scroll through the "compatible" list one scroll-wheel-click at a time and manually read or quick-scan with your eyeballs to see if any given line might be present that wasn't before. Please, allow me to manually suppress or block certain mods from my scroll visibility. This would probably come with an option for me to go in and de-suppress something (or even de-suppress all). Is there anything to suggest that this already exists, or is already in the works?

Full disclosure, I'm an irredeemable mod-addict. However, I am intentionally asking in a stock modless context: What roadmap exists, if any, for KSP to receive optimization passes in future updates, if indeed any future updates ever come to pass? KSP is pretty much in a class of very few other gaming titles (Factorio being another notable example) which bottlenecks at the CPU and not at the graphics card. Worse, it's been the better part of a decade since anyone was likely to purchase a computer for use with computer games that had single-core CPUs, yet KSP still only utilizes a single core. Case in point, I run an octo-core i7, and while quads aren't exactly bargain-basement economy models quite yet, I think it'd be equally unfair to characterize hex- and octo-core systems as "newfangled" or "rare." In the context of my admitted mod addiction, I recognize that the more mods one uses (particularly plugins) the more likely any multi-core / multithread / optimization would be to bork the backend stuff that allows said mods to attach to the game so easily. That said... is hoping for 2015-cutting-edge performance here in 2017 really an unreasonable thing for a user to request?

I for one consider this mod as a must-install if for no other reason than my nostalgia for the KW-style fairings (non-procedural, non-confetti -- dear lord I hate the stock fairings with a passion.) So, thank you for maintaining this and all of the other mods that you work on. My question for here -- whether manual install of CKAN, what is the difference between the Redux and the Rebalanced versions? I'm experiencing CKAN-crashes from an overwrite error because both Redux and Rebalanced are attempting to write the same GameData\KWRocketry\Flags\KWFlag01.png. This might be a packaging bug, or it may be that these two mods are in conflict and I should run one or the other. Hence my curiosity as to how they're different, so that I might choose. Generally, I'd go by the datestamps on their respective forum threads, with this one for Rebalanced being the more recently visited by the author. And in the other thread, it's explicitly stated that this one will be more closely monitored and supported. But both seem to have been recently updated within the CKAN index for KSP v1.3.1. Which implies that both versions are equally supported. Which implies that the conflict I'm observing might not be known or intentional. So I'm asking about it here.

I quite enjoyed reading this. Very well done. Here's to your crew having returned safely!!! (...?)

You say you're new to modding KSP, but I'm not sure how new you are to game modding in general. Assuming you're on the new side with that, too, I think I can help explain. Basically, CKAN works because of "metadata," wherein mods are packaged wherever they're up for download. CKAN doesn't "hold" any mods, it just holds a centralized index. That index keeps track of a lot of things, including mod versions (as a mod gets updated, the CKAN index expands to include multiple versions of the mod, I think.) Individual mod versions are tested and indexed as to which exact patch versions of KSP they're keyed to be compatible with. Indeed, most of the very reason behind mod version changes is to keep the mods up to date with the latest version updates and patches of the base game. With this mod, the metadata says that the latest mod version is v6.3.2 (as of the writing of this comment) and that this version of the mod is compatible up to KSP v1.3.0. If you run KSP from Steam (more on this in a second) then in all likelihood you've migrated to KSP v1.3.1. That third digit of the KSP version may or may not be significant to a mod's compatibility. The CKAN index can never know, so it never assumes. If a mod creator chooses to list its own metadata as keyed for KSP up to a max version of v1.3.99, for example, then that's how that mod creator would let the CKAN index know that small version patches to KSP are predicted to be immaterial to mod compatibility, but any time the game migrates to v1.4.0 or higher, then CKAN is instructed to await further instructions. In this thread, a few panels above my comment here, the current mod caretaker made a comment that indirectly confirms that the KSP v1.3.0 to 1.3.1 is a significant enough jump that some tweaks and updates within this mod are necessary. Note that CKAN never "knows" if a mod is EVER compatible, it just lists mods filtered against the internal metadata of your system KSP install and the metadata of the mods themselves in the centralized index. Basically, the scenario here for B9 is to wait for a few more days for the mod-author to update it for KSP v1.3.1. And have a pleasant modding evening. Note from above regarding Steam installs: Mild warning, especially if you're new to modding KSP:

Does that mean that you'd be ok with one of us reporting it for an update of the .version metadata for CKAN? Or is that considered a test build right now? Edited to add: I found the dev thread, you answer this line of questioning rather explicitly over there. I shall sit tight (sorry, too late for me to delete this comment.) Thanks!

I vehemently disagree, at least to the extent that you exclude the notion of usefulness of other possibilities. After all, aren't certain specific parts more likely to radiate heat? Aren't certain parts more vulnerable to overheating? Just as we'd care to shield a heat-vulnerable part from heat sources within the same craft, so too would we not want to limit its opportunity to receive potentially destructive radiated heat from adjacent craft, particularly when docked if in space, or parked near each other when land based?

Not a specialist, but I have some (not as much as I'd prefer) technical experience. Terminology becomes extremely important for accuracy. You're both correct and incorrect to state that radiators radiate unevenly in a predictable pattern, but you're incorrect to refer to "points." Rather, radiation (all kinds, including thermal) radiates from *surface area.* That's why radiators in vehicles and air conditioners have so many tens of thousands of delicate little metal fins in a grid-like pattern, because the design calls for exposing as much surface area to airflow as possible. With that improved terminology, you can then correctly state that large flat surfaces radiate more effectively for a given mass of matter than the edge-face surfaces might. And remember that even for a piece of paper, the edge of the paper IS a surface. Nothing is two dimensional, even if it's a sheet of material only one atom thick. Demonstrate this at home. Buy two 250ml bottles of water. Drink half of one, leave the other still sealed, and put them both in your home freezer overnight. Let them freeze absolutely solid, all the way to the core. In the morning, take them both out of the freezer and put them on separate dishes out in the open on a table or counter. Make sure they're in equal amounts of light (if one is in bright sunlight, make sure the other is too.) Leave them to melt unattended for about two hours. When you return, observe how far along each is in the melting process. If you did this correctly, you'll likely find that the half-emptied example has less of a percentage of its contents in solid ice form than does the one still containing the full amount. Both have melted some, of course, and one had more ice to begin with. External heat and thermal energy can only enter through the exterior surface of the ice, and that surface extends to the shape of the bottle that contains it, along with whatever flat spot there was for the air that was also trapped in the bottle at the same time. The full bottle might have more absolute surface area in terms of how many square centimeters there would be (surface area of a cylinder is π•(length)•r^2) but with the smaller mass of ice, there is MORE surface area as a proportion of the overall mass of the water molecules. In other words, as heat penetrates and melts the ice, the melting only propagates at a specific rate past the surface. For round figures, let's imagine that the the heat can melt the ice away at a rate of 1cm per hour. With the smaller mass, there's less ice leftover AFTER you melt away that outer centimeter than with the full container. Now, take the larger and as-yet-still-mostly-ice bottle and carefully smash it against something sturdy that one break. Shield your eyes in case the plastic bottle breaks or leaks, or a chip of ice flies offin a random direction. The edge of a stone staircase or the jutting corner of a brick wall would do nicely. Make sure the ice inside fractures or shatters. Note two hours later how much more quickly that chunk of ice is melting. Heat can now radiate into the ice crystals across all the new surface area introduces by the fractures and breakages. You're now melting thousands of tiny ice chunks instead of one large chunk, and overall liquefication is faster. As to Kerbal Space Program. I would imagine that parts are considered point sources of heat. But I submit that there might be some surface area calculations involved either as to surface facing, or as to radiation shadows, since the aerodynamics of the stock game do take into account SOME aspect of how the model collision meshes present to the airstream during atmospheric conditions. Of course, this can all be manipulated or enhanced with mods, of course.

Earth does not exist in this game if unmodded.

For the record, these forums are unparalleled in breadth of topic discussed, the diversity in the game-modding ecosystem, and the support tools that modders and game devs alike put in place. This is MAYBE the second or third time the forums have been significantly disrupted since 2011, I believe. 2011, you might benefit from noting, was back before there existed a GameData folder -- which meant that individual mods could only be installed by overwriting hard-coded game files, which pretty much meant you could run one MAYBE two mods at a time without something borking out. Fast forward, you now have SpaceDock [plus that other accursed respository that I try to avoid] to say nothing of CKAN, I estimate that a solid 20% of the modding community uses github, fully deployed cross-platform mod support across Windows / Linux / Mac, and one of the healthiest overall YouTube landscapes there is by game title, second perhaps only to things like Rust or Minecraft. The fact that not only was Kerbal Space Program the first major success story to come out of the horrors of The Age of Fly By Night For-Profit Early Access, but still remains a standout in a field of maybe 4 or 5 individual success stories in all of existence, and I'd say that you'll likely feel differently a few weeks from now. If you'd care to PM me, I'd be happy to individually show you anything you'd care to know.

That is a configurable option, check the settings I see the configuration option you mention, but the X,Y number entry isn't entirely intuitive. As things stand, I think it's necessary to guess at numbers to change from the KSC-scene and then go into the VAB / SPH to attempt a sim sequence, by trial and error. Perhaps making this option accessible from either within-sim or within the VAB / SPH scene? Or a tooltip on the options screen explaining what the numbers mean, what increments might be recommended, or possible info relating to different gameplay screen resolutions? Unrelated: I run your mod with DangIt, TestFlight, and a few others. Whether for any or all of these, or perhaps just the more popular ones like the two I just mentioned, would it be possible to coordinate with that mod to make it an option to disallow random failures in sim? Perhaps in addition to allowing for centralized-interface intentional failures, or scheduling failures at specific points in the flight? (Reposting this to those other mods, as well.) (Note, I also run Kerbal Launch Failure Revived, which you seem to be helming as well.)

Is there a way to reposition the ARP once it displays that I'm just not figuring out, rather than a simple binary toggleOn and toggleOff option? My ONLY complaint about this fantastic little plugin is that it makes clicking on KSC messages and the stock contract window into a real pain.

I for one am constructively biding my time by preparing krakenbait craft files in the VAB while awaiting the next release of this mod. Why, just a few minutes ago, I borked a stack-launch pretty good simply by incorrectly installing the folder structure of the devbuild of this mod. #ThatsEnoughModtestingForMe

No, that's the United States Library of Congress Main Reading Room in the Jefferson Building in Washington, DC. Bro, do you even library? 8-)

Well slap me around and call me a doomed kerbal. I thought I had but I obviously missed that. That would be very helpful if it were more prominently explained in a readme file. Separately from a readme, perhaps @taniwha could consider adding a .version to the file to allow for easier AVC / CKAN updates? (And with respect to CKAN, perhaps the NetKan maintainers could include a sub-selection on shader needs would also help reduce user error in installation -- I think I'll bring this to their attention.)

When running only this mod on an otherwise modless install of KSP v1.2.2 for Windows x64, in the TrackingCenter, enabling the geodesic grid overlay produces a magenta hex-mesh on all focused planets, but not on any unfocused planet. Undisplaying the geodesic grid allows for the magenta to disappear and the normal planet texture to become visible again. Again, this happens on an otherwise unmodded install, Windows x64, with Kethane v0.9.8 (re-downloaded and re-tested to make sure.) Logs and screen grabs are available here. I'm rather convinced that I'm the one who's doing something wrong, but I can't seem to figure out what. Any advice would be appreciated.

What does Ship Sections do, and how could other mod authors take advantage of it?