drewmacrae

Good job with the omniwheels. I like how they work

Tested in 0.17 and still works. Top speed appears to be 7m/s after the rescale. The .cfg files can be edited to change top speed.

The present system to generate an atmospheric flight model in KSP is the best I\'ve seen made available to the public. It allows for arbitrary design of craft and then arbitrary destruction of the assembled components while maintaining a reasonably credible flight model. Designing planes is a frustrating process, and I think it\'s great that this realism affects KSP. There have been claims that the difficulty in designing large planes is due to innacuracies in the winglet model used to compute lift and drag. I don\'t think that\'s the case, but the current model does encourage the sorts of things we saw when people were trying to fly for the first time, and this is partly a result of the winglet model. I\'m not a fan of telling people how to do their jobs, but I\'m of the opinion that Squad should focus on features that require intimate knowledge of the KSP code base, and ones that are impossible with mods; I don\'t feel this is one of them and it seems this could be developed externally in a mod, so I\'m going to take a crack at it. I have a tendency to move slowly on some projects or to put them down entirely so I think opening up this process for comment might be beneficial to the community. If someone wants to pick this up at any point and do the next step, I\'ll be grateful for the help. I\'ll post a link to a Google code project once I have built up some source code. All I know about aerodynamics I\'ve learned from RC planes, model rockets, simulators and from the internet. I don\'t consider myself an expert, but I feel I have a lot of the knowledge needed to produce a wing plugin and that it will be an interesting problem. I asked a friend for help, regarding a problem of wings flying sideways through the air especially if there was information available at sub/trans/and supersonic regimes. He was the one who originally showed me KSP last August, and has more formal aerospace training than I do. I thoguht he might know which terms to punch into Google at the very least. He informed me that a sideways version of AOA is called sideslip, and that there\'s not much information characterizing wings behavior in side-slip because the aircraft tend to be characterized as a whole instead. He sent me one paper he felt might be helpful. http://openae.org/files/resources/datcom/Datcom_handbook_1978_edition/Section_5_Slideslip.pdf If that qualifies as not much information I\'d hate to be researching something where there is a lot. I find I can\'t understand that resource on it\'s own, and no amount of math is going to get me there, so here\'s the equivalent of a decoder ring for all the funny looking letters: http://lahso.megginson.com/2005/07/18/the-alpha-beta-of-flying/ The first referenced paper in the long one looks helpful: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19930082233_1993082233.pdf I\'ve been told that these old NACA publications are worthwhile. In fact it\'s nice because as they develop the theory here along with some early swept wing development they\'re introducing terms for the first time which means they see fit to define them. This is a great collection of data, and it looks like it\'s almost ready for implementation. It\'s coverage of swept wings doesn\'t quite isolate winged pairs. Wing plugin scope 0.1 release: The C7 swept wing and small control surface will each have their lift and drag model overridden with a subsonic model for lift and drag at a variety of AoA and sideslip conditions based on interpolation of some data set, likely from the above NACA paper. The model will assume the wing is moving trhough the air in a symmetric but otherwise independant pair through the air so as not to require simulation of the wakes of other parts. This will enable craft to generate more lift at smaller AoAs and then to simulate stalls with reduced lift and increased drag at higher AoAs, so we get to see our planes fly with 5 degree AoAs instead of 55 degrees. I imagine constructing 0.1 in the following manner [list type=decimal] [li]plugin will be an extension of the winglet, parts will be changed to 'wings' and 'control wings'[/li] [li]Removing the current forces by setting drag and lift to zero[/li] [li]Checking that I can insert craft relative lift by applying it in the vessel.up direction[/li] [li]printing AoA and sideslip for the wing when arbitrarily attached to a plane[/li] [li]use nearest interpolation to lookup lift and drag as a function of sideslip and aoa[/li] [li]develop interpolation methods to better compute lift and drag as a function of aoa and sideslip[/li] Future releases may have the following features in no particular order: [li]Stall horns[/li] [li]Stick pusher stall prevention[/li] [li]Improved drag models for other types of parts (nosecones, aeroshells, everything else)[/li] [li]Trans/supersonic models[/li] [li]Atmospheric heating effects[/li] [li]Stochastic Raycast based wake effects[/li] [li]Exhaust aware wake effects[/li] Open questions [li]How do I determine velocity relative to the air?[/li] and plenty more to follow I\'m sure...

Are Kerbals lucky? If so, I\'m feeling very Kerbal at the moment.

Ah yes, reading this over in retrospect there isn\'t much info on what any of it means. OK, here I\'m going to try to actually explain it without drawing a wall of equations. This strategy for orbital intercept allows you to perform the difficult computation at the time of writing your flight plan when intercepting objects in circular orbits. A target at a known circular orbit can be intercepted accurately and without any measurements that can\'t be made within either the map view or the flight view. The computations at the time of the flight are approximate, but may be performed by hand. All computations are assumed to occur in plane. My inspiration for this was based in part on not understanding the info in rincomp (orbiter 2010 has since taught me what most of it meant.) It\'s difficult to measure the orbital phase between a craft and a target at points other than 0 and 180 degrees. Approximate, ascending interception is performed as described for orbits higher than 158,000m: Craft climbs to circular staging orbit at 1/1.42* the target orbital radius. Craft circularizes in staging orbit When the target passes over the craft (phase is 0) the craft executes a burn to raise apogee to target orbit After the craft performs 2.5 transfer orbits, (and the target performs 1.5) the craft should achieve an approximate intercept and may either circularize or begin the next process immediately which in the event of a leading target will save fuel by not elevating the perigee to the target altitude until later. Final phase adjustment is more interesting and involves some precomputation when producing the flight plan (based on the target altitude) At apogee the craft should be at the target altitude. Measurements, computations and burns will be made only at this point in the orbit (very small burns at the opposite point may be necessary to adjust for drift in this point and inclination may be adjusted to bring orbit onto the target orbit plane as appropriate). At apogee and after each successive orbit: The error should be measured approximately in map view or flight view (I didn\'t have radar when I first developed this but that\'s probably a good way to measure now) A precomputed differential for circular orbits, can be multiplied by the error to determine the target altitude for the opposing somethingee of the orbit. The precomputation is measuring how many meters of a lead or a lag will be produced by a small adjustment of the oposite somethingee of the orbit. (which may be an apogee or a perigee depending on the sign of the error). Knowing this, and the number of meters of lead or lag for which we want to compensate, we\'re able to find an approximate altitude to place the opposite somethingee. The craft orbit is adjusted accordingly. This pattern is repeated with each successive orbit until rendezvous is achieved. The approximation works for the same reason a first order approximation works for Newton\'s method: as the error is reduced so is the innacuracy in the approximation. You should be close enough to use RCS for stationkeeping after 2 or 3 orbits. This method could be adapted for elliptical orbits as well timing burns at the apogee or perigee. To perform the precomputation (approxmately) I used the equation for the period of an elliptical orbit: =PI()*SQRT((Rap+Rpe)^3/mu) to determine the period of the target orbit and one with a perigee one meter higher than the target. The difference can then be converted (approximately) to a distance using the circumference of the target orbit and its period. Later, knowing the error and how much error 1m of opposite somethingee altitude will correct, we can then produce an optimal gain for the error measurement to control the altitude of the opposite somethingee. Of course using half the value would use twice as much time but less fuel so the phrase optimal refers to single orbit interception targets and is optimal within the constraint that the system is linear (which it isn\'t) Hope that helps. Let me know if you want me to clarify/correct/expand on any particular part.

Card, I like your suggesstion, and I\'ll take it into consideration. I\'m currently having trouble with my VAB tabs being too cluttered with parts. I just did a fresh install of KSP and I\'m reluctant to add mods and I certainly don\'t want to make my parts dependent on others.

Update your plugin sander and you should be able to have them work sideways.

When my friends ask me what KSP is, I often say it\'s essentially what the space age of Spore could and should have been. That game had so much potential and was fun to play for about 10 hours. I\'ve spent far more time on KSP.

I\'d love to help. I\'ll keep an eye on this and I\'ll let you know if I feel able to make a substantive contribution.

While testing, my experience was that smaller wheels were more dangerous wheels. It\'s unlikely anything much smaller would be likely to be able to roll off the launch pad while still reasonably utilizing unity wheel colliders, but you can cheat and simulate the wheels as bigger than they\'re drawn. I\'m not very talented with blender or with asset design in general. I\'ve laid the groundwork here, and I believe smaller/nonsteering/nondriving/wider wheels can all be made using the wheel plugin. Let me get in touch with NovaSilisko, the prospect of getting them in Probodyne might be sufficient to motivate/inspire me to make a rover wheel. I imagine this has something to do with the way I test to see if the ship is controllable. I\'ll try to debug this if I can reproduce it. I haven\'t used the relay mod yet though I like the concept. (Thanks for checking again SOLID) Everyone will want something different with deployment. Just look at how many different landing leg or solar panel mods are out there. I\'m confident that maintaining 'deploy-able' versions of every part isn\'t the right way to do things when in the end, someone is going to want to deploy everything. These parts are open source, which means anyone can extend them. I\'m happy to provide support if any of the advocates of deploy-able wheels would like to get started on them. I\'d rather spend my time trying to make a general purpose deployment node and possibly failing, than making deploy-able wheels.

Try the new version. Deactivating the wheels with the ';' key should serve as your parking brake.

Pushed the V0.3 update to Github and now you should be able to build sideways rovers which drive a bit more intuitively as rovers (less sensible as crawlers). The wheels now apply whatever force best provides the six axis moments commanded of the command module. The omniwheels demonstrate the capabilities of the plugin, but I don\'t like them, so I moved them to an Archive folder. If you like them, you can move them out and use them, or better yet you can branch them off. Activity can be switched on and off too. Don\'t land on inactive wheels though. Hope you like it.

I tweaked the friction downward so there would be fewer rollovers, but I\'m not able to reproduce this, can you post a .craft and a .sfs file that demonstrate this? Do you mean tracks like a halftrack, or tracks like a traintrack? If you meant like a halftrack, I\'ve been thinking about that. I\'d like to make some, but the idea is only starting to come together in my head. The real trouble with tracks is that they don\'t turn well (without consuming a lot of energy and sliding in weird ways) This turning would likely prevent their use in larger vehicles even if a good set were put together. Turns would apply dangerous loads to your chassis and require a lot of power. There\'s some coding effort that\'s required to make a system that would angle it\'s track section level to the ground, but I think I know how to do it with a pair of wheel colliders, perhaps with a set of three. Because of the different sets of problems and the limit to vehicle scaling, I think this would be best as an independent modification of the cart plugin to make a treaded cart. If you meant like a train... It might be, but I honestly wouldn\'t know how to have the vehicle access pieces of the track, which might even belong to other vehicles. (This is a mod I\'d love to see, but I think difficulty-wise it might be right up there with 3rd party docking plugins.) That said, I\'m not convinced either is impossible. This can be done with the cart mod or with any of the nodes already though I\'d love to see someone write a revision of the source where that can be driven properly. I was able to coax it off the launchpad, but only just. Next time I understand the computation of drive direction I\'ll try to keep this in mind to enable proper control of this type of vehicle. I think it\'s just an issue of allowing the other directions to contribute to drive instruction (pitch, yaw, and translate up) by allowing them to contribute to the desired drive vectors, the wheels should then be able to drive properly... fingers crossed. Thinking more on the omni-wheels, they don\'t feel Kerbal, and I haven\'t really been able to draw any omniwheels with convincing suspensions or reasonable animations. I\'m happy I got the plugin to the point where it would support them because I feel that means it supports non-steering wheels, complex friction behavior and pretty much maximises the utility of the plugin, but I don\'t really want to maintain the part. I\'m going to add an archive folder and keep using them to test the plugin, in case anyone wants to build on it, but I\'m not going to maintain the part specifically.

I don\'t actually know how the center of mass is computed, but that wheel creep thing is a real pain. The wheel collider seems to remain well behaved, and I believe it accounts for the wheel mass. The raytrace to compute where to draw the wheel seems to be bad. I\'m pretty sure it would happen to Tosh\'s cart as well but I\'ll be damned if I know how to fix it. Y8, do you have a test case or instrumentation that exposes the center of mass problem? or after the wheels creep down do you just feel that something is wrong?

I look forward either to using these parts to stabilize docking targets, or using the source code to make a command system for that purpose. Keep up the good work.