MisterFister

Well, yes, but then mid-integer transfers of resources become less convenient to work on. In fact, I specifically recall that TACLS at one time has a 1 unit = 1 day = 1 kerbal, but when it switched to CRP, after some brief growing pains of save-breaking, everything was nicey nice. With CRP, you have 1 unit = 1 liter of a resource. Then, densities and masses could be configured to whatever degree of realism or parody a mod designer would want, and further made third-degree mod interactivity possible (such as TACLS being capable of switching as between stock / RSS / RO / 64k / Toy at the flick of a GameData switch, because 1 unit = 1 liter.) @Felbourn did the same thing with his Project Odyssey series, where he custom-modded his career in sandbox from scratch to base kerbal resource consumption rates on some sort of real-world metabolism that took into account the apparent size and apparent mass of a kerbal against known biological trends that could be extrapolated from earth organisms. While I recognize that 1 / 1 / 1 is convenient in certain scenarios, the stock game already measures in meters and not in "kerbal-heights" and seconds as opposed to "kerbal cardiopulmonary pulserate" increments. Why not convert all other resources to some sort of inter-compatible system, such as metric, which is fundamentally DESIGNED to be inter-compatible? (Full disclosure -- I live in the United States and kinda wish that my country would embrace the metric system, too.) @ShotgunNinja I stumbled upon your mod for the first time tonight, and I must say that I really like the concept. However, I'm diehard TACLS (and am kinda butthurt about TACLS not continuing development) and a diehard RT user. I'm curious what your plans are surrounding TACLS, including the discussion on CRP compatibility, and I'm curious how you'd suggest I interpret what I've been reading that your system here entirely supplants RT. The rest of your mod sounds absolutely faboo, but I'm nervous to make the switch without those two mods considered. I also plan heavily around mods such as DangIt, StationScience, and I am somewhat ambivalent as between Kethane and Karbonite. Do I understand correctly that you generally intend to replace those mods with your own integrated package instead of making something that can work with or without them, compatibly, as desired by a user?

So, are we talking in-field upgrades, like at orbital dockyards? Or are we talking about adding new production options? I mean, the Boeing 747 was a new design when it was made, but there've still been 737's made since. Parts for older 747's are still manufactured for maintenance purposes. All of a sudden when we improve a design we lose the ability to fabricate the older version? Why not have both options available for future purchase, with the later-gen design being the default option?

In organizing and proofreading my post above, I forgot to include another idea: nominal costs for texture changes. All of my 3-series examples assumed that a player would start with a SBOT. If we're reconfiguring the internal compartments of a multi-resource tank, excrements's gonna get real confusing real quickly in trying to remember what tank at what location holds what resource. Either automatic texture decals to indicate resource set (maybe an animated or context-sensitive decal that gets lighter or darker with tank fill level?) or maybe even a user-elective opportunity to simply purchase texture changes at any time. Would we be able to work with pTanks, and conversions as to tank insulation for cryofuels?

I like the idea of having the up-front either-or choice of: 1.) Compress all resource types, according to gradients predetermined to approximately model "compressibility" of a substance; 2.) Compress a single resource type, affording for greater maximum achievable compressibility of that specific substance given that structural modifications to the tank in question can all be oriented around reinforcing a specific inner pressure vessel exclusively instead of "all of them equally"; 3.) No compression changes, but allow a multi-resource container to be internally reconfigured to accommodate a different loadout of various substances; 4.) Interact with DangIt or other part failure mods -- an upgrade tier can offer an either-or choice as between increasing compression, thereby increasing failure / leak severity and occurrence; or instead, a player can invest to reduce failure likelihood / reduce failure severity / reduce potential repair burden (with no increase in compressed resource capacity as a result of this upgrade purchase.) This means that future upgrade choices and upgrade effectiveness are profoundly influenced by previous upgrade purchases -- do I keep compressing the material further, subjecting the tank material to greater strains and resulting in reduced structural tolerances, or do I invest in strengthening the tank hull design to increase impact resistance for equipment being sent to hazardous environments such as a land-base on Eve or a Tylo landing? If I have a very important and profitable orbital station (profitable in terms of science gain, an RT command outpost, or a fuel depot) located in a spot where dV margins are very tight (Eeloo, Moho, Eve, or Kopernicus-modded systems such as RO / RSS) where it's difficult to ensure that incoming craft will have the fuel needed to reduce their closing velocities in time, so upgrading the impact-tolerances of the parts of this station would make the station more resistance to docking-collisions. Examples of #3, above, all starting with Tier-0 KRnD initial part upgrades with a single Stock Big Orange Tank, which has LFO bi-resource in ratio-mix: 3A -- Convert to LF-only or LO-only, preserving the original total internal volume and adjusting the maximum wetmass as a result, or possibly even slightly increasing overall internal volume because of the space freed up by removing the internal bulkhead separating the twin internal compartments, with a proportionally-slight decrease in drymass. Subsequent upgrades can then compress this mono-tank further, though at a slightly reduced curve of per-upgrade gain opportunities, owing to the fact that the tank has been slightly weakened by the removal of an internal bulkhead and therefore continuing to overpressurize the single larger containment vessel with subsequent upgrades is proportionally less feasible, from a safety and reliability standpoint, than if you were to instead leave the SBOT as a stock-LFO tank and simply pressurize the two compartments equally with each upgrade. For this option to convert to mono-tank, this must only be cost-effective as a first-tier upgrade purchase. The only way to reliably remove the internal bulkhead separator as between the internal compartments after first overpressurizing the twin-compartments is to bleed off the now-overpressurized contents and undo the pressure and compression tolerances back to stock (with no refund in original purchase price, perhaps even a nominal purchase price for the labor cost of the undo) before removing the internal bulkhead. Then subsequent purchases can be purchased as normal, but continuing the exponential cost increases -- in other words, paying to undo the first compression upgrade still counts as the cost-equivalent of a second upgrade, and the now-first compression upgrade of the mono-tank still counts as the cost-equivalent of a third upgrade, etc. Always: Slight (minor but noticeable for expert craft designers) remodel of CoM as between wet and dry states. First-upgrade-incentive: Negligible effect on part reliability. Non-first-upgrade-penalty: Slight, non-negligible effect on part reliability. 3B -- Same as 3A, but convert SBOT to mono-resource of an unrelated type, such as Xe, monoprop, Community Fuel substances such as Water or SolidWaste (life support) or stock-Ore, etc. I speculate that for this to work, some hand-modeling would be useful to analogize resource default-densities of other substances to figure wetmass / drymass values appropriately, both after initial conversion and after each subsequent compression upgrade. Similar to 3A, this can be performed at any time, even repeatedly between several resource type changeovers, but each resource-type change resets the compression / capacity values to a sort of "default." Always: Slight-to-moderate remodel of wet / dry CoM positions depending on circumstances of the selected changes. First-upgrade-incentive: Negligible-to-slight effect on part reliability, depending on above. Non-first-upgrade-penalty: An either-or choice at time of upgrade, between "moderate effect on part reliability with highly efficient use of reconfigured overall internal volume" (maximum capacity-benefits combined across all involved resource types) and "negligible effect on part reliability and reduced efficiency in the use of overall internal volume" (special attention to detail and safety will mean that safety valves and sensor wiring will take up pockets of space that cannot also be occupied by tank contents.) 3C -- Same as 3A, but add a third or, at maximum, a fourth resource to the tank, thereby cutting into the capacity levels of the stock contents and increasing drymass. Wetmass might increase or decrease depending on the changes made. Always: Moderate to significant remodel of wet / dry CoM positions, depending on resource changes involved, especially when adding a fourth resource compartment. First-incentive: Slight-to-moderate effect on part reliability. Non-first-penalty: Choice between "significant effect on reliability with moderately efficient use of internal volume," and "slight effect on part reliability and reduced space efficiency." Note: perhaps one option is to "add a compartment" for battery power (embed a battery system into the tank hull) allowing for simpler but heavier and lower-fuel-capacity self-contained structures with batteries built right into the fuel tanks. I imagine peculiar tradeoff considerations for DangIt purposes, especially for un-kerballed missions. Battery capacity can never be "compressed," but can be "expanded" once and only once at the cost of significant drymass increase, significant loss of resource storage volume available for other compartments (maybe a user-selected decision as to which compartment is cut into?) and significant reliability decrease. 3D -- Maybe tanks have "flow values," representing their valve routing systems. Overpressurizing a compressed tank would initially result in slightly faster fuel outflow, but as a tank drains, flow rates level off. An upgrade option could be to expand the flow control valves in a tank to allow for faster or slower resource flow rates. The inverse would also be true -- on an overpressurized tank, transferring resources INTO a tank above stock-capacity levels results in a REDUCTION of the resource transfer rate. With a flow-increased capacity-increased tank, you can actually deliver fuel to engines faster, resulting in useful over-thrust scenarios for limited periods -- another DangIt tie-in opportunity as to engines. All examples above: DangIt failures can result in internal leaks as well as external leaks, which can create sudden heat buildup leading to explosion hazards unless a tank is vented or drained immediately depending on the substance combinations involved (and heat buildup in the resources in v1.1 means that temperature is transferred when those resources are transferred). An internal or an external leak can also mean a sudden change in CoM position within the tank, which can make attitude control impossible without a lot of attitude control to compensate, engine thrust vectoring, and thrust and throttle limiting. Untreated leaks can even result on CoM imbalance symptoms that get worse as a leak increases in severity (venting escape of resources into the vacuum of space can cause material erosion in the pressure vessel of the tank, resulting in a pinhole leak that gets bigger and bigger as materials continue venting -- fuel escapes more and more rapidly, begins applying noticeable asymmetrical thrust as an uncontrolled RCS nozzle that can't be turned off, and as the hole progressively widens the thrust-vector changes and gets worse because the direction of the escaping jet of leaking fuel is changing according to the size and shape and placement of the hole... until the tank is drained or offloaded, and then the leak stops applying thrust and stops getting wider. Some very severe leaks might not be repairable at all in the field, and moderately severe leaks might only be field-repairable with the tank drained first. This would factor into designs for orbital stations and ground bases, as a prudent thing to do is to include always-empty tanks on hand so that a tank with a sudden leak can always be drained in an emergency without the resource being lost to the environment (remember, v1.1 allows us to consider designs with vastly higher partcounts, this is one of the earliest ways we can take advantage of that in mod design.) I don't have much programming experience (I can learn, I did some stuff with BASIC and VBASIC in high school, so I understand some of the thought processes involved) but I do know how to design math algorithms and how to balance these changes so no one upgrade is overpowered or underpowered. I am officially volunteering to help on this project.

This is one of my must-have mods, right alongside FAR, DRE, TACLS, RT, and a few others. Of course, my preferred modset includes literally hundreds of others (which I was always able to run in v1.0.x in Linux-64) but this is a mod I wouldn't even cut from the list for Windows-32 play sessions. With v1.1 and Win64 a viable option now, I quiver at the thought of the greatness my career saves can achieve! My schooling is drawing to a close, and the last two semesters have been way beyond "hectic" anyway, but even casually tinkering in KSP just isn't something I look forward to without this mod at the ready. @Ethernet, please know that I am one very loyal fan of your wonderful work, and I intend to wait patiently while you re-release your mod for v1.1. If there is anything I can do to help, even if it's something silly like managing the CKAN metadata tracking, please don't hesitate to message me, as I'd be humbled to have an opportunity to contribute.

Unless the actual copy was deleted.

Thank you for this clarification. And for the record, I work in law. With legal writing, descriptions are VERY terse -- but so thorough that they become bloated again. So I feel your pain. Ha, you weren't lying! This made me chuckle. @CrashTestDanny, you got the double negative, right? This mod consumes memory for breakfast.

Very well. I did read the OP and browsed the most recent several pages here at the end prior to posting my question. On your polite suggestion here, I revisited the OP again. I see your disclaimer asking for screenshots (didn't really seem to apply to my question as I wasn't asking for troubleshooting assistance) but I don't see any discussion as to architecture. I do see a separate link to the WIP, of course. What am I missing in the OP, please?

Hey there hi there! 1.) I'm curious, since I just followed the link to Github, and I see the x86 notation in the filenames indicating 32-bit versions. I run on Linux, which has always been capable of 64-bit. Is there a 64-bit version of this mod, either for v1.0.5 or for v1.1? Or was there one on a fork at one point that was abandoned or deprecated? Am I misunderstanding what this mod does to even be asking this question? 2.) Is there any desire to adopt SpaceDock as a repository? 3.) I know that EVE is available on CKAN. I'm coming out of KSP-hibernation from a few months ago. Last I knew, CKAN was... "persnickety" when it came to this particular mod, what with the texture resolution choices (especially for me, with no memory limit and no cockamamie "workaround" in Linux-64). Is this addressed or resolved? What should seasoned players with experience installing and troubleshooting mods bear in mind when attempting to CKAN-manage this mod? Thanks! Love your work!

Edit -- It seems that, at least with respect to my first paragraph, I'm not original in my thinking, as two others have made similar statements. In my defense, I'd read through the original thread that was replaced by this one, and I simply closed my browser tab with the previous pages discussion thinking I'd already read it over. Sorry. ~~~ I note on the front page that a known bug is difficulty with solar panels not working. Is this because of how stock-behavior panels work? What I mean is, if the central black hole (which should prolly get a name -- Centrica?) is currently either labeled as "Sun," or is modeled as the central gravitational object in the simulation -- and the default game presupposes that the central object is kerbol -- then solar panels would actually be keyed to work off the modeled distance to that central object. We already know that in stock, solar panels work according to the inverse-square law, and the orbital altitudes of the six stars as measured from the black hole are nothing short of "gargantuan" with respect to what the stock solar panel inverse-square behavior is designed to anticipate. Ultimately, the solar panels in stock only work from "the sun," and presume that there exists only one sun. We can use Kopernicus and other mods to nest moons-of-moons, and to set kerbol itself as a planet orbiting the black hole with Kerbin as a kerbolar moon, and Mun as a moon-of-a-moon. What we're essentially asking the game to do is to allow "planets" to generate solar output for solar-panel EC purposes, so that we might model the inverse-square law from THEM. And indeed, we'd want to set different constants for each star as a way of simulating stars of different output and spectra characteristics. We'd want to be sure that "stock-for-Kerbin" solar panel EC-productivity would be modeled for whatever any given star's "habitable zone" would be expected to provide, of course. I'd even suggest that this might be a higher priority fix than people would expect, because once we have a mod that can assign different habitable zones for each star, we can then start modeling realistic geologies and atmospheres of these exoplanets.

One and all, I'd like to contribute to this effort. I have no technical expertise, but I do have LEGAL expertise, as I am graduating law school in 85 days (wow!) and my school has free student-clinic representation for non-profit corporate clients. I am based in New York, USA, but I can access other jurisdictions either within or potentially outside of the United States through my own personal network of lawyers, law students, and other professionals. KerbalStuff failed, ultimately, because of a poor incentive-model (cost of time and money) to update and maintain it. SpaceDock, or any successor, will eventually run into the same problem in some form. Squad's licensing, of course, is with Curse. Curse predicates its own commitment to Squad based on an economic model of forcing mod downloaders to physically visit their website and be exposed to banner ads as their primary method of cost defrayment and profit generation. This is reasonable, because mod cloud-storage is not free; mod hosting and listing and indexing is not free; and bandwidth for mod downloading is not free. Indeed, anyone who knows or prefers CKAN understands that Curse is VERY CKAN-unfriendly, as CKAN is based on metadata files that presume the ability to remote-call and remote-download hosted mods -- Curse actually updated their software to affirmatively prevent CKAN from doing it's thing, specifically to ensure that mod downloaders were forcibly exposed to Curse's banner ads. This is why CKAN management favored a mod that was hosted on KerbalStuff, Github, or some other miscellaneous hosting (such as Dropbox / OneDrive / GDrive / etc.) I am unfamiliar as to the exact particulars of Squad's licensing, but I'm fairly certain that Curse's deal is one of exclusivity -- that any other mod-hosting site is prevented by licensing restrictions from adopting any for-profit model that would compete with Curse. My Proposal: With someone else's help, I can act as point man in forming a non-profit corporation of some kind (my own jurisdiction of New York would offer several filing options for this, and other jurisdictions may offer different options, each with advantages and disadvantages.) I can even serve as a member of a corporation's managing board. I suggest we find a way to manage and navigate the existing licensing restrictions, or possibly even negotiate with Squad in good faith to allow some form of compromise solution, that would allow SpaceDock or some KerbalStuff-successor to operate and generate modest revenue from hosting and CKAN integration, not for the purpose of generating lasting profits, but for the exclusive purpose of strengthening the non-profit product so that it remains as available and robust as the technology could allow. From actually offsetting the digital costs of webhosting and bandwidth, I foresee the possibility to manage a small cohort of otherwise-volunteer programmers and other mod hobbyists by actually offering them some sort of financial incentive to donate their time. I'm not suggesting we hire someone full time with salary and benefits, but something that would make their late nights of sacrificed personal time worthwhile. I can be reached by PM here, or by email directly at David.Jacobson@brooklaw.edu. I get a lot of emails from other sources, so to make yours stand out, please indicate "KerbalStuff Successor" in the subject line. I am convinced that there can exist a fully-legal, fully-compliant, self-sustaining solution to this issue, and I'd care to be a significant contributor to that effort. Best, David

Is this mod on CKAN?

Oye vey, a binary search? I have well in excess of 200 mods installed. :sigh: Luckily, I'm running Dated Quicksaves, so maybe reverting to an earlier save will help. If it helps, I can report that I was attempting to nail down a completely different error. I know that my symptom in flight-scene stems from a faulty module on a part, but I narrowed the symptoms down to a stock part. (A Mk16 parachute was rendering with a CoM and FAR aero-texture offset.) I'd just uninstalled Ven's Stock Revamp to see if that would've removed the problem before this particular bork took place. It'll be a day or two before I have to time to go in and re-attempt, but in all seriousness, I was only two or three hours in a new career (with a lot of grindy hard-mode settings).

Sir, Your mod instructed me to post my log file for you to look at, because apparently my career is unplayable in its current state. Have you any feedback? My log is here. [be warned, there're a LOT of mods installed. Linux-64.]

I'm having similar but not identical issues. Did you identify the cause of your symptoms? Did it have to do with a duplicated module from ModuleManager?

I'm running this and a whole mess of other mods in a new career. I have a contract to test the Mk16 parachute, and separate contracts to test a few others. My problem is that in the VAB, I can't get the Mk16 parachute to appear in the staging diagram. On the Launchpad, not only can I not get the parachute to appear in the staging diagram, but it renders as disconnected and outboard of my main stack, by what looks like 4-5 meters to the side. I'm running FAR, and the drag forces and mach effects seems to be rendering based on where it's appearing and not where it's supposed to be, which yaws me all over the place. Also, since it's not in my staging diagram, launching with the spacebar stage-triggers my parachutes at rest on the ground and fails my contract. Any ideas?

Ho. Lee. Crap. This is awesome. I've recently given you rep, but as soon as my cooldown is satisfied, please be on the lookout for some more.

Agreed on the greatness of the mod. If research cost were tied to "difficulty," I hope it would scale. Kopernicus allows not only for modded planet packs, but also the repositioning of Kerbin itself. In my career, Kerbin starts as a moon of a gas giant that is two planets further out than Jool -- this planet is roughly an analog to Uranus, I think. I'd hope that any cost-scaling would be able to reflect new readings, since Minmus is now way down near Moho, I think.

Follow up -- I learned that this is an issue with Kopernicus. Apologies for clogging this thread.

THIS IS AWESOME! Thank you. Do you think that timewarping at KSC can be done if I briefly visit the Tracking Station first before launch? Or would you suggest I do all timewarping in the Tracking Station? (And let's be clear: with KCT, there's a lot of timewarping.)

You're saying that the bounce-on-flight-scene-load problem is a Kopernicus problem? Cuz someone else in another thread just suggested to me that Kopernicus's reparenting of Kerbin resulted in KSC-scene daylight problems (daylight levels are static and to change them I have to reload it through the Tracking Station.)

Nope, same issue. New symptoms too, the terrain came out... I dunno even how to describe it. Jagged? Blocky? But once I got up above 30km altitude, KSC re-loaded with proper contours. At this point, I have no choice but to edit the footage and post it, which I won't have a chance to do until later tonight.

Really? My understanding (which could be wrong) is that any restrictions that come with those parts state that they have to be distributed with the Kethane mod, specifically. I'm not aware of any restriction on how the Kethane mod itself is to be distributed, whether by these forums, CKAN, KerbalStuff, Curse, or the old Kerbal SpacePort.

Nice station ya got there, fellow kerbonaut! ~~~ Is there any known issue from this mod resulting in craft bouncing off the Launchpad on load? I'm very early into a new career save with a lot of hard-mode mods, including KCT. The odd thing is, this symptom only crops up on "real" launch attempts and not on simulation attempts. (I've already posted on that thread with this issue.) Could CollisionFX be a culprit? I bring my question here because my symptom seems to be connected with KJR physics load delay. This is my first kerballed launch, with a thrust-limited SRB-Hammer. I've tried just straight nozzle-on-the-ground, propped up by tailfins, and moored by a FASA Redstone launch clamp. The results are the same -- during physics load into the flight scene, my craft's collision mesh bounces off that of the Tier1 Launchpad terrain. Usually this results in popping up 5-10m into the air, which often causes the SRB to explodify when it lands but not always. Can't stage-activate or context-menu-activate the engine until well after I'm re-landed (which triggers an Achievement which is a problem because I can't activate SAS until after I have control access again. A few times I ended up subterranean, and thrust doesn't seem to work when the nozzle is embedded into the terrain. It seems to be random where I end up, as burrowed is by far the less likely result. Any ideas?

New question: what's the terminology to describe the fact that my KSC-scene sun position seems to be static? That the day-night cycle only seems to update when I go into the Tracking Station scene (or possibly a flight scene, but I'm super early into a new career save and don't have any orbiting flights yet to test this with.) I'm running a super heavy load of beautification mods, including at least one or two other OPM planet pack addons, if that helps narrow things down.