AetherGoddess

i think it's important to look at exactly what's going on here, at a low level, (hopefully) with as little politics as possible: the maintainer of a mod has implemented CC to get an easy way to alert people of the code they are running isn't designed to run that way, and it pops up a warning saying "hey! this isn't supposed to work like this, you're on your own. click OK to continue at your own peril.". CC is designed to centralize those warnings and minimize disruption to the user, while providing easy tools for the modder to implement version support checking. this mod is globally disabling that warning by breaking CC. the natural response from any modder is to stop using CC; if someone is subverting the code to talk to users, then they will find other methods. Maybe pop their own warning, Maybe break functions, or maybe simply disable their plugin where the version mismatches. See also ModuleManager's Winx64 must die edition. this will actually make the warnings MORE common, MORE prolific, MORE disruptive and MORE intrusive since there is no common, user tailor-able, codebase to pop up warnings, and each modder must design, code, and implement their own warning system, and decide what that behavior should be. wither you agree or disagree with Khatharr's original goal, this will not accomplish it, and will probably make the problem worse.

i'm only glad this thing doesn't include some kind of self-update self repair thing like modstats. granted that's scraping the bottom of the barrel for cold comfort....

the space shuttle didn't really fly during reentry, it's reentry configuration was basically the large flat underside with balanced forces. it fell with style. once the atmosphere was thick enough and speeds slow enough, it started to fly, but that was well into the atmosphere.

:FOR[MOD] tells module manager that this patch is part of MOD, and that it should be run between :BEFORE[MOD] and :AFTER[MOD] patch sets. it also tells module manager that this patch is part of MOD, and so any patch that :NEEDS[MOD] should also be run.

i have problems with this. disabling warnings is always asking for trouble. the designer of the warning is trying to tell you something. this is a bit like plugging your ears and shouting "LA LA LA CAN'T HEAR YOU" at a construction safety sign.

i was going to end with something like "in short: stop asking, you're only making it worse" but it seemed too harsh, even for me. which is saying quite a lot.

very likely you have old TGA textures. delete your B9 folder and reisntall from the latest.

i can't speak for Ferram, but i can tell you that supporting Win x64 isn't any extra effort IFF the stability was on-par with other platforms. the Mono code that unity is built on doesn't particularly care about architecture, provided some fairly simple best practices are followed. I've used Ferram's mods (among others) in Win x64 back in .24, and i never ran into a problem with the mods themselves, provided i could keep the base game stable long enough to actually, you know, play. the core problem is that Win x64 has so many internal issues, and people were installing mods, running into stock instability, and then blaming the mods. until the squad-side problems are locked down, it doesn't even make sense to accept bug reports from win x64, and people seem unwilling or unable to respect the "you're on your own" declaration that was common in .24. the fix was to just shut down in known bad configurations. a related problem is that now people are complaining about the disable code, and it's almost as distracting as the bad bug reports from Win x64.

I've been skeptical of the removal of direct conversion, but it looks like has issues with that, so i can see the justification now.

i'm not being obstructionist, i am not fixating on the current behavior, i don't appreciate being called immature and incapable of abstract though, and i CERTAINLY don't appreciate having my comments reduced to "(nonsense)" i AM telling you the problem is harder then you are estimating, the solution we have is already near optimal, and getting it closer to optimal will require more effort and produce more problems then it will save or prevent. If you can come up with a solution that gets closer to optimal, without entailing the complications i am outlining, then i would be glad to hear it, but i strongly suspect you are on a snipe hunt, and i'm attempting to save you effort.

Sooooooo there are two problems with this: Wasteheat isn't pumpable. I've personally used trigger's Alternate resources panel to move it around, but unless you're using this (arguably cheaty) method, there's no way to move waste heat around. this is probably by design. It wouldn't radiate. heat radiation requires the FNRadiator module from KSPI. Even if i did create a new part with FNRadiator, it would need to dynamically discover the asteroid size and configure the RadiatorArea value. This would require a plugin. that being said, it does have a certain appeal. i might see about trying to put together a pull request to Rover's mod to add a FNRadiator modules to asteroids that are attached with the ART Jaw, and update the value of FNRadiator based on size minus converted space. Here's an example FNRadiator config for the small Radial Radiator from Wave's KSPiLITE: MODULE { name = FNRadiator isDeployable = false convectiveBonus = 20 radiatorTemp = 2000 radiatorArea = 50 originalName = NaK Loop Radiator upgradeCost = 5 upgradedName = Graphene Radiator upgradedRadiatorTemp = 3500 upgradeTechReq = experimentalElectrics } RESOURCE { name = WasteHeat amount = 0 maxAmount = 400000 } so the radiator temp would need to be something low, like 350 or 400; getting a unconsolidated mass of rock up to 2000 degrees seems problematic, but i can't tell if this is in Kelvin or Celsius or Fahrenheit or what. The radiatorArea and resource maxAmount would need to be dynamic: the example part is 0.02t (20 kg) and is about 1 m by 0.3 m by 0.3 m, but is supposed to have lots of folded fins to increase the surface area. i'd say radiatorArea is probably equatable to m2, and MaxAmount is just unreasonably large, because it works out to 20,000 per kg, and that seems high.

Added state checking

OH! Swamp_IG: a person. I was convinced he was looking for some kind of marsh-water-based copyright protection. that's -5 points for me.

Patience for an update that might not come, because the author gets busy or has a life, or simply looses interest. look elsewhere and switch over just in time for the original to update? both of these things have happened; in one mod; in the last 3 months. Additionally, the users can't control the threads, so we'd be relying on moderators "declaring" a mod dead. this is even more problematic, because of the false authority situation. The future is unpredictable; information about the future, whether from the source, an authority, or the community, is definitionally unreliable. wait, how can you estimate the cost of a solution you don't have a design for?

I'm usually pretty good at this game: I got nothing.

Neither of those are true. "all rights reserved" means exactly what it sounds like. all rights, including the right to recompile or redistribute, are reserved by the creator and can not be exercised without permission. the treeloader license explicitly states that the source is for reference only; compiling is not reference. as has been previously stated in this thread, no one is going to go to jail over it, but ignoring creators rights is an excellent way to have less creators.

Basic is a way to trade off some compression (blurriness) for memory (more crashes). it's behavior is otherwise identical to aggressive (which is the default). in short, if you have memory and want things to look nicer, use basic. if you don't for either, then use aggressive.

TGA textures are kinda unstable right now. this is probably unrelated to planetshine

shamelessly Quoting myself because i can't be bothreed to write an original response. It's probably not going to happen. a config option would probably defeat the whole purpose of the disable code as it is right now. consider this related NEAR conversation: i'm speculating on the purpose. don't blame Ferram for my reasons. With love, Sarah.

the 32-bit version SHOULD(?!?) work, but you're running an operating system the manufacturer won't even support, so?...?

This is a common symptom of getting too close to KSPs internal memory limits. ActiveTextureManagement, the -OpenGL command line option, removing unused parts and (more importantly) textures from GameData, and (for linux and OSX only) switching to the x64 version can all help this. WinX64 is very unstable right now, so a lot of mod makers don't support it. there is a rumor going around that we might have a clue to that, since DDSLoader is showing some stability improvements in Winx64 if only DDS textures are loaded. Yes and no. there is a MM patch to fix known probe cores specifically, and there is a general patch that tries to fix all other cores, but it's not psychic, and there will always be at least one or two probe cores that slip past. probe cores that DON'T get a fixing will act like a kerbal pilot, (i.e. local control: no signal checking, no signal delay, and no flight comupter) but will otherwise act as intended.

that's going into my scrap book, right besides that one time rover said i was right.

and all three of which, in actuality, result in "no support, you're on your own". working as intended. it's not that those are the same case, they are all different, but from the perspective of the mod consumer, the results are indistinguishable. if you care enough, you can read the thread and dig in to the gritties, but the net-net is that it's not supported, use at your own risk, your milage may vary and results not typical. this might actually have some legs to it. a per-vessel marker of "x-mit only" would make long probe missions easier. i could get behind that.

Considering the last update was for .21, and the most recent post prior to yours was 11 april 2014, i think we can safely call this mod well and truly dead. spaceport is down, there is no source and no license, so even if we could get a copy, there's no way to update it. let the dead rest.

ya, it's probably not going to happen until the flaky Win x64 is better, and the disable code isn't for your protection, it's for Ferram's. there is a fairly obvious function in the source code that does the disable. if you can pull and compile the source, and make that very minor change to the code, then you probably have the programming skills to interpret crash logs and not blame FAR/NEAR for crashes that are actually KSP stock bugs in the x64 version. if you can't, then you don't have the very specialized coding skills required to make those subtle distinctions in an experimental environment.