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

[lo-fi]

I'll get back to you guys more fully later - far too busy nearly killing myself on horseback and getting drunk to do much else.

There are no special cases made for anything at the moment, so dust is thrown if wheels are grounded and moving.

The code I used is meant for taking screen shots - hence the references, and I used commented out sections as an aid to fighting out if the camera was working. It does no saving or writing currently, would be far too slow! I'm sure it can still be optimised though.

[Gaalidas]

Good to know. I was just a little worried when I noticed the screenshot references.

Good luck trying to kill yourself. I'm pulling for you. If you do make it to the other side, be sure to come back and let us know how it is. I'm particularly interested to know if there's baseball in heaven. If I'm pitching tonight, a little heads-up would be awesome.

I did some poking around in the code and I really don't think it will emit any dust on non-static or non-PQS collisions. I'll do some testing later if I get a chance. We're getting some record temperatures for my area and it's rather hard to concentrate when the humidity is high enough that you're practically swimming though the air. Of course, it's nothing compared to the hotter areas of the world, but it's all relative anyway.

If I get any dust from those non-PQS/static collisions, I suppose I could add something similar to the check for the water collider that, instead of redefining the dust parameters, simply disables it. I also intend to further limit when the dust is emitted since I really doubt that a ton of dust would be emitted when moving very slowly over the terrain.

Another thing I want to look at, or get you to look at lo-fi, is further integrating DustFX with the Repulsors, now that you've been integrating it more with the wheels. I also need a way to redefine the default values of the DustFX fields based on whether a repulsor or a wheel is calling for it, so that I can switch between throwing dust when the craft is moving, to throwing dust when the repulsion field is active. The complexity of it all is why I originally planned to have a separate module to run the Repulsor effect

This also gives me an idea: perhaps we should extract out the effect-based sound effects for the wheels/repulsors and any sound stuff from the DustFX files into a separate source file that would act as our audio-controller method. That might help to further reduce the redefined code in all of our various audio systems. We might also be able to define an audio modifier for when the wheels are throwing up dust vs. when they're simply rolling slowly/idling. For the repulsors, it would be awesome to have an idling sound for when the repulsors are active, but not moving, and then a sound for when they are active on a moving craft, and a third for when they are active over water. If I get bored later, I think I'll do some messing around with all that and see what the options are. If I use the stock module for the engines as an example, I may be able to come up with something we can use that will be able to be set up the same way the other audio calls are done in the effect nodes.

EDIT: A thought about optimization of the camera stuff. One thing to look into is whether or not the camera is still taking samples from the terrain when the dust effect is not running. When the craft is stationary (for wheels at least) the dust isn't being emitted and the camera should probably be turned off. For instances where the craft is over water, for repulsors and the screw or any other propeller enabled parts, you don't necessarily need to take an image for every part. Besides, since the screw and other such parts are probably going to be under the water when running, you'll get the image of the ground below the water and not the water itself, which is why I'm trying to find a good way to define the color to emit when over/in water.

I'm thinking that instead of having a camera active for every wheel on the craft, we need to find a way to run the dust controller on the vessel as a whole, taking stock of all the wheels on the craft and building an array of cameras that cover the average areas between wheels that are within a certain distance of each other, or individually for outliers. This would reduce the number of samples being taken on a craft where someone might either tweak the scale of a bunch of medium wheels to really tiny levels and attempt to support a massive craft with, say, 80 of them. Or if someone used the same number of small wheels to do the same thing. Granted, the standard steering and suspension modules would probably slow the game down a ton with 80 medium wheels, but the camera and dust systems would slow it down by a larger factor than the other modules would. I'd like to find a good way to not only average out of the effect between individual parts that have multiple collision points (tracks and such) but also be able to average out the effects between closely-positioned separate wheels. I'd also like to find a good way to limit the dust being emitted from wheels that are in the very front of a craft or are not along the edges of the craft. I don't want to see dust rising through my nearly ground-hugging craft's hull when I have lots of wheels mounted under it to support its massive weight.

The trick is going to be finding a balance between attempting to optimize the number of dust and color samples that are being called for, and the performance hit from simply detecting all these conditions. eventually you could optimize the whole system a ton, but the methods for detecting all the situations where optimization can occur could start lagging the simulation a ton on their own.

So, yeah... Output output output... I'm going to do some digging through your code, lo-fi, and see what I can figure out from that. I assume you have some way of taking stock of all the wheels of the craft, since they all handle their steering in relation to each other so you can have that variable steering thing going on.

Of course, all this should be planned for a future release, and not the one we really should be doing now.

Edited June 28, 2015 by Gaalidas

[lo-fi]

Normal service will resume when I recover... Thank you for your patience...

Oh, and I devised a new grip model while diving today!

[Gaalidas]

You multitasker you.

[lo-fi]

Now I need three days to read your last posts...

The camera stuff is a vessel module, not a part module. This means one instance gets added for each active vessel in flight automatically. IIRC, the update routine checks if the vessel it's running on is active vessel. This is why it's done in VesselTools, and doesn't need an MM patch or anything to get it running. The repulsors will just need a similar mechanic to the wheels added in - it's no big deal. KFModuleWheel just searches for the camera module on the attached vessel and grabs the colours to pass up to the dust stuff, though the biome info needs adding back in and some benchmarking done on the camera stuff. Still need to work out what's up with the defaulting biome info, so I'll have to read through EvilReeper's plain English explanation and poke about. Going to be a busy week, though.

[Gaalidas]

Well, I don't know why the biome info stuff is defaulting for you, because it works for me, at least as far as showing the default when colliding with the KSC static landscape vs. the actual planetary surface. I have not had a lot of time to test other biomes, though I recently re-installed some of my Kerbal Konstruct stuff that will allow me to launch into other biomes for quick testing. I propose that we keep both systems for selecting colors available and perhaps create a global toggle to switch between the two methods for the end user, or disable it completely. I've been doing some fiddling with the idea of providing a small configuration menu via a toolbar button that would allow for toggling some global settings for the mod, saving and loading from/to a single-layer config node. That way the end user can decide if they can handle the extra effects or not. Even if I never get around to a GUI, I'd like to allow for some global settings to be available. it should be pretty simply to set up compared to the biome color loader, considering we'd be able to define exactly what we're loading and saving, where the biome color stuff is saving/loading an unknown number of nodes.

The whole vessel module thing does sound pretty interesting though. Could reduce the amount of redundancy in a lot of mods out there which seek to control multiple parts on a craft in sync. At least that's what my limited knowledge is telling me about what I've heard.

So, does this mean that each wheel does not have it's own camera? If half of the wheels are roving over a different material, they will all be the same color still? For small craft, that would be fine, but for larger vehicles you'd have a real continuity issue. I guess my next question is this: where exactly is the camera positioned in relation to the vessel, if indeed every wheel isn't getting it's own camera?

Edited June 30, 2015 by Gaalidas

[lo-fi]

I think we would be in lag central with one camera per wheel!!! One cam per vessel. It's positioned above the vessel, always looking at the center of the planet you're on. Individual wheels don't calc their own colour, it's whatever gets averaged out of the camera and will be the same for all wheels on the craft. Unless you're looking very closely, you really won't notice. Yes, this does mean that the vessel colour is counted in the average, but that actually works quite well and lifts the dust from being exactly the same as the ground.

Have you changed any of the colors recently? Runway used to be grey, but change to brown when you got to the grass. No longer seems to change when off the runway. This was before I experimented with the camera stuff... I drove a rover over to the mountains to see what would happen, but dust still grey. Haven't tried any hyperedit somewhere else yet.

Global configuration file would be good!

[Tyren]

Eeehm. Huh? If i get that correctly, you want to have a general file with the most common ground color per planet to be applied for the not so concerning users right? Furthermore the implementation of a GUI toggle to switch from general to camera handled dustFX management.

Awesome.

- - - Updated - - -

I guess with the first part only Kerbin is somewhat more complex concerning biome colors, the rest is somewhat indifferent. more or less.

[lo-fi]

Yeah, that's kinda what we have - just controls to implement.

Kerrin is indeed the most complex - the rest are fairly simple.

[Gaalidas]

I think we would be in lag central with one camera per wheel!!! One cam per vessel. It's positioned above the vessel, always looking at the center of the planet you're on. Individual wheels don't calc their own colour, it's whatever gets averaged out of the camera and will be the same for all wheels on the craft. Unless you're looking very closely, you really won't notice. Yes, this does mean that the vessel colour is counted in the average, but that actually works quite well and lifts the dust from being exactly the same as the ground.

Have you changed any of the colors recently? Runway used to be grey, but change to brown when you got to the grass. No longer seems to change when off the runway. This was before I experimented with the camera stuff... I drove a rover over to the mountains to see what would happen, but dust still grey. Haven't tried any hyperedit somewhere else yet.

Global configuration file would be good!

That's really strange lo-fi. The weirdest thing that ever happened to me using the biome color definitions was when I was heading towards the mountains and hit a patch of polar biome in the wilderness somewhere around the KSC. That's why I like the camera thing better. I wonder if there's a way to get the camera to ignore the current vessel. Either that, or some way to position the camera below the craft (like a little bit above the wheel colliders when grounded) and take a super-wide angle shot of the ground there. Another thought that comes to mind is that the dust color will then also be modified by any engines the user is running, lights that are illuminating the ground around them, and shadows if their computer can handle them. Thought: I wonder if one could grab the visual of the craft's position on the planetary level (such as what it looks like from orbit, or in the map view but without the various node and info layers rendered) and use that instead of the local image. My brain is really going fast now...

Overall, it's looking like getting the biome color stuff working properly again might be a better option. The only thing I can think of is that squad might have changed some of the format in which the biome names are handled. It's not like we have a way of directly asking KSP what biome we're in and getting a direct response. I believe some strange parsing is done to nail it down. I need to browse the code again. Also, I believe our local reaper put something into the code that allows us to define colors for a LandedAt definition of some sort, which would take a more specific name for a location instead of just the planet and biome. That, or it might be able to take a specific coordinate set. I never understood how I could make that work or how it would be useful.

EDIT: Really guys? I spent 5 minutes looking at the camera stuff in the unity DLLs and discovered something which, unfortunately, I have no clue how to use but seems promising.

public int UnityEngine.Camera.cullingMask { get; set; }
Summary: This is used to render parts of the scene selectively.

I'm going to do some more digging to see what this accepts, but it could be an answer to the problem of the craft itself factoring into the colors.

Edited June 30, 2015 by Gaalidas

[JDCollie]

I don't know if this has been addressed yet, but the tracks seem to have some really weird proportions according to the SPH. In Career mode I was trying to make a rover for some early exploration (I moved the tracks earlier in the tech tree), but even the Small tracks were listed at being over 20m long. (the larger tracks are listed at over 35m!) As far as I can tell this bug only applies to the SPH measurements, as the tracks function just fine in the field, and if I try and put a fairing over said rover, it hugs the vehicle snugly as one would expect.

I run a pretty heavily modded install, so if I'm the only one experiencing this then I'll just chalk it up to mod interaction and ignore it.

Anyway, still loving the mod!

(If you'd like, I can grab a log file when I get home.)

[Tyren]

Is it a readout of the stock measurement thingy?

- - - Updated - - -

More precisely, does it happen with a clean only KF install?

[JDCollie]

Is it a readout of the stock measurement thingy?

- - - Updated - - -

More precisely, does it happen with a clean only KF install?

I just tested on my laptop (clean install). The other parts seem fine, but there is definitely something fishy with the Surface Track, Inverted Track Unit, Small Track, Medium Track, and Long Track, which the SPH lists as 10.4, 11.4, 20, 51.5, and 85.6(!) meters long respectively.

Considering that the longest, the Long Track, can't be physically more than ~6m in length, I'd say something is bugged.

(Interestingly enough, that enormous Mole track is listed at a very reasonable 10.1 meters.)

Edited June 30, 2015 by JDCollie

[Tyren]

Thats weird...and i dont get the reason for KSP to read out that values, either.

I didnt try myself, though. I am solely using it in sandbox mode for bug and break missions atm.

[Gaalidas]

This is probably the same issue that makes the parts overheat and explode even when covered by fairings. The skinned meshes use for the tracks tend to report at being massively larger than they are supposed to be when the game's measurement system does its thing.

In other news, I am going to test, in a moment here, adding a culling mask to the camera for the dust color sampler. It turns out that the culling mask parameter takes an integer value that corresponds to the unique value for the combination of any number of layers and their corresponding numeric values defined by a binary place value output. For instance... I used the layers for water and local scenery. Water is layer 4, and local scenery is layer 15. You put this together by first defining them as "cullingMask = (1 << 4) | (1 << 15)" which translates to "(16) | (32768)" which are added to get "32784." As far as I can tell, and this comes from a lot of experimentation in the code editor, is that the first number is the identity value for the calculation of the second number, which is a binary place value. Using SharpDevelop I am able to tell the editor to turn this into a multiplication equation which gives me "1 * place_value_value" for each equation. For instance, the number for the place value of 4 in binary is equal to 16. That means it's a zero-based number where "1 << 0" will become "1 * 1" or "1 << 4" will becomes "1 * 16" and so on. Then you strip out the redundant identity value and add all the values together. You can either let the compiler do that, or have your editor calculate a constant value for each set, and then for the entire group.

If the tests are successful, then the craft no longer needs to be part of the color calculation and even craft-emitted things such as shadows or lights can be omitted from the calculation.

Edited June 30, 2015 by Gaalidas

[lo-fi]

The crazy reported sizes are indeed to do with the skinned mesh. It's the same reason that the editor icons are tiny if you don't use the icon fixer plugin. Sadly not something I've been able to fix.

The culling mask is cool, Gaalidas. I had a feeling there was something like that you could do, but hadn't looked that far. No idea what's been going on with my biome colour testing, so I'll have to do a little more playing around.

[Gaalidas]

The crazy reported sizes are indeed to do with the skinned mesh. It's the same reason that the editor icons are tiny if you don't use the icon fixer plugin. Sadly not something I've been able to fix.

The culling mask is cool, Gaalidas. I had a feeling there was something like that you could do, but hadn't looked that far. No idea what's been going on with my biome colour testing, so I'll have to do a little more playing around.

To be honest, I haven't tested it enough myself to be sure that it is still working right now. That said, I also haven't tested the culling mask on the cameras yet, so I'm going to fire KSP up now and try it out. I also did some preliminary work on defining a "KFGlobals" config node and calling up a "globalDisableDust" parameter to use. I've also started work on a "localDisableDust" field for a context GUI option so that it can be disabled on a per-wheel basis, which will hide itself from the context menu if the global option is set. No GUI toggle for the global stuff yet... that's going to take time. The great news is that if we think of other options that could use a global toggle, adding those to the config node will be super simple. I used SmokeScreen as a template for it, since it has a simple top-level config node for its global toggles. I just thought of a tweak I need to make to the config loader though, so off to do that now and then testing time.

EDIT: Good news, the config loads and a log entry was able to report back the value of the parameter. No clue if the module will accept it, cause I ran uot of RAM storage before KSP loaded.

Edited July 2, 2015 by Gaalidas

[lo-fi]

Very cool Saw the updates in the parts repo, but don't forget to commit the code changes. Don't worry too much about the UI for the moment, I understand it's a frustrating black art, though you can probably grab a working set of code from somewhere. Global config will be really useful.

[Gaalidas]

On the GUI stuff, I will either take a sample from Smokescreen again, or there's another option that I don't remember the same of... it was a prefabricated set of methods useful in creating GUI windows in any unity environment that I downloaded a while back. Gonna have to dig though some of my sources to find it. Once i get KSP to load properly again (deleting some extra-huge static models from KerbinSide and eliminating overly-useless small statics that don't do anything for game play) I'll get a chance to test my per-part toggle for the dust too, which should disable itself if the global toggle is turned on.

Actually, on that note... I'm confusing myself with the global toggle being "true" if the DustFX enabled state is "false." I may just change that around to "EnableDustFX = true" in the global config.

Anyway, I'll update the code with the changes soon. we still need to figure out if we can use the DustFX stuff for the repulsors without having to have a separate module, while still maintaining the modifications of the dust based not only on craft speed, but also on repulsor height and with a small emission happening even when stationary. The reason I spearated the modules in the first place was because of the issues with separating the settings based on what type of part it's attached to.

That brings up another point... I think the dust is emitted per-wheel collider based on the speed of the vessel. I wonder if that could be changed to take the speed that the individual part is scraping over the surface instead? Actually, it might do that already, but I have not been able to read the code very well in that area, so I'm not sure what it really happening. Anyway, the idea is that if a larger craft with a wide wheel base is turning sharply, you'd expect more dust to be thrown up on the outside of the turn. I also want to find a way to have a very small dust emission from the front/back of a track when turning at a stationary to near-stationary surface speed. Finally, I want to made the base emission amount settable from the biome configs. I'm thinking that, since I was previously trying to use the alpha layer to control the visible dust, I could use the alpha layer to also define the base emission amount if I can figure out how to extract that value from the color in the biome config file. This would also give us a reason to re-enable the biome color definition loader for the DustFX module in addition to loading the camera colors.

That brings up yet another thought: the camera currently sits at a fixed height above, I'm assuming here, what would be considered the exact center of the physical craft. I'm wondering if it could be made to set that height based on the size of the craft so that we could sample all the colors that the vessel is currently running over. Either that, or somehow scale the field of view for the camera. Also, if performance becomes as issue with something like that, we might be able to improve performance if we switched from taking a square image to a very short and wide shot, scaled by vessel horizontal size (x/y if looking at it from above, using my limit knowledge on what the axis indicators refer to in KSP) so that you'd get maybe 2 pixels heigh, but... for example only... 20 of them over the width. It's less image space to cycle through when averaging all the colors. Just a thought.

Anyway, don't want to bother you with figuring all of this out... you've got other things to finish before we can release this baby. Just sharing my thoughts and plans for the future of the "special effects" department. I'm gonna make this baby look purdy!

[Tyren]

Another 'special effect' would be dust thrown out at the upper front in moving direction of the tracks. Just like sticky mud and dust pieces hauley all the way around the upper side of the track until finally falling off at the front. Usually this effect kicks in at medium speed.

- - - Updated - - -

Technically a particle emmission with the same width of the front wheel at the upper sector of it with a shallow diagonal angle towards the ground. My english fails here for further explanation...

- - - Updated - - -

Found a pic, look at those 'plumes' at the front

[Tyren]

Ok i gave mysef some headache and thought it through...

I cant deliver real code solutions cuz i am far away from programming, shikashi:

mentioned effect does not apply to free mounted tracks

effect is altered if:

top of the track is shrouded beyond the center of the last wheel, so it will need a check if there are parts whom can deflect thrown up dust and if it will be carried to the front

top of the track is shrouded beyond the center of the first wheel, effect at the front will be deflected downwards

side of the track is shrouded, the fall out of the dust from the top will be deflected and 'compressed'

additional mud guarding around the wheels, deflection values for the dust effect are to implement...

Well, better ignore it, thats a humongous hell of work.^^

Nevertheless, closer to reality regarding dust effects from tracks wont be that easy to accomplish imho, nor do i have an idea if it is possible to code that.

[lo-fi]

Anything is possible, it just depends how much work you want to put into it

More complex dust generation would be cool, but may be beyond the scope of KSP.

Have a good look at the wheel collider hit scripting docs, Gaalidas. All the stuff you want to do is achievable by grabbing info from the wheel colliders hit point. At the moment, the only info I grab is the hit coordinate, but slip amount (both long and lat separately) and force are also available. The methods just needs expanding to encompass those. So much more is available to us this way than you can gain using the generic OnCollision method.

Do consider my camera code a very basic proof of concept. It will need a lot of fleshing out for prime time, but it is fun to play around with.

[Tyren]

Hmm i dont think Unity would fail with those effects. But its really ahella work to do for that, so maybe better let it run as is.

Probably with a descent implemention of x64 / U5 it could be reconsidered...

[Gaalidas]

Anything is possible, it just depends how much work you want to put into it

More complex dust generation would be cool, but may be beyond the scope of KSP.

Have a good look at the wheel collider hit scripting docs, Gaalidas. All the stuff you want to do is achievable by grabbing info from the wheel colliders hit point. At the moment, the only info I grab is the hit coordinate, but slip amount (both long and lat separately) and force are also available. The methods just needs expanding to encompass those. So much more is available to us this way than you can gain using the generic OnCollision method.

Do consider my camera code a very basic proof of concept. It will need a lot of fleshing out for prime time, but it is fun to play around with.

Indeed, I'm having a grand time thinking of all the possibilities. I'm currently researching some methods in the Unity/KSP DLLs that are used to determine the size of the craft (I think they use it mainly to scale the craft appearance in the new load-screen previewer, but the functionality doesn't seem to be specifically limited to the editors) which I may be able to use to figure out how I want to camera to behave. I have yet to try changing the dimensions of the camera field to a non-square, but I figure if the guys making those bolt-on cameras could make a wide angle camera, then it must be doable. if I do get around to that, and it seems stable enough, I may even look into adding a second camera and trying to aim the cameras at the left/right sides of the craft to get info for those specific sides and then modify the dust color to react to the side of the craft the part is on. Also, I tested the culling mask and it seems to work well. What I want to do now is find a way to put a randomness into the colors so that it's not just a solid average color. Think I could simply do a mathematical operation on the color object to add/subtract a certain value from the color channels within? Of course, that would affect the alpha level as well, which is not what I want... I might have to disassemble the color into separate RGBA values and then apply the variance. Hmm... need to do some research. Anyway, wheels within wheels.

For the time being, I have merged all of this with the main repository since the camera grab seems stable, and that includes my Logging Utility that I talked about a while back. It's not a complete implementation of what the other utility mods do for logging purposes, but it works for now and seems stable. I attempted to make it work the way the others do it by allowing the calling methods to simply call it by name, without having to define an object in the local scope, and with automated checks for the class/method name that is calling it, but those things were resisting me. I kept getting situations where, first off, it couldn't find the method name in the current scope even though the other mods I looked at didn't seem to have anything different in them and it worked perfectly. Secondly, once I defined an object in the local scope, it then couldn't locate the name of the class/method and would either display the class/method name of the class it was coded into (the log utility class) or error out on me. It couldn't even locate the names when called into a string in the scope of the class that was calling the log. I threw in the towel on those and simply defined a class-name string at the top of the files I wanted to use the log utility on, and defined at object for it. I want to make this thing work better in the future, but right now it's looking like it can't be done, unless (maybe) I separate it into it's own DLL so the KF_plugin project can reference it properly.

Complaints aside, you'll see how it works. It will prefix the log entry with "[Kerbal Foundries - class_name()]: " and will output it as a Warning, Error, or just a basic log entry when you call it with "KFLog.Warning/Error/Log" and even has a "KFLog.Debug" option which will turn the prefix into "[Kerbal Foundries - class_name() : DEBUG]: " so it can be easily found. If the class name is not passed to the utility, then it will come out simply as "[Kerbal Foundries]: "

Finally, there's the global variables. I'm still working on those, but I merged in the definition file a day or so ago, and today I've added the source file to the repository, and added it to the project file. Extremely WIP right now, but I can report that the variable is read, and the DustFX module does not give any errors when using that variable data. Whether is all works is another story, but I want a way to toggle it in-game before I do much testing. I'll get a per-wheel toggle working soon enough anyway. I've made some preliminary attempts, and it might even work now if you want to give it a go. It's on the part's context menu and available in the editor and the flight scenes.

- - - Updated - - -

Another 'special effect' would be dust thrown out at the upper front in moving direction of the tracks. Just like sticky mud and dust pieces hauley all the way around the upper side of the track until finally falling off at the front. Usually this effect kicks in at medium speed.

- - - Updated - - -

Technically a particle emmission with the same width of the front wheel at the upper sector of it with a shallow diagonal angle towards the ground. My english fails here for further explanation...

- - - Updated - - -

Found a pic, look at those 'plumes' at the front

http://www.army-technology.com/projects/challenger2/images/chal1.jpg

That work be awesome, but it's a bit out of my range right now. I didn't even create the basic code for emitting a particle, much less create something brand new like that. Besides, I'm trying to create an effect that will be applicable for standard KSP uses, which means off-world dust plumes that don't necessarily react to the gravity/atmosphere on that body. Something like that would only really be useful in a desert region on a Kerbin-like body. My hope is that squad implements something like material densities to the biomes in the future, and creates their own per-biome surface effect system, or even a whole part-scraping particle emission system of their own. Sure, it would make DustFX obsolete, but that doesn't mean I couldn't still try to expand it with cool new features. At least then I'd be able to work off of official modules which would probably have much more efficient ways to detecting the materials we're scraping over. Here's hoping someone at squad is paying attention when we unveil this mod to the public.

[Tyren]

I will definitely try to draw their attention to this

But regarding the effects: i think there would be more bodies it would apply to...basically all atmosphereless bodies due to the fact they are covered with fine material - lack of wind etc - and some with a low atmo density and/or low gravity, like duna...

But for now, its an idea for later on. just wanted to share it