The latest update features my first effort at rotation stabilization. 

Of course in spaysmode (object placer mode) unity friction is used (as is probably the most common form of stabilization in games, it is what I have seen in every example that I can recall for space games) ... However while using the thrust physics mode (the drones) there has previously been no real plans to include rotation stabilization as I personally do not have intent to use it. 

However, I did desire to have it as a feature, but only if it used thrust just as the player did. I first imagined that I would probably need some form of PID controller,, but it turns out this is not the real hurtle with unity,, there's a bunch of reasons why most of the ways that the developer can interact with rotation in unity are not properly "user friendly" when it comes to using a PID controller for rotation stabilization. Presently,, there is NOT a pid controller, but I did find a way to interact with unity using thrust and a feedback loop,, so the present stabilization is basically a simple P only controller. I have basically 3 vehicles, although the mass of the small and normal drone is different, and also, I don't really know about PID's well enough to simply program them,,, so I have basically decided that by now, PID's are the ONLY thing I need to worry about to start including them,, so at this point it's just a matter of me figuring out the PID controller, and no longer do I need to figure out how to use one with unity. My grand objective would be to have a set of suggestions for PID's based on various power levels, and then a "drone-esque" player tuneable section,, with the future potential of some other robotics-esque features as I find that I might be able to figure them out,, but in the near term I will try to learn how to make a capable, smooth stabilization system with some degree of player tuneable settings to go along with the player settable power levels. (( the player may want a more gentle stabilization if they will crank the power levels )) .. 

additionally, I have made some changes to the hoops,, still in an effort to improve their ability to register the correct direction once the player is moving so fast that the frames do not actually ever have the drone in the hoop. (if the physics engine calculates the drone to be moving fast enough that from one frame to the next it actually move all the way past the hoop,, then it is possible or even likely that it will do one of two things,,, either it will not even know the player moved through the hoop,, or it will think the player moved through it the wrong direction) ... In addition to this so far appearing to be more robust at higher velocities (I have no idea how fast players might want to move,, but ideally I would have no actual limit to the games ability to process it) ,, further it does appear that it leads to the potential that I can expand on this new solution to accommodate even higher velocities.  ,,, specifically rather than a single direction check mesh on each side, there are now 3, and I can increase this number and space  them out in a sort of "tuning". The issue appears to be that if I make the direction check field too large, then the playership will be rendered fully inside of the mesh, and the mesh will only trigger (register contact) if the playership is on the SKIN of the mesh.  ,, So in order to fill a larger area with trigger skin (basically),, I tied several objects to each direction check mesh so that if it hits ANY of them,, the direction check mesh will then be triggered. Presently I have not had to worry about adding additional "hoop" triggers, because I simply made the playership have an invisible object that was much longer than the ship, so that it was less likely to not hit,, but the result of this was that it became possible for the ship to render all the way into BOTH directions at the same moment. 

There may be some "stability" issues that arise from the ship being artificially longer AND the hoops being artificially longer if hte player wishes to place many of them into tight configurations,, because it may be possible for the player to trigger direction check meshes even without actually moving through them,, so it maybe become necessary to split the game into two hoopsets,, high speed and low speed, or perhaps it will be possible to somehow have the hoops track the player speed so that the additional space occupied only "feels" for the player if the playership is actually moving with enough velocity to risk skipping them. For now, I have not experienced (or experimented enough) any of these issues,, so I haven't really decided what to do next.. Usually I wait until the problem actually arises.