damerell

Mmm. It had struck me that it's about as far as Kerbin, but I spent at least half of Kerbin at sea with the rover sailing itself. I think for "Elcaneverything" I plan to start at Moho and work out, so it'll be a fair time before I get there, at least. I might have improved my tools.

I fear this may be one from the department of stupid questions, but my understanding is that the .mu files are compiled by Unity and some of the wheel characteristics are already baked in. If that's so, please, are the corresponding source files available? I'm trying to figure out which bit does what, so to speak, and have the impression I'm missing some of the pieces.

I'm not looking forward to Tylo; if there's one thing my lander project isn't built for, it's high-g vacuum worlds.

Literally less efficient, as in EC in to Ore out?

Not quite. I saw the rolling resistance term in the recent source, which is a good idea, but fundamentally the issue is that power isn't proportional to torque output against losses. It's proportional to force times distance over time. ("Over time" is not the objection here, we understand when we say "power" we actually calculate energy usage per tick). (Since torque is in Nm and the force is ultimately applied at the rim of the wheel, the distance terms cancel out nicely). ie, if you're going twice as fast and applying the same amount of shove, you burn twice as much juice. An idealised electric motor shoving as hard as it can but not getting anywhere burns no juice (of course, real electric motors are non-ideal and there are losses internal to the motor that show up as heat). This may be initially counterintuitive; it's masked in most motors (and KF parts) by the way maximum torque falls at high speeds. (Which reminds me, I need to look at the torque curves for the KF motors to see what they appear to look like compared to real electric motors). This would have been an edit but these stoaty new forums won't let me edit posts half the time!

I have hardly been looking closely but I haven't been aware of any very substantial changes. I'm one of the forkers; I intend to look first at the issue of power consumption. I hope that's likely to be of some use.

It was more long in real life than in play time - I just didn't play very often. I don't call it a tank just because it has treads, but it is fairly indestructible so take your pick, I guess. :-)

Github shows https://github.com/BobPalmer/NuclearRockets/commit/8826e1e9ba063808a2762750ba4e1bf26aa29ebb as version 0.1.3.

GWR stands for Gresley Was Right, as I recall? :-)

It does have something mislabelled - obvious from reading the plaintext strings in the .mu, but I used taniwha's tool to import it to Blender to make sure.

It doesn't, although it does explain why one Mole Track wheel doesn't rotate in sync with the others. I don't yet have an explanation for "rover's droop": I didn't take many external shots but this image shows it, with the forward wheel in each set dipping into the landscape. (On the other side the rear wheel droops because the tracks were added as subassemblies not by mirror symmetry). Unfortunately it only seems to occur after long periods of roving, making it hard to reproduce.

KF uses Vessel.GetTotalMass(), it's not adding up the mass of every part on the vessel itself.

One idea I had when looking into the KF plugin was to add an explicit on-off switch to all KF parts. This would be particularly useful with the screws, which churn away quite unpredictably, even when their torque setting is zero. However, it would also mean that a lifter carrying a rover wouldn't have this issue - a lifter's mass unavoidably changes every frame but if all the wheels were shut down they wouldn't care. The check could also be not for a tenth of a unit but for (say) a 1% chance in vessel mass since the recalculation was last done.

Without wishing to be Captain Obvious, there is one thing you should try first of all.

"Didn't", maybe? Thanks. I'm glad someone read right to the end (although ultimately I did it for me, sort of thing...)

I'm finished. It's been a while, since I've only played in fits and starts, but I'm around Kerbin.

I must remember the JSI cameras are better in low-light conditions than the ordinary kerbal's eyesight. I can see land here on the external camera which has only been visible out the windscreen because it occludes the stars. You can see from the BTDT track on ScanSAT that I drove over the headland in the previous entry rather than sail around it. Oddly, I've never been to the abandoned airstrip... well, now I have. Land ho (again)! The mainland could have been spotted earlier; however, Litzi was asleep and Podpont and Jeanette were attempting to operate the Koffee machine. As a sting in the tail, as soon as I touched land, I started to get a huge phantom steering input which I'm quite at a loss to explain. I had to limp over to the KSC using MechJeb's Rover Autopilot and yaw control; hence no fancy arrangements, but get the rover to the West end of the runway and shut down. Success!

I don't know what any of the other recent posters in the thread have done. I've just finished a circumnavigation of Kerbin on KF tracks and spotted some issues I intend to try and fix.

I awoke in the middle of the night owing to a biological necessity to discover not only had I cleared the first headland but I was at about the right time to steer for the second. Hooray! Then the alarm woke me to discover... well, good timing, but not so much on the course calculation. Not long now...

I've been digging into the innards of KF and spotted two things. One is that MoleTracks.mu seems to reference "RoadWhee2". I wonder if this explains why one Mole Track wheel always droops into the landscape. More seriously, and feel free to tell me I'm wrong, KFModuleWheel seems to have power consumption per unit time be proportional to torque. Of course work is proportional to force times distance & hence for a given torque, power consumption should rise at higher speeds (with a fix to ensure some power consumption at zero speed and to limit or eliminate regenerative braking). This is perhaps why the power consumption for many KF parts seems to be absurdly low. A fix to this would also open the door to parts having a maximum power input other than that implicit in the torqueCurve.

You may also find that some of ours are trickier to drive than they appear. :-)

I altered course again to shorten my route to the sea - sea travel is just much easier. Here is the first glimpse of the sea at last - the final bit of land was frustratingly bigger than expected. I must have crested a dozen ridges half-expecting to see water only to be greeted with the sight of the next ridge. Here's the good ship Mark Four setting off from the coast. Really feeling the lack of one of the propellors with solars going full whack and the fuel cell in reserve - charge to spend and nothing to spend it on. Here's a cockpit view; I'm steering 275 to try and clear the headland to the West.

I'm on the final leg. Does anyone know of a fix for the issue that some surfaces are completely black at night? In the daytime they look normal but at night no amount of headlight can light them up.

I changed course to the South. The Waypoint display is leading me on a great circle course but of course I intend to drive up the Equator, more or less. This Eastern continent is full of good scenery. Sometimes you just come over a ridge and whoah: Cor! Blimey! However, the old vexation that in the dark some surfaces can't be illuminated at all has finally bit me. I have no idea what happened here, besides suddenly being upside down. The loss of an electric propellor before a sea crossing is going to be pretty annoying, but not critical. Does anyone know of a fix for that? For my part, I think MechJeb's Stability Control needs a bit of tweaking.

"A rose, by any other name, would smell as sweet". At the point it is released to a significant proportion - perhaps the majority - of the playerbase, calling it a pre-release does not make it one. This sort of fatuous hyperbole is not very productive.