damerell

That's not physically impossible, but it's going to be horrendously inefficient weight-wise compared to just bringing some RCS fuel. Also, those "used" reaction wheels aren't like used batteries. They're spinning away like crazy. With the best design in the world, some of that spin will make it back to the ship, so you'll have to constantly expend energy on keeping them spinning. They're also gyroscopes, of course, so any other rotational maneuver will cause them to exert lateral forces on the frame of the ship. You could drop them overboard... but, again, if you want to throw something away to get rid of unwanted angular momentum, use RCS.

Good work. Minmus was my first, so looking back on it it's a bit "if I knew then what I know now"...

I wouldn't. The working set is smaller than the total allocation - much smaller, I'd imagine.

Did you check to see if you can download that file manually? (Of course not). I get "404 Not Found". A quick look at https://github.com/KSP-RO/TacLifeSupport/releases/ tells me that the correct URL has "v0.12.1" not "0.12.1". https://github.com/KSP-CKAN/CKAN-meta/blob/master/TACLS/TACLS-v0.12.1.ckan has and from the history has always had the correct URL in. Is there something you're not telling us? Did you copytype not cut and paste that error message?

Also, you can press Mod+F12 during the load and view the debug log, which might make for a better bug report.

You have been busy! I've just been through the remaining albums. Most interesting.

I think it's wrong but I also think conceivably I should work out how to build the thing myself and tinker with it. :-/

Hm, that makes it clearer; thanks both. I think what actually needs to be done is to apply a hit-normal force (at the top of the suspension travel) which will produce a force corresponding to the suspension force. The suspension force is known and the hit-normal force is the suspension force divided by cos theta [1] (since cos theta <=1, this makes the hit-normal force greater than the suspension force). This should be capped at some small multiple of the suspension force to avoid comedy ensuing when ramming the wheels into walls head-on (which _does_ produce very large forces - the vehicle will want to bounce rigidly and/or crumple - but the combination of the interval between updates and the lack of modelling of the springiness perpendicular to the suspension axis could produce crazy-huge values in simulation.) In Shadowmage's diagram above, then, Wheel 1's suspension compresses less (as you'd expect because gravity is acting on it less directly) but the suspension force is then divided by a smaller cos theta to produce the same upward force as on Wheel 2. [1] As above, theta is the angle between the suspension axis and a line from the top of the suspension travel to the hit, possibly reduced in absolute magnitude to cut down on crazy results and allow for pneumatic tyres and other off-axis compression.

Seems reasonable to me. Indeed, I think I'll have a second silly question, if I may; surely this only comes into play if the wheel isn't touching something? Otherwise its velocity is constrained by where the ground is each tick; its velocity relative to the craft is equally constrained by the wheel ground-hugging and the craft being wherever the forces, suspension included, think it is. I kind of feel, even having read the code, that I'm missing something fundamental about the implementation. Oho, a third silly question. Currently it looks to me like the full spring force is applied at the hit, normal to the hit (KSPWheelCollider.cs, line 453). Surely it should always be applied on the suspension axis (with perhaps a small fore-aft shift to account for tyre compression [1]) at the top of the suspension travel? That is the force the rest of the vehicle sees. The force available for traction is then normal to the hit, but is the suspension force times cos theta, where theta is the angle between the suspension axis (with the aforementioned shift) and the line from the hit to the top of the suspension travel - it's easier to get traction with your suspension pushing the wheel down than by just rubbing a wheel up against something. (To pick an extreme example, suppose we could detect a hit at the _top_ of the wheel. cos theta is then -1 - and sure enough, we'd need a negative suspension force to press the top of the wheel against that surface). This looks at first glance like conservation of force is violated, but it's not - the lower end of the suspension is pushing just as hard, but little of that force is available for tractive purposes. Imagine in the current implementation a vehicle has all its wheels leave the ground and shortly after hits a near-vertical wall (wheels first). In either case, the front springs will suddenly squash as it encounters the wall. In the current implementation, it'll rebound backwards (odd, since the suspension springs weren't facing the right way) and continue to fall, staying about level (almost no vertical force from suspension). In mine, the front springs will shove the front of the vehicle upwards (because the impact tick squashed them hard, they'll recoil with more force than one g) but the back will keep falling, risking a backflip. [1] This isn't needless pedantry; it'll help with contact with near-vertical walls.

I seem to be in charge of asking stupid questions, so: why are we trying to derive the sprung mass? I'm not sure for what purpose it is needed. (I know that rolling resistance depends on it... but actually rolling resistance can and should be derived from the spring's compression - if, as you suggest, a rocket engine is pushing the vessel down, that should increase rolling resistance.)

And I suggested already trying installing on a bare KSP; or if you read back, you'll find the suggestion of trying a manual install if CKAN fails (or vice versa). So, try that?

Oho, I understand now. Thanks.

Call me stupid, but surely a spherical collider is necessarily parallel to the wall?

Well, answer the questions they always get asked - how did you install it, and what did GameData look like when you were done, and what happens if you try in an otherwise bare KSP install?

The USI mods have TACLS support and agroponics parts, as mentioned two posts above.

Pick one yourself. You'll have the same 1/12 chance of being right as anyone else. Normally I'd suggest you ask nicely rather than making demands, but no matter how nicely you asked you'd still get a wild guess.

Look at my PR for Orion and I'll look for this bug in return. :-)

The USI mods (other than USI Life support) have TACLS support and include some agroponics parts. There are other greenhouse models to which a Module ResourceConverter could be added. However, the implementation you suggest would not be sensible - it would permanently destroy water, with the greenhouse apparently producing dehydrated space food.

As far as I can tell, tracks could continue to be simulated as a set of (as far as the game knows) independent wheels with the part reporting a RPM figure that's the average of the grounded wheels. The only thing I'd add to that is (as suggested before) that the available torque be calculated per-part and divided between the grounded wheels (if your wheel module can sensibly determine this, to each wheel in proportion to the amount it could handle before slipping).

Then you don't have a memory management problem; the OS will page out the bits of that 8G that aren't being used. DTL was a good thing in the 32-bit days, but it really is never worthwhile to try and prempt the OS's memory management if you don't have to.

I'm back from Leipzig and am following this with bated breath, since I'm no use at this stage. (To whoever asked about CKAN support earlier, however; since I am the one person involved who likes CKAN, I will do my meagre best to ensure everything works correctly.)

Or you (which is spelled thusly) could just use a swap partition (in Windows-land, "page file"). It's not like all 8Gb is in the working set.

RemoteTech would handle it, but you'd have to give the order to thaw a kerbal and then very carefully time-accelerate away that day. What I'd suggest is a kOS script lurking which will unthaw one when the correct conditions are met, which would be instantaneous.

Re sphere colliders, I was wondering if they will give unexpected results with very large wheels with flat bases such as on some of the bigger track units?

It might be better to say that Curse intentionally blocks automated retrieval of mod data (eg by CKAN). A Curse-hosted mod can be in CKAN; but a human has to come and say it's updated every time.