allmhuran

It will be in here: Kerbal Mechwarrior Program on Google Drive , but there's basically no chance anything works anymore. I stopped working on it as of about KSP 1.06 when wheel auto-struts prevented them from being able to walk.

Something like this, perhaps? https://gfycat.com/thatabsolutefritillarybutterfly

Take two did what amounts to an attempt at an ethics panel, while they fill their games with microtransactions and think loot boxes aren't a form of gambling for kids, on the contrary, their CEO actually said loot boxes are protected by freedom of speech and could not be legislated against. The overwhelming response to said panel seems to indicate that they don't have the moral credibility to pull that off.

I'm not able to use discrete throttle control in afbw 1.8.3.3, ksp 1.12 win 64. The four non function are throttle+, throttle-, cut throttle, and full throttle. All other bindings seem to work. Issue created here https://github.com/linuxgurugamer/ksp-advanced-flybywire/issues/34

Well, I have not been here for a while. I have so many hopes and questions, but I will limit myself to two. Q: Does KSP2 use the core KSP1 code in any way, or is it a rewrite from scratch? More specifically, is it coded using Unity's new Entity Component System and Job System? I realise that this is not something which comes naturally to physics simulation due to the physics-interdependent nature of the parts on a craft. Do colonies "do stuff when you're not there"? For example, does a colony produce and / or consume resources over time? Can I, for example, set up a mining colony on the Mun gathering Helium-3, which keeps producing as long as the snack supply is maintained with regular missions from Kerbin? And could I eventually set up snack farming at that colony in order to make it a self-sufficient producer? And if so, is there any kind of balancing mechanic which would prevent me from creating a self-sufficient-resource-production colony, turning on max time warp for a few seconds, and having effectively infinite Helium-3 as a result?

The trick, as I recall, was to alpha as many mechas as possible with 4 simultaneous PPCs before they had a chance to start up.

That last bloody GBL mission where you have to jumpjet up through the hole in the ship was so frustrating. Actually, GBL is the one I remember the least, except for that mission and the one prior (in which activitision valiantly attempted to to make a river and waterfall using their engine which had absolutely no ability to do rivers or waterfalls) Edit: Oh yeah, and the underwater mission, I think that was also GBL

LOL! They are battletech mechs, they must use battletech loadouts

Gfycat extract for those at work/on teeny devices/etc. Note: The embedded version of the gfy is of much lower quality here than directly on gfycat, not sure if this is always the case with gfys.

I just tried the new release of this, thanks for keeping it going. Path mode seems to have an issue if you save a path and then want to use it again when reloading the kerbal save file. I had a path going around the KSC, but when I reloaded the game the first point of the path was in a different position and pointing up at the sky. Might be to do with the rotation of kerbin or its orbit around the sun? It seems like the path tool needs to store its reference frame.

Unless @Grease1991 just means making sure the wheel is straight and level in the hangar? I never actually used adjustable landing gear, but I can see how that might be useful. Attach the part with the wheel strut at whatever angle you like, and have the actual wheel bit then align itself with the cardinal axes in model space. I don't know how important that would be anymore, since you can switch the rotation gizmo to absolute coordinates and turn on angle snap, although this will align the part as a whole, not just the wheel.

For sure, it would be silly to remove the feature entirely unless a better solution for common use cases is developed. Forcing it to be on (even for some subset of parts) is the issue.

Interesting. I recall you also mentioned that the grass around the runway seemed to be continuously calling collide events. Is that a direct result of having a physic material assigned?

I doubt that the current implementation of autostruts is the only possible solution to that problem.

After 12 months hiatus I finally decided to check whether various things in KSP had been fixed to the point where I could get my mech project restarted. So far things are looking promising!

Solved with lots more investigation: Using rigidBody.gameObject forces a walk up the tree, since the physicsless part has no rigidBody (or rather, setting this flag causes the rigidBody to be ignored or removed at runtime). To return the actual physicless part, use the collider instead.

I'm actually playing around with the code myself locally. The current version has a few issues with hit normals and penetration, I look forward to seeing what you've chanaged. For now I've commented out everything regarding "fulllyPenetrated" (sic) in the code

Nah, they're used in different spots. For example, GetComponentInParent is used for the lasers, FromGO is used for bullet hits. But the difference is that when making the FromGO call it uses hit.rigidbody.gameobject, vs hit.collider.gameobject for the other call. So the two lines of code operate differently. Switching everything to the hit.collider.gameobject.getcomponent version makes it all work as expected, I've recompiled it myself and everything is fixed. I have an issue open on the BDA git site showing where to make the changes.

Genius! Love your work Shadowmage, you get things done.

All this great information that I've never seen anyone mention in ~4 years of mucking around in KSP. You're a freaking goldmine. I first really explored the heavy/light mass joint problem about 18 months ago based on some discussion over in the infernal robotics threads, but nobody has ever mentioned anything as specific as what you've said here. Really interesting stuff. In any case, this is why most of the parts on the mechs are physicsless - to prevent IR joints from being wobbly - so it solves the problem everywhere except for the contact patch with the ground. Anyway, maybe the "ice skate" style ground physics will help with your skids, but it sure seems like you probably already know a lot more directly from unity than what I can find out by experimenting in KSP, even if the unity stuff is sometimes overridden by KSP behaviour.

That's all extremely helpful information, thanks very much! So my hypothesis about acceleration ins't correct, it's probably the step from half to full spring response you've just described that was causing the flipping. Interesting that it happens only when the feet have very low mass, though. Changing foot mass from 0.001 to 0.1 prevents it... even though the change to the mass of the craft as a whole, at ~15 tons, is totally negligible. Yes, terrain other than the runway and other paved areas is super, super weird. This seems to be a recent thing. I don't know if my own experiments will help you with your development at all, but it might. Let me describe exactly the problem I want to solve, and what I have found to work. My mechs cannot "steer", since they can only walk straight ahead or straight back. Steering comes only from SAS yaw forces in the hips. I therefore give the hips a very large SAS yaw torque of 150ish (total craft mass, again, is only ~15) With any configuration of physicsless contact patches: No steeering at all, the mech will only walk straight. With flat bottomed, physics-enabled feet: On the runway, the provided yaw is enough such that if I put in full yaw, the mech will rotate around a vertical axis, both when stationary and when walking. But as soon as the mech walks onto the flat ground around the runway the mech cannot yaw at all, even with yaw force ramped up much higher. With 4 small physics parts (structural girders) on the bottoms of each foot and high yaw torque: The mech can yaw very easily on the runway (too easily). It can just barely yaw while on the surrounding grass. The solution I have found: I have made a custom part using the structural panel 1x1 and scaling it so that it is even thinner. I then put 4 of these parts onto each foot, on the front and rear toes so that the "edge" of the part runs from right to left across the toe. The obvious hope being that this would work kinda like an ice skate, with the sharp egde providing minimal resistance to movement in the direction of the long edge, but the wide, flat face providing high resistance to the orthogonal (mech forward/mech back) direcition. Amazingly, this actually works... even on the grass around the KSC, and even with yaw torque reduced And note: This is just a 1x1 structural panel that I have rescaled using a model{} block. It has no special modules or anything, and it has normal physics significance. If physics significance is set to 1, it no longer works. So the friction value really does seem to depend upon the "contact patch" size and particularly the orientation relative to the direction of movement. Of course, the downside of this solution is that I can't "turn off the brakes to skate". The mech is limited to walking speed.

Learned some interesting things playing around some more. Those wide footpads on my mech? They're physicsless. Physicsless parts have perfectly rigid joints and don't flop around on IR servos, so they have to be that way. Their mass is also really, really tiny at 0.001 in order to prevent the "swaying" of the leg mass from rocking the mech as it walks. But the mech as a whole weighs ~15 tons, due to a dense resource I transfer between the feet as it walks, acting as a counterweight. So, I have been putting a normal-physics part between the wheels and the feet. Just a small one, like a small girder. This is how I've been doing my experiments thus far, but I wondered what would happen if I simply gave the footpad its physics back. The result: The mech is flipped up into the air after it spawns in. This was with suspension 0, spring 0.05, and damping at any value. It *looks* like the acceleration applied upwards by the wheels to the thing the wheels are supporting does not depend on the mass of the object as a whole, but only the mass of the immediate parent, which is interesting. I expect this is a KSP or unity thing, not a mod thing. But if this hypothesis is correct, it explains why wheels (and potentially a whole lot of other things) are so hard to get right.

First of all and most importantly, thank you for providing wheels that don't rely on forced autostruts! I've been away for a while and came back hoping updates to KSP would have made my mechs viable again, but wheelstruts were killing me. And if I don't have wheels on the feet, then the mechs can't turn off the brakes and "skate" to higher speeds, nor can they turn on anything but "concrete". That's a new thing as far as I know, but the grass around the runway (and, I assume by extension, anything not "paved") now seems to have enormous anti-skid, which meant my SAS-powered-yaw form of steering no longer worked. Having something steerable on the toes allows SAS to "skid-yaw" the craft again. For reference, this is what autostruts did to me:https://gfycat.com/CarelessColorlessBeardeddragon From my experimentation (and a hint from your documentation) it appears to me that these new modules will only work if their parent part is not physicsless, is that right? What I really want to do is create something like a castor... The wheels aren't there to really be wheels and I don't need motors, I just need a way to turn on grass and (preferably) be able to "skate" with brakes off. Still playing around with the various settings, I've been at it for a couple of hours and am making progress, albeit slow. My best efforts so far have suspension at zero, and alternating between full damping/no springs and no damping/no springs. Unfortunately both of those setups seem to create a constant "collision" noise coming from the wheel.

I'm sure I'm not the only player who uses parts in "creative" ways. That's one of the main things that gives KSP such depth and lifespan... once you're done doing all the stuff you're expected to do, you can spend far longer doing really crazy stuff. But forced wheel autostruts are really blockading that creativity for me right now. So I'm curious... is there a better solution planned? Are forced wheel struts a temporary fix? Is there any chance we could disable them *even before* that fix comes about? I found a reference to a modulemanager patch that put the line "autoStrut = false" into the wheel base module, but this no longer seems to work. Tangentially, has it always been the case that the runway and runway edges (the steep slopes on each side) are much more "slippery" than the surrounding terrain? I'm finding that craft with the SAS power to rotate by sliding on the runway simply get "bogged down" and are unable to rotate under their own SAS power on the grass (even with massively overpowered edited SAS... like yawTorque = 180). Of course, wheels would probably allow rotation under SAS power even on grass, but... see above