damerell

I find this completely remarkable. It was entirely obvious to me. I don't see that "supports N kerbals" admits of any interpretation but the correct one.

Well, no. In general, they don't carry such text, and there is no credible evidence anyone has ever accidentally microwaved a pet. (The persistent urban legend comfortably predates the invention of microwave ovens, no less). I don't think the description should be changed because of some entirely hypothetical population of idiots who enjoy KSP and use TACLS.

That seems entirely an entirely obvious consequence of it supporting up to N kerbals. I cannot imagine why anyone would suppose it would _stop working_ with N+1 kerbals, rather than just not be able to keep up.

"With more Kerbals, your mileage may vary, but it's definitely worse" is frankly gibberish, and I don't see what's wrong with the original statement. "Supports up to N kerbals"; the converter can keep up with the CO2 (etc) generation from up to N kerbals. That seems entirely clear to me.

Huh. Do you have some sort of Supplies to/from TACLS conversion, or just try to meet the requirements of both independently?

I don't think it's useful to compare to the MPL at all, but rather to be comparably effective to the unbroken bits of stock.

This is a fair point, but equally the MPL is so horribly broken, I'd hate to see every mod feel the need to follow suit.

I always thought Stupidity was a bit of a silly joke. Kerbals aren't stupid; they're foolhardy. [1] Their engineering is perfect; their engines always light, their tanks never leak, their airlocks never jam (and don't even take up any space). I'm glad MKS doesn't use it anymore. [1] This is because they are haplodiploid, but that's a joke for another thread...

Steering in reverse, IIRC. If you press left, a tracked vehicle rotates the same way whether it's going forwards, in reverse, or stopped. A wheeled vehicle rotates to the left when going forwards and to the right when going in reverse. What should a half-track do? Probably not have the wheels try and guide you around one way while the tracks try and rotate you the other way, anyway.

Wait, so capped at 30% of the old efficiency?

This is a natural consequence of the square-cube law; double the linear dimensions of the SRB and the mass increases eightfold but the aperture at the base increases only four-fold. You'd expect it to have to be reengineered carefully to preserve the TWR, not just scaled up.

Check it works with a manual install, and submit a PR to CKAN to fix the metadata, or an issue to CKAN reporting that it works.

If you use TACLS and Universal Storage, that contains a useful hydrogen-oxygen fuel cell that is my mainstay for electrically powered roving.

Whoops! I tend to stick to the OX-STAT panels - the deploying ones are just too fragile for vehicles.

A motor doesn't care about the KE of the body it's accelerating, but it does care how fast the shaft is turning, because it has to push it around further every second. I'm not sure how to explain this (and as luck would have this, I am trying to write this comment after a healthy intake of er yeasty beverages) but I should try considering matters without time as a factor. To push with a force of 1N through 2m is clearly twice as much work as pushing with the same force through 1m; to turn the shaft two revolutions exerting a torque of 1Nm is twice as much work as turning it one revolution. Given that, if the shaft revolves twice a second rather than once, and yet we keep pushing it just as hard all the way around, we have done twice as much work that second - twice as much power.

Power is proportional to torque * rpm in the same way work is proportional to force * distance (and hence power pushing something in a straight line increases with the speed of the object). An ideally efficient motor exerting torque at 0 RPM burns no power because it does no work - of course, a real motor burns power from its own internal losses - just as you do no work shoving an immovable object. This is a bit counterintuitive, but what it comes down to is that it takes more energy to shove something (with a given force) a long way than a short one.

If you're willing to go as far as TweakScale, TweakScaling up stock batteries produces - because the small batteries are longer in proportion to their width - thick large radius batteries with huge capacities. Nothing OP - the charge/mass ratio is unchanged, and you could stack a lot of the thin stock batteries to get the same effect, but it keeps down the part count.

Gosh, the shape of the efficiency curve is another question. I hope I'm not just reiterating what I've said before, but with your torque/RPM relationship, maximum power output is always at exactly half the maximum no-torque RPM. My suggested part efficiency is then the ratio between input and output at that half-max RPM. How an efficiency curve affects power usage at other RPM is a separate question to that; all I'm trying to suggest is a value to avoid your hardcoded max power (which bakes in a hidden overall efficiency) and provides an easy way to differentiate wheels and tracks. I quite appreciate this is all a bit beside the point when you're just trying to get something out the door.

Ahhh. That makes sense. I'm playing about in sandbox so of course the extra costs weren't evident.

I'm a bit confused about the new roles, and I think I'm missing something obvious. (Vexingly, the comment on them "spelled out by RoverDude" was lost in the threadmageddon). From the table on the Wiki, it seems that the classic three roles are "just better" than the others - why bring a medic, farmer, or biologist, when a scientist can do all three?

Well, you're implementing it, sort of thing, but I am a bit concerned that with no inherent link between power use and the power output that would be calculated from the torque, you may end up with parts with wildly varying (and perhaps >100%) efficiencies. In particular if these values are TweakScaled incorrectly that is almost bound to happen. I've re-edited this to reflect that you're trying to get a real-world efficiency curve, which is ingenious, and hence is why my idea of a fixed partEfficiency won't work. However, rather than being determined in the configuration file, the maximum power output could be calculated from torque and RPM at the "sweet spot" in the middle. The advantage would be that the power usage for parts will be "just right" - if someone does go in and halves the max torque, hey presto, the power usage will halve as well. Of course this will be very advantageous when TweakScaled. (I still think power usage should vary with part mass. In a TweakScale world that could be achieved by multipling up max RPM and torque by factors that multiplied together give the cube of linear dimension...)

I agree that's true in reality (but I'm saying I was wrong before and there needs to be an explicit one in-game or of course comedy will ensue at 0 RPM).

Thanks. I must have missed that on the Wiki. Sorry.

Of course this was not quite right. If torque is inversely proportional to RPM, that would produce infinite torque at 0 RPM and produce a curve on the graph not a straight line. Oddly http://lancet.mit.edu/motors/motors3.html which you cite above first says "torque is inversely proportional to the speed of the output shaft" and then shows some straight-line graphs which show nothing of the kind. :-( I think Tiktaalik is correct when they write that real EV applications typically show an inversely-proportional relationship with a torque cap. I still think what I wrote above is basically OK, but there needs to be a torque cap to prevent silly torque values at very low RPM. Rather than set this explicitly (with the usual issues about getting it right and TweakScale proportions) it could just be a fixed proportion of wheel diameter which would naturally make it higher on bigger parts. I'd determine the proportion by taking some part and seeing how much torque it produces at 5 m/s then guessing that's a reasonable cap.

Please, what's the current state of play on using MKS with TACLS? I remember vaguely there were some trial configurations in the old thread, but of course that has been eaten. I've worked back through this thread but found nothing - apologies if I've missed something.