MisterFister

Fair enough. In my own defense, I wasn't sure if goldenpsp was referring to information missing: from my own characterization specifically; from elsewhere within this conversation -- as I commented only after reading through the most recent two or three pages of posts; from within the game with respect to scanning for resources -- which I've only dabbled with, as I prefer to play career mode on hard settings, restarting twice since 1.0 in trying to get my mod list tweaked the way I want it; or from generally elsewhere within these forums as a lack of documentation for the new mechanic itself -- which might be possible, given that I haven't focused myself on finding info about it. I freely admit that most of my exposure to the ISRU is from watching the Hypetrain on KSTPV last weekend and the few YouTube videos that have come out since. While I in no way meant to imply that where my understanding ended, so too did the story; I can instead say that my experienced understanding of Kethane, limited-experience understanding of Karbonite, and extensive vicarious exposure to nuStock all lead me to conclude that the Kethane scanning mechanic, itself, seems preferable to my own play style.

And to what misleading or incomplete information are you referring?

Terriers.

You don't post the .craft for the OP (or me or anyone else) to examine and learn from. Also, did you consider the possibility that maybe the inefficiencies of which you speak were necessary due to the tech tree? The OP doesn't specify which nodes are unlocked, so pulling this over to a sandbox for testing, as I did, might not provide the greatest insight in terms of redesigns.

I suspect that proximity to KSC might be a factor, as well -- if not in terms of SciLab output directly, or the fact that data from further afield is worth more as a baseline anyway.

You're not crazy, I found this thing quite wobbly as well in nuStock aero. I also ran into overturn problems, though on my first shot I managed to get it into orbit with lots of fuel to spare in the core launch stage (the engines were rather toasty, however.) All I did to compensate was to periodically turn on piloted SAS to hold the vector until after my altitude increased, then released it to allow the nose to fall, then reactivated, etc. I think I did that three or four times, and yes, the first was way before I got to 2400m up. http://imgur.com/YOZCKzb I get the impression that you built this in career mode, given the tech. The main issue that I see is that it's a needlenose pair of capsules providing only so much heading authority against such a thick trunk of a launch stage fuselage. With your stationary fins shedding away with the LRBs as well, it means that the much heavier ass end is winning. Make no mistake, however, this is flyable as is.

You realize that contracts like these just require you to activate it through a stage command (spacebar)... it doesn't specify that it has to be activated "for the first time ever." Use your jets to get as close to target altitude as they can. First option: nose up and blast. Engines will flameout. Let them. Nurse the throttle to get whatever altitude you can. When it's finally a waste of effort but your apoapsis will eventually qualify (taking into account future drag losses, which the game doesn't model very well, so you have to guess) switch to flight view, manually shut down your engines, manually put them onto a NEW stage, and then stage-activate them a second time once you're at altitude. Second option: essentially the same as the first, but instead of nosing up and clasting, just switch to rocket mode. Shutdown and re-stage jet engines, activate at target. Third option: NEVER stage-activate your engine on the runway. Instead, control-group activate them. Fly your choice of the first two options. Shutdown engines either manually or with control group command. Then stage-activate at altitude.

Not sure what mods you're running, but you need something live-payload-return capable, which is NOT a standard design feature in most craft. Since you're in sandbox-ish, I advise an SSTO plane. And as an aside, that's how I think SSTOs SHOULD be designed. They should be able to takeoff from the runway with full payload (whatever the payload rating is for your design class) achieve LKO, meet up with some stopoff orbital facility, detach payload, and land empty without refueling itself at the station, and ALSO be able to takeoff empty, get to the same orbital facility, take on that SAME payload, and then deorbit and land safely with the payload undamaged. (Note that this often requires re-strutting the payload within the payload bay, and that essentially means you need KAS, which is not up to snuff yet for v1.0.)

Screenie? They're dicey for me, too. Generally, if it's a multi-passenger contract, I suspect that you need to perform the service for all of them AT ONCE on the same flight for it to count (at least until you unlock docking nodes allowing you to move them around to different landers in orbit.) Do some quickload experiments and se what you can discover. Also, make sure you load your passengers through the crew tab in the VAB.

Mehhhh, I see what you're saying, but I'm not certain this is universally true. I play on hardcore mode, with a few delay-tactic mods (RemoteTech, Kerbal Construction Time, etc.) Even without mods, the Sci and Fund awards for contracts and accomplishments are nerfed, and penalties and costs are higher. These suborbital tourism contracts are the only things that can reliably get me past a few key humps. Some tips, though -- test all craft designs, even small changes, before loading tourists (even at normal difficulty, reputation penalties for losing one are substantial). Also, multi-tourist contracts help a lot too. Even with Mk1 pods, the upside is that you have benefit of all that torque, often before SAS modules, RCS, or steering fins get unlocked. Once you make your first orbit, however, most of the tourists start asking to go to orbit with you, and incorporating detours to Mun and Minmus. Without docking ports or RCS yet, those are generally not yet feasible for me on T3 tech, so it does pay to read the contracts before accepting them.

Could also be a bug. I don't understand why accepted contract would disappear, but I think I had my orbit contract disappear while attempting it (but with A LOT of reverts and quicksaves).It's not even an "accepted" contract, its a default gimme-contract, the culmination of all the World First contracts (distances, altitudes, and speeds). I, too, run into the issue where if I don't mind precisely how I go about establishing my first orbit, I destroy the contract. Even quickloading can't restore it, I don't think. I have done some testing (literally, since I run Kerbal Construction Time -- awesome mod, I highly recommend it) and I'm 80% certain that this speed record is pegged to surface velocity, not orbital velocity. The navball will key over to orbital mode automagically after a certain altitude, and once your oV hits 2500m/s, my sV read only ~2050m/s. With a 4200dV craft restricted to T3 tech, with a single upgrade on Launchpad and nothing else, I can juuust barely make both orbit and this speed record, and the speed record is the more difficult of them to accomplish. I'm not calling bug on this (I can't rule it out, either) but at a minimum, Squad might wanna make the contract description clearer on this one. Update: I've established an equatorial orbit, Ap975km, Pe71km, at Pe sV=2505m/s oV=2730m/s. Still didn't trigger the award. Less than 20 units of LF, too, forcing me to retro pretty close to Ap, and from that altitude, the descent is gonna be quite toasty. :-\

I do, though I pain myself to admit that if this were nerfed or removed entirely, it wouldn't affect my gameplay substantially. I do run CactEye telescopes, though it's usually only toward T5 or T6 on the tech tree that I start actually running CactEye missions. Also, I came here to possibly report an issue with v1.5.3, I just had a reproduceable crash on an install running a small suite of mods. To the best I can read the log, it crashed as a result of a lot of NRE spam. Since you've already migrated to 1.5.5, should I just delete these logs, or would you benefit from seeing them anyway? (I'm in the very earliest stages of a career, T3 tech, running a simple vertical launch and dead stick reentry test in an environment "simulated" by Kerbal Construction Time.) Thanks for an awesome mod!

For the record, I don't have any strict preferences as between Karbonite and Kethane, beyond nostalgia (I experienced Kethane earlier in my KSP-playing career [kareer?]) and, yes, I like the idea of orbital refineries, which is more viable with Kethane than Karbonite, as mentioned recently in this thread. However, what I do keenly prefer as to kethane is the scanning mechanic. I play with a lot of hardcore timesink (anti-instant-gratification?) mods, such as Kerbal Construction Time, SCANSat, RemoteTech (when it finally gets updated for 1.0) and others. Slapping a scanner into "some sort of" valid orbit and instantly knowing all the pertinent info I need to develop a profitable landing profile is not my preferred challenge to myself. Understand, I wholly grok why the stock ISRU scanning mechanic is the way it is; to be accessible to people lower on the learning curve than I might be. If there were a difficulty slider with that, or even Karbonite, wherein I could use some sort of graphical overlay, such as the Kethane hexgrid system, or a SCANSat image inset, to actually worry about supplying my orbiting scanner with the dV needed to get full coverage -- or hell, planning a decent enough insertion to reduce the need for dV-costly plane and altitude changes at all -- then I'd be less disagreeable about it. Factor in the abovementioned mods I prefer to use, most notably KCT, I then have to worry about launch windows and rollout queues and plan my missions accordingly. My $0.02. Both mods are great, though.

Running KSP v.10.2.842 with no apparent issues, though I don't know how to look at the logfiles to see if I'm throwing silent errors (if you'd care for me to learn, lemme know here and I can look it up and post the files to you.) Question, though -- with the increased emphasis on job specialty, I notice that on the launch vessel dialogue, "Randomize Filling" of the available seats seems counterproductive. Is there a way to randomize filling, but specify job specialty when possible? Or prioritize them (50% chance of Pilot, 10% chance of Civilian, etc.)? Or specify fallback options, specifying Pilots but if no more Pilots available revert to Engineers?

The files have the version number inside them. Assuming the mod itself works fine, the update would just be changing that internal number to tell KSP it's all ok. I'm getting that alert with some .9 mods that still work (graphical mods are much less version sensitive)I, too, am running into this problem, though I think I can offer a possible explanation. I just downloaded and installed v0.11.1.19 of this mod and am running it with a few other mods in KSP v1.0.2.842. I suspect that the version checker is simply getting hung up on the "....2.842" aspect. I know that reporting this here means the author will look into this, but I'd care to ask for confirmation that this is a cosmetic-only error. Otherwise, thanks for the awesome mod! This is the only life support mod I'll use. That is actually planned. I had started doing something with Kethane a long long time ago, but never quite got it working right.Giggity, please don't forget this! I much prefer Kethane to the other resource mods, including nuStock.

Awesome mod, I'm glad it's back in development again! Just started playing in KSP v1.0.2.842, with this mod's v BETA 5.2. At startup, it throws an error dialogue, telling me that this mod is only compatible with KSP v1.0 (apparently, the ...2.842 is throwing it?) I know that by mentioning it here, you'll take a look at removing it from the next version. My question for the moment is if you can confirm that this is a cosmetic-only error. Thanks!

I just downloaded and installed v2.0.1 and I'm playing it in KSP v1.0.2.842. It seems that at Day0 of a hardcore career, I can scale up a Flea booster to 10x, which would weight 260t on the pad with a single Mk1 Pod. Two questions -- did I mistakenly throw a setting somewhere such that I have access to scaling things that large without first unlocking the tech tree? And second, if I didn't make a mistake, are there plans to integrate tweakscale abilities into the tech tree? Otherwise, awesome mod, sandbox wouldn't be as fun without it!

To everyone saying "well it works for me" -- you realize that you can have silent errors (in this case, "thousands") without any symptoms that would immediately be visible to a user with no programming knowledge, right? You also realize that, even though this mod worked perfectly fine with v.90 which had the same career mode progression through upgrades to the tracking station, that more than two thirds of the changes to v1.0 was to go behind the scenes and revamp or tweak almost ALL of the code in the entire game, optimizing it to use memory and multithreaded processors, which was never done during alpha, right? (In fact, it was those poor optimizations that caused a lot of the alpha versions to be as prone to crashing as the game had always been -- that's the main difference BETWEEN alpha and beta software development: Alpha is where you test the features and set them up, and beta is where you tweak everything to make the software run smoothly.)

Each of you is simultaneously almost-right and frustratingly wrong at the same time. Terminal velocity is always a problem, and always was. Since terminal velocity is a component of atmospheric drag, and NuStock aerodynamics have changed, what terminal velocity is has changed, but it's no less important. Simply, the nature of that change makes it less of a practical concern for most early-tech launches. Terminal velocity, in any aerodynamics, is simply where acceleration force going forward is cancelled by drag forces working in opposition. Skydivers have this very simple, since their "accelerating force" is always gravity (1G) and always in a straight line toward the hard deck. As they initially jump and enter freefall, wind resistance is negligible in comparison to their body weight, and as such, their downward velocity increases steadily along a linear progression of ~9.8 meters per second in downward velocity for every second spent in freefall -- abbreviated as meters per second squared, or m/(s^2). (Their cumulative vertical distance travelled is an exponential affair, since speed is constantly changing, but that's outside the scope of the question here.) If they were in a vacuum, they'd literally continue accelerating at the same rate literally forever until something changed that -- most likely, impact with the hard deck. (It should be noted that if they began freefall in a vacuum from "really far away," for example the altitude of the moon, their initial numbers would be different, since gravity decreases the farther out you go, so it would initially be less than 9.8m/(s^2), and gravity from other bodies would affect things, but for our simplified purposes here, the underlying truth remains valid: at time of impact, a skydiver would theoretically be travelling at many hundreds of thousands of miles per hour, likely appreciable fractions of the speed of light by that point. Impact energies of a human-sized impact like that would in all probability be the equivalent of a small to medium sized nuclear bomb going off.) Now, that digression seems absurd, and totally is absurd, for the simple reason that people don't skydive in a vacuum -- they do it in the atmosphere. Now, just sitting there at your computer reading this, air is flowing over you, either from the breeze through an open window, maybe you have a small fan on your desk at work, or even microscopic air currents from people in the next room a-la the butterfly effect. All of those air currents across the surface of your clothing and across your skin imparts a very real, very measurable, amount of force -- usually in such tiny strengths that we simply don't notice them. At sea level pressure (which we'll call "100%" for the time being) air has a specific consistency, a specific viscosity or "goopiness coefficient." In other words, it's a lot heavier and harder to push around than pure helium would be, but a lot less substantial than molasses. This becomes important when masses start moving around at higher velocities. It doesn't matter if the mass is moving or stationary, or if the air is moving or stationary -- it just matters that there should be relative motion between them. For example, getting strapped into a harness inside a wind tunnel, where you are stationary but large fans blow hurricane force winds, causes a lot of air turbulence on the human form. The same thing might happen on movie sets simulating dangerous thunderstorms. This principle is harnessed on aircraft carriers, too -- standard flight operations dictate that the flight deck be steered into the wind whenever possible, so that whatever ambient wind speed there is will only make aircraft flying easier, even if only by a margin of however many knots the windspeed might be that day, so that heading into a 15 knot headwind at a ship speed of 15 knots yields a flightdeck headwind of 30 knots -- this means that an aircraft with a stall speed of 70 knots only has to worry about that 40 knot difference when taking off or landing into that headwind that's been artificially inflated up to 30 knots. Aircraft can then land at higher throttle settings, an important safety consideration if the plane misses the deck and needs to accelerate and climb for a go-around and another attempt, and it's easier to hit that flightdeck at a relative approach speed of 40 knots than it would be to do so at 70 knots. Back to the skydivers, though. Ignoring the original flight speed of the aircraft they jump from, since the planes tend to slow down just before a jump happens anyway, the initial "air speed" relative to the skydiver after a few seconds in freefall gets pretty fast rather quickly -- generally, five seconds in, the airspeed is around 50m/s, which equates to 180kph or 112mph -- a healthy gale, trending toward strong tropical storm-force windspeeds. Anyone who's flown a kite, anyone who's stuck their hand out a car window while driving on a highway, anyone who's seen what happens when a bird flies headlong into a window, knows that those kinds if airspeeds can become rather undeniable. In our skydiving case, they actually start to cancel out the accelerating effect of gravity -- the rate of acceleration slows down, and overall vertical speed levels out. Eventually, an equilibrium will form, and the skydiver will just drop at a constant rate, with no significant speed fluctuations or increases; acceleration will terminate, hence the term, terminal velocity. Most skydivers spend MOST of their time around these speeds, generally. A trained professional can go into an intentional nosedive (unrecommended outside of emergency situations to catch up with someone ahead who needs help) and achieve speeds in excess of 115m/s downward travel, but the massive tradeoff for such a maneuver is that it consumes altitude very quickly. Rocket science introduces some extra variables, but the physics remain unchanged. Now, instead of ONE direction (downward) with ONE constant force (gravity) you have all sorts of directions (with vectored thrust and control surfaces) and all sorts of accelerational possibilities (different engine configurations, the ability to change engine throttle settings, different types of fuel problems which would DECREASE thrust, on top of always-present gravity itself) and also the simple fact that you're playing in a wider range of atmospheric possibilities. Generally, skydiving happens within the bottom-most 3,000 meters of altitude or thereabouts. Much higher and you start requiring special equipment to be able to breathe, to say nothing of the potentially dangerous low temperatures at those altitudes, wind shear, and other factors that make non-military skydiving at higher altitudes generally impractical. While it's true that the air density and air resistance values at 3000 meters up is measurably different at sea level, the changes are surprisingly small in the grand scheme, and in any even, the skydiver is VERY quickly returning to sea level conditions as they fall anyway. With rockets, you have to worry about things like the jet stream, global air currents, and the fact that not only does air density decrease rapidly as you go up (which affects air resistance and therefore terminal velocity calculations) but that the atmosphere is really divided into measurably distinct LAYERS, kind of like layers of oil and water in an unshaken bottle of salad dressing. Where those layers have a meeting between boundaries can have some pretty intriguing physics regimes, which can sometimes factor into flight planning. (Indeed, the space race took almost two decades of people working very hard to figure out all of these considerations before we could reliably call our shot and send humans to orbit and back again, whereas here in KSP we can do so in career mode sometimes in as few as 4 launches across less than a day of in-game elapsed time.) That's all interesting, bruh, but what's your point? My point is this: terminal velocity is a LOT higher (and therefore much more difficult to attain with early-career tech levels) in NuStock than it was in oldStock. And really, this was the primary complaint about oldStock aerodynamic modeling anyway -- it more accurately modeled flying through some sort of digital mayonnaise than it could ever have modeled air resistance. Think about it -- how fast can you "run" through water at the beach, without lifting your legs completely out of the water with each step? Now, imagine that same practice, but instead of running through water, run through mayonnaise. You'd go a lot slower -- because your terminal velocity would be a lot slower. Terminal velocity also depends on shapes, yes. This is why a skydiver can still fire a rifle downward without the bullet coming back to hit the shooter, because the streamlined bullet has much less air resistance, and therefore a much HIGHER terminal velocity, than the diver that fired it. Wingsuits, on the other hand, allow a diver to intentionally increase one's air resistance, thereby reducing terminal velocity, allowing one to bodyglide and steer. Streamlined phallic-shaped objects can cut through wind resistance more effectively, such as arrows, missiles, and vertical rocket stacks. But the underlying physics remain the same. oldStock aero allowed us something redonkulous, like ~150m/s or something, in sea level terminal velocity for the average vertical stack rocket (calculated strictly on mass, not on shape). nuStock on the other hand models closer to ~380m/s terminal velocity at sea level for the average vertical stack, which no average rocket would ever attain or bump up against, because by the time you're going that fast, you're high enough so that atmospheric density has dropped, and THEN your new tV is >600m/s. As long as you remain prograde, terminal velocity will never be a significant issue in nuStock aerodynamics during a normal career-mode ascent program. Sometimes to do things you NEED to divert from prograde, but then it's not really fair to call it "lateral tV" or "collateral vector coefficients," it's just "drag." Fly safe! /lesson

Just because it functions with no user-visible symptoms doesn't mean it's working properly. Often times mismatched mods can throw silent errors that accumulate behind the scenes, often not causing gameplay symptoms until deep into a play session. ... That said, the KerbalStuff page for this mod flags it as 1.0 compatible. Without the mod author editing this OP to reflect that, or any other reference in the KerbalStuff description to indicate 1.0 compatibility, I've been burnt before. Regardless, I'll try it.

For best Up-And-Comer, I nominate Gordon Gillespie. His channel is at For Showcase, I nominate his Better Than Starting Manned series, at

Does anyone have any word on why KSPTV and the Lolbster are parting company?

You can mount your SRB the same as you did for the Skipper. I suggest draining the solid fuel to reduce launch weight. "Immersion"-wise, maybe testing the SRB at altitude is necessary to confirm ISP predictions? (In which case, launching with no fuel breaks this.) A jet engine with no intakes tests turbine bearing pressures? *shrug* Oh, and with TweakScale, you can shrink your test payloads down pretty decently. I once grabbed no fewer than give "test at altitude" contracts. I reverse-stacked them on the nose of my pod like you did with the Skipper, with no stack separators between them. Just stacked. Adjusted staging so I could activate them in sequence at the appropriate altitude checkpoints. Recovered them. Something like 100 science (from a paid flight test mission!) and 278,000 funds. v0.24.2.

Interesting. This seems to assert several results. First, it apparently confirms my hypothesis that root part placement seems to affect bend-point. Second, the multifaceted overlapping evidence of phantom acceleration most definitely corroborates previous observations that this is indeed a fully fledged kraken. Third, the static orbital velocity readout is peculiarly intriguing. The phantom acceleration seems to be imparting orbital energy, NOT relative velocity. I wonder how the core KSP-code imparts dV changes. I would be willing to believe that the code manipulates raw orbital telemetry data and then conically-projects the resulting trajectory changes. This would explain why persistence and quicksave files look the way they do and respond the way they do to manual editing and the HyperEdit mod. Separately, it sheds alternate light on the KSP facility career tech progression's notion of needing to update the tracking center to allow for patched conics, and by extension, maneuver nodes and vessel targeting. Further testing is indicated. IMPORTANT!: Sign up for a Dropbox account if you have not done so already. Installing the client may make testing more convenient for you, but since you'll be sharing (or should be sharing) test and experiment data with us via hyperlinks to dropbox folders, I imagine it would make no difference to us. I suggest that it might be especially important for Claw to have access to this raw data, given his mod status, tenure and reputation rating with the forum, and his obvious and avowed interest in these experiments. Perhaps segregated subfolders with persistence and quicksave files, raw screenies, and .craft files used. Ideally, I think we'd benefit at least for a few weeks from a hosted copy of your install backups, complete with GameData folder versions as you run through experiment stages. "GameData 1, original config," "GameData 2, stripped of mods back down to stock," "GameData 3, restored X mod from backup," "GameData 4, restored Y mod from backup," "GameData 5, restored mods XY together from backup," "GameData 6, restored X mod from original," etc. Within those GameData folders, provide perhaps something as humble as a .txt file with observations and experiment notes, possibly with filename references to screenies and other data. Be sure to include .craft, quicksave, and persistence files within those GameData folders for easier result tracking. For this ideal version, storage needs can expand quickly, and admittedly, free Dropbox account sizes would likely be insufficient. I, however, have a fully paid subscription to Dropbox with more than 80% of my total 1TB capacity available. I can create a folder and share upload access with you for hosting purposes. This would require you to have an active Dropbox profile. PM me for details if interested. Side question: do you still have your 0.25 install (or any other version's install) backed up from before you re-installed v.90 from Steam? I have 0.25 backed up and 0.24.?? that I can make available for testing purposes. Follow up hypothesis 1: Since root part seems to define bend-point location, perhaps the presence, or proximity (as defined by .craft file, not defined visually) to the root part, of nearby child-parts (as defined by .craft file vessel assembly-logic tree) that are physicsless (landing gear, ladders, RCS jets, etc. -- possibly fuel lines? maybe, maybe not, since fuel lines were just completely custom redesigned from the ground up for v.90beta) affects kraken behavior or emergence in some way. Public posting of .craft and persistence / quicksave files would be essential for this, and full hosting of detailed KSP installs / GameData evolution, as described above, would be highly beneficial to testing this particular hypothesis. Follow up hypothesis 2: Since it seems as if one possible explanation MAY be that acceleration (or stabilization, or floating point corrections, etc.) is being applied to SOME orbital properties while IGNORING corresponding changes to orbital velocity -- resulting in increasing eccentricity of the orbits as shown in your data here -- I wonder if those changes can be made visible in before / during / after quicksaves. (You can individually name multi-version quicksaves with Alt+F5 from the flight scene.) Control for possible corruption within the mods. Find and download backups now of the originals to the exact current mod versions (in case the mod evolves or is updated in the meantime, since as you rightly point out, results may take time.) If one mod's restoration yields experimental results, try to see if the same behavior exhibits from both your backup copy as well as a re-download copy. Perhaps I spoke too soon to call it "slinky-kraken." Re-visiting the photos now, it appears to resemble the neck of one of those bendy-straws we all used as a kid. "Bendy-straw kraken"? At any rate, this behavior above may prove useful. Or not. Hmm. I'm not experiencing this kraken right now. Are the non-root parts pulled downward onto impact trajectories? Could Ghost Kraken have been "fixed" and now it works in reverse (parts pulled off remain in orbit, but to compensate, control pod is boosted up to phenomenal apoapses)? I note how this wiki entry speaks of "command pod." Prior to v.90, the ability to re-map root parts was only available through a mod. Now it's stock. This may mean that root-part experiment was never carried out before, especially since for a long time, command pods were the ONLY parts available as root parts. Non-command-pod parts weren't even available for selection in the VAB / SPH until after a command pod was placed. This was even before probe cores existed within the game to begin with. Then probe cores were introduced. Then with a more recent version, available root-part options were made possible that were not command pods or probe cores. The data you quote from the Ghost Kraken wiki provides no context as to when those observations were recorded. This bendy-straw kraken might be the same Ghost Kraken, or it might be a new species of kraken entirely. (If it's the same, I think Bendy-Straw Kraken or Slinky Kraken are much more useful terms than "Ghost Kraken." At any rate, it would be easier to search for in the forums for new users who might not have heard of the Ghost Kraken.)

Why was the forum member list disabled? I viewed it not even three days ago and went to revisit it today, and the function is marked as disabled. Was something brewing? (If this post is unwanted attention, I'd ask for a mod to please close / delete it and message me privately to lemme know to hush.)