[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[sirkut]

Yup, and you can also use the tweakable slider in flight, though that only modifies individual repulsors. Thanks

I wonder if you could create a kspfield variable called linkID where you could link up any number of repulsors to an ID number that way when you adjust the tweak slider it would adjust them for all repulsora linked to that linkID. Just a thought.

[lo-fi]

Any ETA on when 1.7 will be out again? I'm anxious to get my hands on the new bits.

Soon^TM seriously, though, as soon as is humanly possible and I'm happy it works at least well enough to be largely usable. Big, big changes and not so easy to swap between 1.6 and 1.7.

I wonder if you could create a kspfield variable called linkID where you could link up any number of repulsors to an ID number that way when you adjust the tweak slider it would adjust them for all repulsora linked to that linkID. Just a thought.

Thanks, I think I can see how I can make that work. I'll have a play

[Gaalidas]

I've found from the numerous reports around the forums that x64 becomes unstable at random for a random number of people in random situations with completely random results. It's a bit of a random situation we have here.

So, that train is crazy. I love the fact that it left very little debris behind when it obliterated itself. I was thinking, you might be able to produce some drag so that the train cars would follow the leader more like a wheeled setup if you had some air-brakes permanently turned on at various positions along the craft, better yet if you could get ones on a certain side of the craft to turn off when turning to better facilitate that action. Just a thought.

I wonder if you could create a kspfield variable called linkID where you could link up any number of repulsors to an ID number that way when you adjust the tweak slider it would adjust them for all repulsora linked to that linkID. Just a thought.

Now that would be useful when trying to set up action groups for crafts with greater than four repulsors, or when dealing with very large vehicles.

[lo-fi]

Ok, the group number idea is well worth pursuing. For repulsors it will affect which get set the same as the one you're twiddling with. For wheels, tracks etc. it will govern how they are organised for calculating the steering ratios on craft with multiple rovers attached to one vehicle. Thanks for the idea, Sirkut, that neatly solves a potential problem. I wont get around to coding it until I get back from holiday (away until the start of next month), but this is definitely getting implemented.

[lo-fi]

Actually, it seemed so absurdly simple I got it working in half an hour after the Sunday pub trip. Latest build in dev has group ID slider in Tweakables, along with an Apply Settings button that will send the settings to all parts with the same ID. For repulsors it sends the ride height, for tracks, wheels etc, it sends steering inversion and torque, as well as governing which wheels to calculate the steering angle ratio against. Groups are 0 - 10, group 0 being special in that it blocks sending the settings to other parts entirely and only affects the selected part.

I'm happy with this being simple enough for release without needing extensive instruction, and defaults to group 1 in any case.

Edited September 14, 2014 by lo-fi

[sirkut]

awesome. I love what you have done with it and the first thing I did was attach four repulsors and tried to adjust the height while running around and realized I had to set an action group. I've played enough with the tweakmenu that I knew you could do it! I hope you didn't mind the suggestion since it frees up some action group keys for other functions. If I think of anything else I'll let you know but please keep up the good work, this is one of the things I really enjoy using and have a great idea for those repulsors that I need to test out when my busy schedule slows down a bit.

[Camacha]

I've found from the numerous reports around the forums that x64 becomes unstable at random for a random number of people in random situations with completely random results. It's a bit of a random situation we have here.

This mod seemed to make the difference in two installs, so that suggests it is more than random. Whether it is this mod or the combination with another I need to investigate.

[mike9606]

I notice that the 1st post says 1.7 for the link to the download, but Kerbal Stuff still has 1.6e. I know that 1.7 was pulled due to some issue, but can lo-fi at least change the first post so it is less confusing?

[Gaalidas]

Hey, quick question lo-fi...

So, I've been fiddling about with the crawler wheels and I've come to the conclusion that you have yet to provide a way to switch from standard (as if... these things are anything but standard) steering to true crawler steering. Is this feature not implemented, or am I missing something obvious? It surely wouldn't be the first time...

EDIT: Never mind... I did some code diving and discovered the keys you'd assigned to them.

Edited September 15, 2014 by Gaalidas

[mjy]

oh, so I can ajust my height of the tracks?? would be nice to get to have Abraham style tracks, just not as high and stretch out a bit, as u see here. ty for these nice tracks but these are some very good working tracks, very nice , hope u don`t mind the big pics

[lo-fi]

awesome. I love what you have done with it and the first thing I did was attach four repulsors and tried to adjust the height while running around and realized I had to set an action group. I've played enough with the tweakmenu that I knew you could do it! I hope you didn't mind the suggestion since it frees up some action group keys for other functions. If I think of anything else I'll let you know but please keep up the good work, this is one of the things I really enjoy using and have a great idea for those repulsors that I need to test out when my busy schedule slows down a bit.

Thanks, glad you like it Keep the suggestions flying, they're more than welcome! Look forward to seeing what you come up with.

This mod seemed to make the difference in two installs, so that suggests it is more than random. Whether it is this mod or the combination with another I need to investigate.

Interesting. Anything you can figure out would be helpful, along with some logs.

I notice that the 1st post says 1.7 for the link to the download, but Kerbal Stuff still has 1.6e. I know that 1.7 was pulled due to some issue, but can lo-fi at least change the first post so it is less confusing?

Of course. I've been so busy fixing stuff I forgot all about it!

Hey, quick question lo-fi...

So, I've been fiddling about with the crawler wheels and I've come to the conclusion that you have yet to provide a way to switch from standard (as if... these things are anything but standard) steering to true crawler steering. Is this feature not implemented, or am I missing something obvious? It surely wouldn't be the first time...

EDIT: Never mind... I did some code diving and discovered the keys you'd assigned to them.

I'd forgotten about them being in there (just like the skids). They're a development really, I'm using them to get the mechanic right before I add that toggleable mode into the medium wheels proper. It's not quite right yet, but I know how to fit it now.

oh, so I can ajust my height of the tracks?? would be nice to get to have Abraham style tracks, just not as high and stretch out a bit, as u see here. ty for these nice tracks but these are some very good working tracks, very nice , hope u don`t mind the big pics

http://cloud-4.steampowered.com/ugc/30719887739259360/D1C33C8F1DF8B00EB08FFB13A9B8A6D13037A09E/

They look absolutely brilliant Your own models? I'll get around to making a longer set at some point, probably with five road wheels rather than three. Too long and they get a bit unwieldy.

[Gaalidas]

I'd forgotten about them being in there (just like the skids). They're a development really, I'm using them to get the mechanic right before I add that toggleable mode into the medium wheels proper. It's not quite right yet, but I know how to fit it now.

Yeah, so about those... one thing I'd really like to see when you get around to it would be a way to re-center everything with the push of a button. in my own experiments I have had a number of issues. First, after finding out how to use crawler steering, I discovered that it was really difficult to get everything back the normal after using both steering modes in conjunction. I will say that having my rover steering extremely well while traveling backwards and to the left with a slight right-hand turn all with individual wheel suspension and all that... well, it was amazing to say the least. Second, I discovered that it was impossible to re-center the wheels so I could drive straight. I was always either turning left slightly, or right slightly.

A few other observations lately that are not fully related to my previous issues: I have been having performance issues with KSP for a while now. This is not due to your modification exclusively, but rather a memory problem of KSP 32-bit overall, which we are all well aware. I use a number of memory optimizations, and I also resize all my textures (some with a really amazing batch file I wrote, others by hand due to odd size ratios or a personal preference for brightness/contrast of the textures in question) so I don't necessarily need advice on memory optimization. What I've started doing most recently is diving into the .mu files to see if all the textures being included with the model are really being referenced in the model or the config. In your mod specifically I have identified some extra textures that we can safely prune. Next on my list is to try and set up MODEL nodes for these things so that we can have a common texture folder and not have to have so many duplicates of the same textures.

For now, I've discovered the following textures which can be safely removed due to them not being used in the models or configurations:

(Note: my observations are based on the Github package, not the released alpha tests.)

In "AlphaRBIInvertingTrack" you can safely remove "model003_NRM"

In "AlphaRepulsor" you can safely remove "accordion-tex" unless you want to sue it to replace the used texture called "accordion-tex 2"

In "RepulsorWheel" you can safely remove the following: "CF+A" , "RepWheel-diffuse" , "RubberLoGrav"

In "RoverBody" you can safely remove "CF+A"

So, if you're an optimization freak like I am, go ahead and trim the usage a bit.

[lo-fi]

Yeah, so about those... one thing I'd really like to see when you get around to it would be a way to re-center everything with the push of a button. in my own experiments I have had a number of issues. First, after finding out how to use crawler steering, I discovered that it was really difficult to get everything back the normal after using both steering modes in conjunction. I will say that having my rover steering extremely well while traveling backwards and to the left with a slight right-hand turn all with individual wheel suspension and all that... well, it was amazing to say the least. Second, I discovered that it was impossible to re-center the wheels so I could drive straight. I was always either turning left slightly, or right slightly.

A few other observations lately that are not fully related to my previous issues: I have been having performance issues with KSP for a while now. This is not due to your modification exclusively, but rather a memory problem of KSP 32-bit overall, which we are all well aware. I use a number of memory optimizations, and I also resize all my textures (some with a really amazing batch file I wrote, others by hand due to odd size ratios or a personal preference for brightness/contrast of the textures in question) so I don't necessarily need advice on memory optimization. What I've started doing most recently is diving into the .mu files to see if all the textures being included with the model are really being referenced in the model or the config. In your mod specifically I have identified some extra textures that we can safely prune. Next on my list is to try and set up MODEL nodes for these things so that we can have a common texture folder and not have to have so many duplicates of the same textures.

For now, I've discovered the following textures which can be safely removed due to them not being used in the models or configurations:

(Note: my observations are based on the Github package, not the released alpha tests.)

In "AlphaRBIInvertingTrack" you can safely remove "model003_NRM"

In "AlphaRepulsor" you can safely remove "accordion-tex" unless you want to sue it to replace the used texture called "accordion-tex 2"

In "RepulsorWheel" you can safely remove the following: "CF+A" , "RepWheel-diffuse" , "RubberLoGrav"

In "RoverBody" you can safely remove "CF+A"

So, if you're an optimization freak like I am, go ahead and trim the usage a bit.

The thinking is to have the normal steering return to centre and the lateral mode as-is, probably with an action group/gui menu thing to return to centre. What you see is mathematics straight from excel, syntax converted. I didn't get it quite right, though I know what I need to do now and the rest is detail. They're currently still using the stock modules, as are the repulsor wheels, which I have yet to do configs for with the custom plugin.

If you can give me some config pointers for texture sharing, I'd be much obliged. Like many things, it's something I've not even had time to look at! Regarding the performance issues, I've been doing my best to keep the update loops as free and simple as possible. There is some complicated stuff going on, though, so there's a limit to what I can optimise. Getting some texture sharing going on would be really good, though. Make you realise how much work there needs to be done to put out a fully fledged mod!

Off on holidays now, I fly out in the morning. Happy testing, I'll check in at odd points over the next couple of weeks. TTFN

EDIT: Apologies if you have no clue what we're talking about. A lot of work has been going on behind the scenes for some cool new parts and features. They will be unveiled in due course

Edited September 15, 2014 by lo-fi

[Gaalidas]

Well, for the texture sharing I do have some good news, but first the bad news. I know, I'm terrible that way.

So, the bad news is that when I tried to setup texture sharing via the MODEL node I ran into an issue with paths which contain spaces. The "accordion-tex 2" texture the repulsors use has a space between the texture name and the numerical suffix. This threw all sorts of nuts into the project. I had an idea this morning for a possible fix that would not be a "quick test" because I would have to launch KSP and wait for a error to be thrown. What I did was open the model in notepad++ and change the texture name referenced at the bottom of the gibberish it displayed to me to use a dash instead of a space, new file name: "accordion-tex-2" and adjusted the name of the texture to match. Upon loading the game, the model and texture was loaded as if nothing was changed at all. Success, and first time too. After making sure I was still awake and breathing, I had to conclude that I really did succeed in the test and could move on without worrying about what is real.

So, while it would be better to have the official files updated so as to remove all spaces from file names, this work-around will have to do for now. I can now replace the textures in the folders with the model with dummy textures of extremely small size, and place the full-size versions in a new folder that I call "CommonTex" because... well... I don't know, I just do. I can then set up each config to replace the entry "mesh = model.mu" (or whatever you named the .mu) with a multi-line entry:

Using the AlphaRepulsor as my demonstration part, with the changed file name I mentioned above.
MODEL
{

[INDENT]model = WheelDev-master/AlphaRepulsor/AlphaRepulsor
//model name without extension.
texture = accordion-tex-2 , WheelDev-master/CommonTex/accordion-tex-2
//texture name without extension, path to new texture from the root "GameData" directory.
[/INDENT]

}

The folder where the model resides will need to have textures of the same names as it expects, but those can be dummies.

You can then add more lines consisting of "texture = " in the format above if the model needs more textures that are common. Textures that come to mind: "CF+A" and "RubberLoGrav" which are used several times. "CF+A" might cause some teeny problems due to the mathematical operator used in its name, but I have not tried it yet.

Now, the really good news is that your mod is not heavy on the texture memory at all. I'm just doing this for all of my non-optimized mods right now in an attempt to reduce my occasional issues, especially when running KSP on a non-gaming laptop.

I'd also like to set up a MM config to add, if Firespitter is installed, a texture swap module. This I did try recently, but failed miserably because I have no way of figuring out reliably what the "object name" assignment in the texture swap config needs to be. I assume it needs to be the object definition in the .mu that references the texture that's going to be swapped, but I'm browsing the .mu files with a text editor and that provides pure unadulterated gibberish... mostly. It's a work in progress, and not necessary at this moment to even think about.

Edited September 15, 2014 by Gaalidas

[Robotengineer]

Would it be possible to give the wheels from TohouTorpedoe's MMW mod smooth steer?

[AccidentalDisassembly]

I've got a small suggestion or twoto add to the pile - if it's possible, it would be great if the Alpha Track (the non-inverting, non-mole one) had a surface attachment point/location higher up on the backside of its model. It seems like it should attach where the white elements are, but it attaches in the middle of the model instead (I think). I don't know if this just involves moving the node_attach up a bit or if it's more involved. The same can be accomplished right now (sort of) by just moving the model around and rotating it appropriately, of course, but within limits- it'd be cool to avoid that step & get some easier built-in ground clearance!

Secondly, in keeping with the ground clearance theme, it would be handy to have a relatively long, surface-attachable part meant to stick out at a downward angle from the bottom or side of a part and to have a track attached to it. The cross-section of the part would be rectangular with a mitred edge to which the track (or wheels, or whatever) would attach, the idea being that the mitred egde ends up perpendicular / vertical in relation to the ground while the part itself extends downward and out at a 45 deg. angle, or whatever. Alternate version: rhombus cross-section. Hopefully that description makes sense-ish.

[lo-fi]

Well, for the texture sharing I do have some good news, but first the bad news. I know, I'm terrible that way.

So, the bad news is that when I tried to setup texture sharing via the MODEL node I ran into an issue with paths which contain spaces. The "accordion-tex 2" texture the repulsors use has a space between the texture name and the numerical suffix. This threw all sorts of nuts into the project. I had an idea this morning for a possible fix that would not be a "quick test" because I would have to launch KSP and wait for a error to be thrown. What I did was open the model in notepad++ and change the texture name referenced at the bottom of the gibberish it displayed to me to use a dash instead of a space, new file name: "accordion-tex-2" and adjusted the name of the texture to match. Upon loading the game, the model and texture was loaded as if nothing was changed at all. Success, and first time too. After making sure I was still awake and breathing, I had to conclude that I really did succeed in the test and could move on without worrying about what is real.

So, while it would be better to have the official files updated so as to remove all spaces from file names, this work-around will have to do for now. I can now replace the textures in the folders with the model with dummy textures of extremely small size, and place the full-size versions in a new folder that I call "CommonTex" because... well... I don't know, I just do. I can then set up each config to replace the entry "mesh = model.mu" (or whatever you named the .mu) with a multi-line entry:

Using the AlphaRepulsor as my demonstration part, with the changed file name I mentioned above.
MODEL
{

[INDENT]model = WheelDev-master/AlphaRepulsor/AlphaRepulsor
//model name without extension.
texture = accordion-tex-2 , WheelDev-master/CommonTex/accordion-tex-2
//texture name without extension, path to new texture from the root "GameData" directory.
[/INDENT]

}

The folder where the model resides will need to have textures of the same names as it expects, but those can be dummies.

You can then add more lines consisting of "texture = " in the format above if the model needs more textures that are common. Textures that come to mind: "CF+A" and "RubberLoGrav" which are used several times. "CF+A" might cause some teeny problems due to the mathematical operator used in its name, but I have not tried it yet.

Now, the really good news is that your mod is not heavy on the texture memory at all. I'm just doing this for all of my non-optimized mods right now in an attempt to reduce my occasional issues, especially when running KSP on a non-gaming laptop.

I'd also like to set up a MM config to add, if Firespitter is installed, a texture swap module. This I did try recently, but failed miserably because I have no way of figuring out reliably what the "object name" assignment in the texture swap config needs to be. I assume it needs to be the object definition in the .mu that references the texture that's going to be swapped, but I'm browsing the .mu files with a text editor and that provides pure unadulterated gibberish... mostly. It's a work in progress, and not necessary at this moment to even think about.

Excellent work, thank you. I need to do a texture rename pass as they're all over the place. I'll keep a weather eye on naming and document. Thanks for the config tips

Would it be possible to give the wheels from TohouTorpedoe's MMW mod smooth steer?

Yes, I would think so. I believe he uses the stock module with some stuff on top, the same as I used to, so just a couple of changes in the unity rigging if TT is so inclined. Spanner knows all about it, he might well be able to help run you through it while I'm away.

Seems a little surreal talking about using my plugin for other projects... A few months ago I was a KSP player marvelling at how cool the modding scene is with no clue how you even went about making models, let alone a plugin. Anyway, basically treat it like FireSpitter in terms of installation instructions, bundling etc. and I'll update the OP to mirror those instructions when I get back from holiday. I'll help where I can on my return, of course.

[lo-fi]

Well, for the texture sharing I do have some good news, but first the bad news. I know, I'm terrible that way.

So, the bad news is that when I tried to setup texture sharing via the MODEL node I ran into an issue with paths which contain spaces. The "accordion-tex 2" texture the repulsors use has a space between the texture name and the numerical suffix. This threw all sorts of nuts into the project. I had an idea this morning for a possible fix that would not be a "quick test" because I would have to launch KSP and wait for a error to be thrown. What I did was open the model in notepad++ and change the texture name referenced at the bottom of the gibberish it displayed to me to use a dash instead of a space, new file name: "accordion-tex-2" and adjusted the name of the texture to match. Upon loading the game, the model and texture was loaded as if nothing was changed at all. Success, and first time too. After making sure I was still awake and breathing, I had to conclude that I really did succeed in the test and could move on without worrying about what is real.

So, while it would be better to have the official files updated so as to remove all spaces from file names, this work-around will have to do for now. I can now replace the textures in the folders with the model with dummy textures of extremely small size, and place the full-size versions in a new folder that I call "CommonTex" because... well... I don't know, I just do. I can then set up each config to replace the entry "mesh = model.mu" (or whatever you named the .mu) with a multi-line entry:

Using the AlphaRepulsor as my demonstration part, with the changed file name I mentioned above.
MODEL
{

[INDENT]model = WheelDev-master/AlphaRepulsor/AlphaRepulsor
//model name without extension.
texture = accordion-tex-2 , WheelDev-master/CommonTex/accordion-tex-2
//texture name without extension, path to new texture from the root "GameData" directory.
[/INDENT]

}

The folder where the model resides will need to have textures of the same names as it expects, but those can be dummies.

You can then add more lines consisting of "texture = " in the format above if the model needs more textures that are common. Textures that come to mind: "CF+A" and "RubberLoGrav" which are used several times. "CF+A" might cause some teeny problems due to the mathematical operator used in its name, but I have not tried it yet.

Now, the really good news is that your mod is not heavy on the texture memory at all. I'm just doing this for all of my non-optimized mods right now in an attempt to reduce my occasional issues, especially when running KSP on a non-gaming laptop.

I'd also like to set up a MM config to add, if Firespitter is installed, a texture swap module. This I did try recently, but failed miserably because I have no way of figuring out reliably what the "object name" assignment in the texture swap config needs to be. I assume it needs to be the object definition in the .mu that references the texture that's going to be swapped, but I'm browsing the .mu files with a text editor and that provides pure unadulterated gibberish... mostly. It's a work in progress, and not necessary at this moment to even think about.

Would it be possible to give the wheels from TohouTorpedoe's MMW mod smooth steer?

I've got a small suggestion or twoto add to the pile - if it's possible, it would be great if the Alpha Track (the non-inverting, non-mole one) had a surface attachment point/location higher up on the backside of its model. It seems like it should attach where the white elements are, but it attaches in the middle of the model instead (I think). I don't know if this just involves moving the node_attach up a bit or if it's more involved. The same can be accomplished right now (sort of) by just moving the model around and rotating it appropriately, of course, but within limits- it'd be cool to avoid that step & get some easier built-in ground clearance!

Secondly, in keeping with the ground clearance theme, it would be handy to have a relatively long, surface-attachable part meant to stick out at a downward angle from the bottom or side of a part and to have a track attached to it. The cross-section of the part would be rectangular with a mitred edge to which the track (or wheels, or whatever) would attach, the idea being that the mitred egde ends up perpendicular / vertical in relation to the ground while the part itself extends downward and out at a 45 deg. angle, or whatever. Alternate version: rhombus cross-section. Hopefully that description makes sense-ish.

Next version will have parts with centre of gravity and attach node updates. One step ahead of you You can move the attach point in the node_attach line in the config if you want to play, though. The wiki has a good explanation, but you want the second set of numbers which govern the Y axis, IIRC. That's kinda how I started modding, so I'd absolutely encourage getting stuck in and playing about. I learned a lot just messing about in configs.

Could you do a sketch? Sounds like a good idea!

[AccidentalDisassembly]

Next version will have parts with centre of gravity and attach node updates. One step ahead of you You can move the attach point in the node_attach line in the config if you want to play, though. The wiki has a good explanation, but you want the second set of numbers which govern the Y axis, IIRC. That's kinda how I started modding, so I'd absolutely encourage getting stuck in and playing about. I learned a lot just messing about in configs.

Could you do a sketch? Sounds like a good idea!

Aha! Possibly even two steps ahead.

I can do a bad sketch, at least. I'll update post when I have one.

EDIT:

Truthfully, not sure how important such a thing would be. Not really a lot of off-roading in KSP, but might help with wide/long vehicles?

Edited September 15, 2014 by AccidentalDisassembly

[mjy]

hi, as for the models, meshes released, there a mix of freeware,custom meshes, had to fix up a lot of stuff for them to be added into ksp, but was worth the work. low meshes, so I can add tons and still can play w/o lag

anyway, I was fooling around with the tracks, how do u ajust the brakes, is it brake torque, as it needs to slow down slower, as right now it brakes to fast, ty

[lo-fi]

Aha! Possibly even two steps ahead.

I can do a bad sketch, at least. I'll update post when I have one.

EDIT:

https://dl.dropboxusercontent.com/u/59567837/crappysketch1.png

Truthfully, not sure how important such a thing would be. Not really a lot of off-roading in KSP, but might help with wide/long vehicles?

Actually, a useful thing to add to the rover body release when I get to that. Gives me a few ideas, at least

hi, as for the models, meshes released, there a mix of freeware,custom meshes, had to fix up a lot of stuff for them to be added into ksp, but was worth the work. low meshes, so I can add tons and still can play w/o lag

anyway, I was fooling around with the tracks, how do u ajust the brakes, is it brake torque, as it needs to slow down slower, as right now it brakes to fast, ty

Good work, I like the textures too.

Yes. Either brakeTorque or brakingTorque (I forget which it is in the config).

[Skyro]

Just a quick question, with the poll showing what people want, what do you plan to add to either this patch or 1.8? I mean, they're probably going to be tracks, but if so, what would some of them look like? If you don't mind doing another not-bad sketch. But, seeing as you still need to do things, just checking in because I love this mod and depend on it for a lot of things

EDIT: Also, how does the track collision mesh and such work if its considered a wheel by KSP means? Unless a plugin defines it, then nevermind

Edited September 16, 2014 by Skyro

[lo-fi]

A longer track is built, it just needs the deformation skinning (which takes a little time), and I'm hoping to get the models for the original smaller tracks from RBI at some point. Also have an idea for a folding mini track, a high speed track and a centre or bottom mount track unit a little like a snowmobile.

The helical drive will also see the light of day (read a few pages back), as, hopefully will the repulsor wheels, which convert BTTF style from wheels into repulsors. A lightweight folding wheel is also trying to fight its way out of my head and into KSP, along with some dedicated rover body designs. Spanner is kindly contributing too, so there is some cool stuff from him that will get bundled into future KF releases as they come along - rover bodies included.

The plugin writing has been taking up literally all the time I've had for the past week or more, so there are lots of modelling ideas backed up in the queue. So glad I did it, as it gives me a solid, known platform to model to, rather than bodging things to existing modules not designed to do what I'm doing with them. Hopefully its flexible enough for other mods to use in the future too

The tracks use multiple wheel colliders, typically one or more for each wheel. The rotation you see of the wheel meshes is actually a calculated average of which ones are grounded and not freewheeling and this also drives the track texture rotation. In short: plugin trickery

Edit: This is in no particular order. Someone said to me, in the first few posts of the thread: "do what you like and makes you happy". Which I thought was very solid advice, and that's exactly what I tend to do. The poll is interesting, and I'm sort of using as a rough guide. It will be even more interesting to see it change as more and different parts are released. I'm still surprised by how popular the tracks are!!

Edited September 16, 2014 by lo-fi

[Skyro]

Oh ok, that definitely explains how the tracks actually work in KSP, as well as the tracks aren't just one wheel I mean i knew that, the tracks have individual wheels...duh But yeah, thanks for explaining!

[Gaalidas]

It's definitely something that needs explaining sometimes. In KSP you can have, technically, a whole slew of wheels of different sizes and shapes, all animating together, and yet be defined as "one wheel" as opposed to all of them being separate entities. It gets confusing when your eyes say "ooo... multiple circular thingies!!!" and your brain is saying "ooo... one giant object with multiple colliders and animated parts!!!"