Kenobi McCormick

It's worth noting that KSP is not the most graphically demanding game in the world. The sheer bulk of its rendering is done on the physics side. I'm not surprised at all it runs fine on integrated graphics if you've got a beast of a CPU, conversely my GTX960 laughs at it(I can waggle the graphics settings wildly and not get a single twitch in my framerates no matter where I put those sliders!) while my AMD 720BE tricore chokes and dies if my partcount creeps north of 150-ish.

I run sports cars up and down that T1 runway all the time. It's great fun and you need little more than a foot of suspension travel to bomb up and down it at 35-40m/s no prob.

You're saying the T1 dirt runway is post-apocalyptic, yet apparently obliterating half of KSC in the name of testing a 4x4 isn't? Sense: Your comment makes none. Also I'd love some Fallout themed parts for KSP.

MY favorite is actually the Tier 1 dirt runway we get. If we could put one of those next to the upgraded runways specifically for vehicle testing...

I raise you the Kettenkrad. Those things are the closest historical analogue to the ATV-with-tracks, they predate power steering, predate epicyclic gearboxes, still had the clutch-brake system integrated into the handlebars. IIRC they would use the front wheel for gentle turns, but after about ten or fifteen degrees of steering input linkages attached to the front fork would begin to actuate the track brakes and steer it via clutch/brake. You could also run them with no front wheel fitted at all, if you so desired.

Such a thing isn't really feasible. It's ready when it's ready, be patient. Rushjobs are worse than waiting with nothing.

I can't bring to mind a single tank that tried to use a friction drive between its drive wheel and the tracks themselves. Dating all the way back to WW1 when we were still calling them tanks to disguise them as water transport vehicles they used toothed sprockets interfacing with holes in track links for that. T-34, BT-series, T-44 used an inverted version where the drive sprocket accepted the guide horns and pushed them instead of inserting teeth into holes/gaps to drive the track that way, still a zero slippage system unless there's something majorly wrong. They need good torsional rigidity, yes. I've noticed that when turning /35th scale tank models into RCs. I tried to drive my KV-2 on the kit supplied rubber tracks but they just twisted right off when steering it. The metal tracks I replaced it with will form an S-shaped pattern on the ground if the surface upon which it tries to turn is substantially grippy. If you traced the guide horns at each end along where the overall track lies you'd find the exact width of the gap between the inner and outer halves of the road wheels. that is the flex I was pondering.

Unless the drive sprocket is stripped out there should be zero slip whatsoever between the sprocket and the track. Generally, if they're slipping, they're seconds from throwing a track completely. Stab a '0' in there and roll with it. The slippage comes from between the track and the surface upon which it rides. The slip I was referring to is between the road wheels and the track links, and it's in a lateral direction. When trying to turn the track has to slide against the ground, which the guide horns allow for when they interface with the road wheels, idler wheels, return rollers. However, the gap they run through is significantly wider than the teeth themselves, that plus the natural flex in the track means there's some slippage there. IT was mostly an academic question, no reason to model it for our KSP module as it has zero effect on the function of the track.

That is friggin sweet. Glorious progress! It makes me kind of curious whether or not tank road wheels flex significantly when steering like car tires do...well, the rubber part of the ones that have rubber parts anyway. Friction against the track links has to be substantial and you'd expect the relative movement between the hull, ground, track to cause some slippage between wheel and track. The solution to that is, simply, 'We cannot provide support for bugs created by third party mods at this time. However, we are working with the major mods that would potentially cause them....Tweakscale, being an example...and hope to be able to fix the problems/support such installations in the future. Thank you!'

Eh, Source has its flaws as well. For starters, the fastest any object can move through a Source map without some hacking is about 115MPH. There's a hard cap built in, never a problem in any of Valve's games but it very quickly became one in Gmod once we figured out how to get our cars moving that fast. A plugin mod exists to remove this cap, using that makes the game rather prone to crashing from time to time. There's also an angular velocity speed cap, which when met, will cause wheels to spaz out/do really bizarre crap. Ever see a car suddenly fly up and hard left because it crested 74MPH? I've had it happen to mine before, hit angvel cap on the wheels and physics just broke down. Constraints behave in silly ways, the map system is of course wholly unsuitable for KSP...and modding it is not easy. Unity is most certainly more modder friendly than Source, no doubt, and honestly I'd use it for KSP before I used Source.

The Source engine, designed from the ground up to be a first person shooter, handles wheel physics better than KSP! Go play Gmod. There's no special module in that game to handle the interaction between something round and the surface upon which it rolls. The basic physics properties of the surface, of the wheel, handle all of that. How your car handles in Gmod is 90% how you set up the suspension constraints, 5% how you set up the controls, power system, and 5% hoping that you don't get constraint spazz when you run over a small prop left on the ground by the newbie spamming thrusters and soda cans. I don't know if Unity supports that sort of level of physics, though.

DEMV series. Marks 1, 2, 4, 5, 6. We never got III and he was WIP another one before he went poofski. I still use the cockpits but his wheels were rendered obsolete when I got the RollKage/Kerchelin wheels, and those were put into obsolescence by the long tracks from this mod.

........full analong instruments?! SHUT UP AND TAKE MY SPESOS! I absolutely love analong meters. They look so much cooler than digital ones.

You wouldn't need any special equipment in the tracks, though, to at least take advantage of the effect to brake. All you need is a speed controller that shunts the motor contacts from the EC source to resistor networks and you get the braking side. You waste the energy, admittedly, but still stop no prob getting the braking effect I'm calling for. There's more than enough room in the long tracks, at least, to hide said resistor networks. Could also be done with a seperate part, I s'pose. Have the plugin scan the craft for the resistor network part on unpack, if detected, enable the electric braking. If not detected, no electric braking. Or, we could have resistive networks the default state and have a seperate part that, if detected, would dump power back into the batteries first rather than just waste it as heat? It'd be nice to, rather than waste it, dump the EC back into the batteries. But, I 'spose we'd need those resistor networks anyway, for realism's sake. Batteries have a fixed amount of charge they can take and it's not exactly realistic to exploit how KSP doesn't seem to factor that in when applying EC to a fully charged battery. You wouldn't want to dump what, in all likelihood, is several hundred kilowatts per second(You do the math on a ~15 ton flatbed truck trying to whoa down from about 50MPH I don't understand those sorts of equations :P) back into an already fully charged battery after all.

The main thing I'm getting to regarding the caps is user tweaking. With a hard cap it's a bit harder to up the top speed of the tracks should someone so desire. With the soft cap, as released, top speed remains unchanged, but changing one variable in part.cfg would let someone adjust the speed to their preferences. The soft cap would shift upwards on its own, as a function of the new torque curve. I was always fairly happy with the long tracks, which I used most often, but the short ones with three road wheels and the skidsteer micro-rover bogies always felt waaaayyyyy too slow to me. I wanted them to have speed parity with the big ones, but never did get their speed upped accordingly. The hard cap also means using reverse to slow down is outright impossible when you crest the coded in top speed, a region where using Squad's brake button is an almost guaranteed frontflip. I quite like the idea of regenerative braking being used to give these things a bit more stopping power. Another point of using reverse as brakes is, for me and many others, analog inputs let us apply partial braking. MechJeb will do this as well if you're using its cruise control module. With regenerative braking there'd be enough force on hand at any speed to do this(IIRC this gets stronger the faster you're turning the drive motor) and you'd be able to recharge quite a bit if not all of your batteries cruising down slopes. I quite like the idea. You could go poke Sarbian regarding adding regen braking as a later tech tree add-on. MechJeb splits its modules across the entire tech tree without needing a million part.cfgs for each node. Honestly, though, with how late we get rover parts in general, I'm fine with it just being the default state. By the time we've got tracks, the ability to put them into space, the ability to feed their voracious appetite for EC, we're already technologically advanced enough that knowing the principle is a foregone conclusion. Even for Kerbals. Except Jeb, he doesn't know what brakes are.

I disagree about having a hard capped rev limit. A soft cap where the power peters off into near uselessness is better. Perhaps, would it be possible to code it such that applying torque in the opposite direction is artificially much stronger than in the forward one? I find hill descents with the tracks rather tricky over about 5-10m/s because the torque produced at that speed is so low that the vehicle often gains speed anyway. That makes me have to hit the actual brake button, which is effectively pulling the emergency brake, and can cause frontflips.

Woohoo! Those tracks were my favorite part of my mod, and indeed that module was the only part I used. Glad to hear they weren't too tricky to get going.

If I were a mod creator I would encourage it, hell, I may roll that patch into the official thing. Save me the trouble of porting it, stab your name in the credits, go from there. Welcome to the team, the coffee's cold the cheezits are stale but we have more mello yello than god!

No transport boat. The tank itself either swims there, or it just drives there on the sea bed. Depends on what sort of effort it takes to get a KV-2 turret to float.

My must-have mods are there because the wheel module is a butt. Hmm. I...don't know, actually, I won't be needing the SWheels anymore because the stock wheel module will actually work. The tracks if they're ever updated are a must have. BEyond that itt'l pretty much be as it is now with the 64bit hack, whatever catches my eye from the forums.

Ooooh. Would be an excuse for me to actually arm the Mach 3 fighter jet I've built! OR perhaps build an amphibious tank and just swim over there. Hmm. The possibilities...

Last mission I did was one to the Sarnussian moon Tekto. Built a small car, a lander, gave it 4km/s dV, and I was planning on using a Jump Drive to get it there. To do that, I first needed a cynosaural field in place...and to get that there, I needed. Something. I reached for an alcubierre drive. My FTL system uses both, the beacon will fly to the destination on an Alcubierre drive, then the actual science missions will just jump to the beacon and fly under normal pretenses. The return trip is another jump to a beacon I'll put in medium kerbin orbit here soon, then a normal landing. The jump drive itself is a seperate module with a 2.5m docking port on the business end, the Kerbin beacon won't be moved, and the other beacon will be free to travel to-and-fro depending on where I'm going. I got the beacon in place easily enough. Set up the lander, the docked-to jump drive, rolled that out on the runway and began what I thought was gonna be a dry test of the jump drive, making sure it had enough power. Nope, you're in Tektonian orbit now. Floored, and realizing I just brought launch clamps halfway across the Kerbol system, I reverted to SPH, finished the design, removed the clamps, and...well, sod the boosters, don't need 'em. I'll just jump straight from the runway to the target orbit! I still have to finish sciencing up the place, launch back into orbit, redock with the jump drive. Then I have to get the return beacon set up, jump the science mission back to Kerbin, land them. Fun fun.

Update since my last post: My final mission went well. Chose Vall as a target because the last time I landed there we were still using Tosh's Cart Plugin for rovers. The trip cost 3/4ths of a million funds to launch, returned 12,000 science(10,000 recovered, balance transmitted), then...well, stared at my space center. What now? Where to do? Effectively that save is sandbox. So I close the game, download Unity 4.6.4 x64, and do the hack. Yay. Works. Well, then what? I'm still pretty much sitting there staring at the VAB with no real goal in mind. I guess I'll throw flying wings at the stars until one stays up there or somethin' iono

I rarely kill kerbals(<3 'Revert to Launch and Revert to VAB), but I did lose jeb a few days ago. To an odd glitch. I was testing an aircraft out. Twin recips, two seat cockpit from a mod that's basically a twinned up EAS-1 with a windscreen. So he and Bill were 'docked' to this thing rather than properly in it. Jeb was, well, being Jeb, and trying to see how well a twin engine recon craft would work in a low altitude dogfight(Against what? He won't tell us). He clipped the right wingtip on the side of the runway and cartwheeled it into the ground. Both him and Bill were ejected from their seats and pinballing around in the cockpit until the remains...the cockpit, fuse back to the wing root, and left wing...came to rest in a twisted, crumpled heap in the grass to the south of the runway about a 100 yards or so(<3 Kerbal Krash System). Bill was fine. Upsidedown, but fine, and he was able to clamber out of the wreckage. Jeb was MIA. He isn't in my tracking station, he isn't visible at the crash site. but the crash log never mentioned him going poof! Wierder still, the hiring center does list him as KIA and he has yet to respawn over several Kerbin years(I have since launched an unmanned Eve rover) despite 'Killed crews respawn' being enabled. I have a feeling the only way I'm getting him back is with editing the persistence file. I also left the wreckage where it came to rest, as a memorial, for some time before recovering it.

I started out in 0.13 doing the usual 'slap SRBs under a capsule light fuse and laugh' thing. Got bored, stopped playing until roughly 0.17.1 launched. By the time 0.18 dropped I had: learned how to orbit Developed a standardized lifter(The Munar III) that I still use to this day* Learned how to do interplanetary flight Learned how to package rovers Learned how to mod the game Learned how to mod the mods Dabbled with modding the meshes of mods Developed a 1.25m variant of the Munar III to use when the payload is so light that the Munar III itself barely gets the boosters emptied before reaching space. My general technique hasn't changed much. I never asparagus'd. I always found it stupid, disliked the community's obsession with overly complex vehicles that violate several geneva conventions related to torture the moment the physics engine kicks in. I could put anything my processor could handle on any planet in the game with the Munar III, which is a simple three-stage rocket. It puzzled me that people would shy away from simple and reliable, still does. Even today I still rely on the same design. With the new aero it can put even more mass in LKO, or get the same mass even farther out into the stars. I've taken to removing about a fourth of the fuel carried by the lifter because it was sending transfer stages to planetary surfaces. * Basic design of the Munar III: Lift stage: 4x Rockomax Mainsails strapped radially to the main stage, fuelled by an orange tank and a X32 Rockomax tank. Originally it was just three of the X32 tanks, the orange tank just lets me drop part count. These light first, and when heavily laden, do the bulk of the lower atmosphere lifting. Main stage: Basically a carbon copy of one of the boosters stuck under the transfer stage. This lights when the boosters drop away and does most of the actual getting into LKO work when this thing is heavily loaded. While not intended, this stage can be lit at launch if the payload is particularly heavy. Doing so means an in-orbit refuel for interplanetary stuff, though. Engine can be a mainsail if needed, was in the original design, but these days it's usually a Skipper. It often also retains a few hundred m/s of dV so it will do a lot of, if not all of, the kicking when leaving Kerbin. Needless to say there's quite a few of these in solar and high eccentricity Kerbin orbits in my 0.17 save. Transfer stage: 1 X-32 fuel tank and a poodle strapped to the base of the payload. Pretty trustworthy setup, mostly used for either exiting, or if there's enough dV in the main stage(Often there is) the transfer stage is repurposed into a deceleration stage upon arrival at the destination body. This can be omitted if the destination is LKO, instead the payload itself will mount here. Odds 'n ends: It is equipped with RCS throughout. In the early days of my time playing KSP I needed this active from launch to keep it from flipping out, but refinements in the design, my piloting ability, and MechJeb have led to the RCS being mostly a vestigial organ. For the most part. Since the transfer stage is bulky it does get used for aligning to interplanetary ejection nodes. The tanks for this are kept in the transfer stage. Fins. I love the 50s retro-futuristic look that huge fins on a rocket give you. they also tend to help this thing avoid going out of control when it's either overloaded or too lightly loaded. Also, sometimes, the payload I've got equipped is too awkward to fit in an aeroshell. These payloads also tend to make the aerodynamics go haywire. the huge fins on the transfer stage tend to help the craft force the payload through the air rather than the air force the payload off course. Aero nosecones. Not necessary in the souposphere, but in new aero there's nosecones on the booster stages. Aeroshells go over some payloads but not all of them. Strap-on solid boosters also come into play once in a while, but generally they're not necessary. It's hard for me to get a payload heavy enough to need them yet light enough on part count for me to get enough of a framerate to actually send it up. I tend to not fly missions that give me less than 12-15FPS and that's in the 200 part area.