Gaalidas

Weird, I use it all the time without issue. Be sure your craft doesn't have an errant collider that's sitting at the same level or lower than the wheels. I attempted to put wheels on those new wider RetroFuture parts and discovered that the hull was colliding with the ground below the wheel colliders, despite the visual appearance showing that I had plenty of clearance. I won't be able to put up any screen caps of my misadventures. Trying to reproduce these things is rather difficult and time-consuming. besides, the craft that I messed up with no longer exists since I tend to not keep broken designs, I just fix them and re-save to the same file. Almost wish I had the processing power to run a vid-cap program in the background during every play-through so I could document my stupidity in designing rovers. EDIT: Probably a stupid question, but you are updating all of the files when lo-fi dumps his stuff (that sounds so wrong, sorry) right? Cause, if he updates the .mu and the .dll and only one gets updated on your machine, things will go funky sometimes.

Oh! I remembered the second thing! So, this is probably how it's supposed to function, but I discovered that a set of wheels with a group number 2 don't work too well with another set of wheels (even of the same type) with a group number 1. I had a rover with four wheels, but the front ones needed different torque settings than the back ones so it wouldn't do the monster truck flip on me when I accelerated. What happened was that the back wheels still reversed their steering like the stock wheels would do, taking into account their position on the craft, but they didn't necessarily work together, if you get my meaning. I reset the back wheels during the trip to group one again, and the steering started working the way it should from what I could tell. I took the test a bit further though, and put another set of wheels between the two sets and set the back four to group 2, Sure enough, the separate torque settings worked great but the middle two wheels were turning as if they were the front wheels. They didn't start acting like middle wheels until I set all the wheels to use group 1 again. So, I'm faced with a small problem of over-active wheel torque causing acceleration flips but turning amazingly well, or having less turning performance and being ably to manipulate things separately without hitting every single wheel settings sliders separately. Am I making sense?

Something in that last post reminded me of something I thought to mention. Actually, two things. First off, I did something really stupid (stupidly awesome, but still really stupid). I loaded up an ASET rover body (around 12 segments long) with four sets of four medium wheels each (y'know, the ones that look like repulsor wheels but don't transform, though I wish they could still transform and act like landing-legs). So that's four wheels, set in standard rover format around a central tube, then copied three more times and put into a square formation. I know, it's pretty nuts. I was trying to see if the module could make the necessary adjustments for wheels in this nutty arrangement, taking inspiration from that kethane mining rig shown early on in the mod's development, and taking it a little bit further. Performance from the start was pretty good, though I couldn't tell if the wheels on the inside track were reacting properly considering they were attached to a part facing the opposite direction than would be expected considering the side of the craft they were attached to. So, I begin rolling with this giant 16 wheeled monstrosity (abomination possibly?) and performance is great... until... one of the wheels from the four quads gets stuck in full suspension extension and refuses to turn. In fact, it causes so much friction that it is tearing the rest of the craft apart. On top of that, the rest of the wheels were spinning in place. Long story short, I pushed it to get it unstuck and ripped one of the quads off the thing. It still worked after that, just sagged a bit in the front. EDIT: I just realized that's only one thing! Now for Number 2! Okay... now, what was number 2 again? Think brain, THINK! Gah! I've got nothing. okay, just that one little weird thing then. I'll think of the other one later I'm sure.

I'm going into Application Development. It's a vague BA dealing with pretty much everything from HTML to mobile app dev. and everything in between. I found the culprit I think. I was the wheel-tweak mod ("Tweakable Wheels" I think?) adding its own module to the part before I could get your module swapped in there. I've changed ":FOR[KerbalFoundries]" to a ":First" which should do it. technically ":First" is not necessary, but I find it helps me clarify what is running at the beginning when debugging. It doesn't affect the functionality at all. The point is, it should now intercept the part before the other mod gets a hold of it and make it rather unappetizing to any other mods that want to edit it as well (at least when ModuleWheel is necessary).

initial tests were not so amazing unfortunately. Upon attempting to check my action groups with the modified wheels attached, I ended up with a complete GUI lockup with null exceptions being spammed to my log. I haven't checked the log quite yet to see what happened, but I suspect it has something to do with other MM patches making modifications to the same part which require a stock module to be present but aren't checking if that module is there still before applying. I'm going to test the duplication method later on as well. I would actually think that method would be preferable to most users, but I'd probably include optional patch replacements if the user wants to just override everything. Actually, if we go the duplication route we wouldn't even need MM patches, just need to reference the model using the "MODEL" node format and put your config in your own KF directory. I might be able to take over that area, but I'm unsure about the separate thread. My reasoning is, first off the list, that when someone downloads a new mod fully of goodies that can also be applied to the stock parts, they don't want to have to go somewhere else to find those configs. Second on the list is that if I were to release the MM configs as a separate addon, with a dependency of your mod, I would have to separately license my work as a subset of your work since in reality I'm just adding a few @ symbols and deleting some unnecessary lines. I lack the ability to do any of the real work behind the scenes, and I lack time to learn it because I'm still in college and not yet even beginning my BA. (I'm a late bloomer.) Third on the list (last one I promise) is that because I'm a student I may not always have time to update these configs (not to mention that I don't have the ability to update more than just the MM patch, and people would be asking me to fix things I have no ability to fix) I may have to suddenly disappear for a while to focus on some large project. If a major KSP update comes through during that time and a major rework of the MM patches is needed, I'll not only hate myself, but the rest of the MM users out there will hate me for not being around to help them. What I would do, in your shoes (so to speak), is keep everything together in one release thread. Post your new stock CFGs to the github and I'll do what I can to convert them into patches for a stock-overwrite option. I'll send you what I have when/if I get them where they need to be. If you want, offer them as a separate download or just wrap them into the complete package with an optional folder with an alternate method of install. i know it sounds complicated, but in the end it's usually better to offer as many options as possible. Who knows, maybe I'll get inspired to write a batch file to help customize the installation for whichever way they want to update the stock wheels. This all assumes I can get the other wheel-based mods to stop making game-breaking modifications to the configs before I can get to them. this also assumes that it isn't your modification of that stock wheel that screwed it all up. I better go see if the logs are helpful at all.

Sweet, configness! Yeah, that pod is pretty crazy with that monitor stuff. In fact, I'm unsure if they can even call it a monitor mod considering how they've branched out into transparent pods and such. I barely understand most of what i see on those things, and I'm unsure they're really that practical still. I'd like to see them create a stand-alone monitor you could pull up like you can with the scansat maps. It'd be a bit like the External MFD we had in Orbiter. UPDATE: Okay, so we have two options for the MM patches. We can either do a replacement of the stock configs or a duplication of the stock configs to allow the end user to choose to install them but still use the old ones on current craft. Here's what I turned your configuration into after assessing the differences between it and the stock config: //This will replace the current part configs with the new configurations. @PART[roverWheel1]:NEEDS[KerbalFoundries]:FOR[KerbalFoundries] { @title = KF RoveMax Model M1 @manufacturer = Kerbal Motion LLC & Kerbal Foundries @description = After years of outcry against the lack of proper powered wheels, a small startup company named Kerbal Motion was founded and delivered just what the public wanted - the RoveMax Model 1 powered rover wheel. Upgraded version with funky steering, wibbly suspension and tyres that taste like Jolly Ranchers. Do not feed to Bob after midnight. !MODULE[ModuleWheel] {} !MODULE[FXModuleLookAtConstraint],* {} MODULE { name = ObjectDestroy objectName = bustedwheel } MODULE { name = OverrideWheelCollider moveCollider = true moveColliderBy = 0.25 suspensionDistance = 0.3 spring = 1 damper = 0.05 mass = 0.5 targetPosition = 0 } MODULE { name = ModuleTrack raycastError = 0.035 springRate = 1.4 damperRate = 0.1 smoothSpeed = 8 chargeConsumptionRate = 0.2 hasSteering = true torqueCurve { key = 0 40 0 0 key = 5 30 0 0 key = 10 15 0 0 key = 20 0 0 0 } steeringCurve { key = 0 20 0 0 key = 10 10 0 0 key = 20 5 0 0 } torqueSteeringCurve { key = 0 0 0 0 } brakeSteeringCurve { key = 0 0 0 0 } brakingTorque = 50 rollingResistance = 0 maxRPM = 600 } MODULE { name = TrackWheel wheelName = wheel colliderName = wheelCollider sustravName = suspensionTraverse steeringName = trackSteering isIdler = false isSprocket = false smoothSpeed = 40 wheelRotationX = 0 wheelRotationY = 1 wheelRotationZ = 0 susTravAxis = Y steeringAxis = Y } MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX { targetName = susp2-1 rotatorsName = susp2-2 } CONSTRAINLOOKFX { targetName = susp2-2 rotatorsName = susp2-1 } CONSTRAINLOOKFX { targetName = susp1-2 rotatorsName = susp1-1 } CONSTRAINLOOKFX { targetName = susp1-1 rotatorsName = susp1-2 } CONSTRAINLOOKFX { targetName = susp3-1 rotatorsName = susp3-2 } CONSTRAINLOOKFX { targetName = susp3-2 rotatorsName = susp3-1 } } } That will overwrite the squad config with your modified configuration. If, however, we want to duplicate the original part and end that duplicate then we actually have two options on that front. You can either give up the MM patch and simply use a MODEL node to reference the model path while placing this config in your own mod's folder, or we can simply replace the "@" character in the MM config with a "+" character. Combine that character change with a few additional edits at the top of the file and it will spawn a brand new part based on the stock configs. Otherwise, the patch I posted above should work. I have yet to test it however. It's getting late and KSP takes quite some time to boot up. I don't see any reason why it wouldn't work as it is though. Here's the config option if you want to duplicate the original part: //This will duplicate and modify the new part to not conflict with the original. +PART[roverWheel1]:NEEDS[KerbalFoundries]:FOR[KerbalFoundries] { @name = KFroverWheel1 !mesh = DELETE MODEL { model = Squad/Parts/Wheel/roverWheelM1/model } @title = KF RoveMax Model M1 @manufacturer = Kerbal Motion LLC & Kerbal Foundries @description = After years of outcry against the lack of proper powered wheels, a small startup company named Kerbal Motion was founded and delivered just what the public wanted - the RoveMax Model 1 powered rover wheel. Upgraded version with funky steering, wibbly suspension and tyres that taste like Jolly Ranchers. Do not feed to Bob after midnight. !MODULE[ModuleWheel] {} !MODULE[FXModuleLookAtConstraint],* {} MODULE { name = ObjectDestroy objectName = bustedwheel } MODULE { name = OverrideWheelCollider moveCollider = true moveColliderBy = 0.25 suspensionDistance = 0.3 spring = 1 damper = 0.05 mass = 0.5 targetPosition = 0 } MODULE { name = ModuleTrack raycastError = 0.035 springRate = 1.4 damperRate = 0.1 smoothSpeed = 8 chargeConsumptionRate = 0.2 hasSteering = true torqueCurve { key = 0 40 0 0 key = 5 30 0 0 key = 10 15 0 0 key = 20 0 0 0 } steeringCurve { key = 0 20 0 0 key = 10 10 0 0 key = 20 5 0 0 } torqueSteeringCurve { key = 0 0 0 0 } brakeSteeringCurve { key = 0 0 0 0 } brakingTorque = 50 rollingResistance = 0 maxRPM = 600 } MODULE { name = TrackWheel wheelName = wheel colliderName = wheelCollider sustravName = suspensionTraverse steeringName = trackSteering isIdler = false isSprocket = false smoothSpeed = 40 wheelRotationX = 0 wheelRotationY = 1 wheelRotationZ = 0 susTravAxis = Y steeringAxis = Y } MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX { targetName = susp2-1 rotatorsName = susp2-2 } CONSTRAINLOOKFX { targetName = susp2-2 rotatorsName = susp2-1 } CONSTRAINLOOKFX { targetName = susp1-2 rotatorsName = susp1-1 } CONSTRAINLOOKFX { targetName = susp1-1 rotatorsName = susp1-2 } CONSTRAINLOOKFX { targetName = susp3-1 rotatorsName = susp3-2 } CONSTRAINLOOKFX { targetName = susp3-2 rotatorsName = susp3-1 } } } Note: file name is irrelevant. In fact, in the end we could place patches for all the wheels you modify in a single file that you can distribute with your mod within the KF mod directory.

It's only affected me when using the ASET pod. That nutty guy has not only two different sizes of Raster Prop being used, but several of them for the primary seat. Add to that the holographic HUD projected on the glass that displays real-time data about your current orientation and drive power status, and the fact that with all those different window panes and their corresponding JSI transparent transforms... well, it's a wonder it runs at all on my low-powered laptop. I turned off the transparent pod part of the part config, leaving the internal config alone completely, and just that improved things a ton. The windows and opaque from the outside, but otherwise everything works as intended. I think part of it is the extra load of polygonal faces being rendered and the real-time data that's being processed and displayed even when you're viewing those monitors from outside the pod. if those JSI panels could display a generic image instead of all that data when viewed from the outside, it would perform better (but look a lot less cool). If those little buttons all over those consoles were turned into a lower-quality mesh or even hidden completely when outside the pod as well, that would likely fix the problem completely. I'm also a little skeptical as to the need for all those separate transforms for each pane of the front windows. For example, I believe the Pano-pod developed a while back manages the create an entire 360 degree view of the interior on the pod, with at least as many consoles and a lot more polygons than the ASET pod and nearly 3 times the individual glass panes ALL while using a lot less transforms and at least a third of the performance hit. it's actually quite a mystery why the ASET pod is so hard on the system really. I tried the new rover body you put up and its initial performance hit in the SPH is at least 10 times less than the ASET pod. Of course it's using about 30 times less props than the ASET pod too. EDIT: I just took a look at the configs and it's insane. The Pano-pod has a single window transform for the entire 360 degree window setup. The ASET pod has only a few front windows, a lot less polygon face detail in the model, but uses a whopping nine freakin' transforms. That's a lot of rendering activity going on there. Optimization went way out the window.

Excuses excuses. "I forgot..." pfft! Couldn't help myself. Anyway, fortunately you can rip and re-paste as much as you want and I'll be able to swap that stuff in with the patch. in theory of course, I won't really know until I can run a difference checker between a stock config and a modified config for the same part. That's what I like about the ASET rover pod. Unfortunately I'm going to have to either drop that part or disable the JSI transparent pod functionality. That thing eats up over 60% of my pitiful frame-rate even after I cut out a bunch of the pointless props in the config.

Modularity or not.. I want to mess with that baby asap. I also really want to mess with some of the configs for the stock wheels and those aset wheels. Once I can see the configs, I can begin converting them into MM patches.

Sounds awesome. As for that rover body, Holy Jebediah's Ghost! (and he ain't even dead yet!) That thing looks awesome, kerbal passenger placement and other bugs aside. That's the first time I've seen JSI transparent pod technology put to use for so many windows, or such a large space before. It reminds me of the virtual cockpits we had in Orbiter several years back, but without the advanced interaction we get with KSP.

Those are what we call Kerb Troopers. They're quite expendable and hit trees on a regular basis. those bikes are rigged to explode in a spectacular fashion when hitting anything made of wood or stone. Oddly enough, they just bounce when hitting anything organic. We hope to have that bug ironed out in the future and the Jebi Knights are currently conducting testing to make sure that expendable Kerb Troopers are killed in a spectacular fashion and on a consistent basis. We appreciate your understanding during these trying times of survivable crashes and less-than-amazing explosions.

Alright, I'll weigh in. So, the tracks I have not tried to tweak the scale of because they're obviously a bit more complicated than the wheels. The wheels however, using the last known release of TweakScale, are working perfect with the steering even being maintained extremely well. Heck, even the repulsors work really well with scaling. And that's without any updated configurations for the scaling of operation values, just the basic size change. So, I really have no idea why that would change the steering. However, if somehow the wheels are getting attached in the wrong orientation after being scaled, that would be the issue to consider. A few minutes ago I answered a post about the ERS wheels not launching from the SPH to the runway correctly, clipping with the runway and not turning correctly. It's been an ongoing discussion and the last complaint on that issue was that they weren't steering right. He was turning the wheels and instead they were tilting sideways. Well, what happens when you take a horizontal steering mechanism and put it on its side? It tilts. Not saying this is the problem here as I'm sure you're careful to orient things right, but it's something I struggle with every time I use a wheel especially from the SPH where almost everything comes out at the wrong angle from the get-go. I'm curious lo-fi, do the stock wheels, when hooked to the KF plugin, function like stock wheels? Or do they exhibit the steering and suspension effects (within their own extreme limits) like your specialized wheels do? Either way, an optional MM config would be the best option I would say. If you need a hand at that, I can take a hand at writing some if you can make a template of what needs to change. Might even be able to re-use some of the data in the configs and make your MM patch be more universal instead of customized for each wheel. I've already got the KF wheels undergoing a few personal MM customizations (makes updating your latest changes a lot easier if I don't edit the cfgs directly) and have become rather proficient at making MM configs as long as no advanced (aka. Regex) commands are required. Now, I must weigh in on the speed thing. I discovered the max rpm thing myself and what I've done is just use an MM config to multiply the current "maxRPM" by a small value to give the wheels some more breathing room. Yes, that produces some of the run-away wheels when not attached to the ground, but otherwise you loose out on being able to make a small rover with a super-powered engine that can make it catch air when going over the runway sideways... without using boosters that is. They still tend to limit me from getting too fast (unlike when I made a HUGE LLL-hulled rover using those giant stock wheels and found that if I held the key down it would continue to accelerate ever so slowly) but I don't run into the maximum rpm thing limiting me from going any faster and hyper-switching status in the right-click menu. They still have their curves untouched, which preserves how they accelerate, but they have the chance of flexing that to the limits without being held back as much. It works pretty well for me. Okay, now the crawler stuff. Yeah, I like that idea better than my old idea of just having a "recenter" command in the action group settings. If they could just orient to the direction defined by those keys, like you were doing linear translation in space (except without the third dimension of movement) then it would become extremely intuitive. However, to gain fine control over that, the speed at which it aligns with the new heading should be slow enough that you can stop pressing that button and continue moving at whatever orientation they currently sit at, waiting to be re-oriented properly when the correct button is pushed. Personally, I'd rather have the standard rover controls as they are and put the other movement functions either in the numpad or require the alt key to be used to alter the functionality of the directional keys. Either way, I say we save this for another day and work on getting what we have at a release quality. Crawler steering could open up all sorts of new bugs that could drive us nuts, and lo-fi even nuttier considering he's doing all the real work here.

Sounds like they've been attached in the wrong orientation. Most parts brought into the SPH from the part-list come into being at the wrong angle and need to be adjusted to work right. These wheels especially confuse because they can change how they attach. There really needs to be some sort of alignment-to-ground indicator or something. It'd sure help out the less intuitive builders.

Uh oh, ready the fire extinguishers... the servers are gonna get HOT tonight!

Hah, I always wondered if a static air-born object could be constructed. I wonder how far one could go? Floating launchpads at the atmospheric edge?

Sounds like a plan. Considering how fast you've managed to make working wheels/tracks from nothing in record time already, I can't even imagine what you'll pump out without the need to recode everything every other day.

I'm not sure what you mean by that. You don't need a tool to assign different textures, you just need a tool to change the texture format. Internally, the texture extension doesn't matter when the model is loaded, assuming the extension matches the file format.

I take a day off and two more pages spring up on me. Loved that video... err.. both of them. Those little repulsor-bikes or whatever are awesome. I had a shiver go up my back when the air brakes opened up. I did not see that coming. That's a level of craft design that I am simply not capable of. I'm too attached to my nodes, so to speak.

ah, gotcha. Guess it's time to do some module mashing.

And to think it was working just fine before you started reinventing the wheel... literally. Typical programming nerd. If it's not broken, you're not trying hard enough. I should know, I'm one of them. EDIT: Hah! Jebediah would try to one-up Jesus wouldn't he? Isn't adding the floatation module and the propeller module a bit redundant? I thought the propeller module was supposed to have a floatation function integrated so that it could be used to make the hypnodrive floatable.

You just have to hope that people are smart enough to disable this when a major game update comes about to see what needs updating.

those pipes are downright wrong on so many levels. I went over them with the largest tracks available and it landed me high-centered on my rover's roof. Those things should be banned from existence.

Yeah, just tried it and everything is good to go. Can't explain it. Hey, there might not be any active anti-roll but just the awesome suspension of the wheels makes all the difference. Where stock would send you flipping, with yours we just get a smooth leaning of the craft while all the wheels maintain contact with the ground. EDIT: Just remember, if you're going to do texture aliases you'll need to eliminate those spaces in the texture names, and update the models to match.

wait, 0.90? It took long enough to get from .24.2 to .25. .90 will be a long way down the line. Half of us will die from old age before then.

I'll let you know later when I get done trolling for new mod updates and funky craft designs to torture my machine with. "Picky" MODEL nodes? at least they let you control exactly what you're getting. just defining a mesh and hoping for the best is a recipe for disaster. I had to convert some of the stock parts in the .25 update to use MODEL because I was getting errors that the model, located in a folder that doesn't exist (I checked) could not be located even though you've specified that the mesh is in the same folder as the config by using a "mesh" parameter. Okay, so I added a bit to that error, but it really is nuts that it would look for a model from the "mesh" parameter in a config located in, say, "squad/parts/engine/engine1/" and error out by saying the model could not be located in "squad/parts/engine/engine1/engine/engine1/bigfreakinengine/" when that folder, even when you factor in the internal referencing process which does include the config file name and the part-name in the path, never existed in the first place and was not even defined. I'm not bitter, honest! I was showing off the wheels and the anti-roll system to a friend the other day during a break in my SQL class. It's pretty bleepin' hard to even get one side of the wheels off the ground. It's beautiful, really. I cant wait to see how they respond to slightly less gravity though. I have no illusions that it'll be smooth on the Mun, but Duna shouldn't pose too much trouble.