Gavin786

I amended the above post with a test I did and result is a mixed bag, def not as big a difference as I had hoped. Question really becomes : does it genuinely not matter WHERE on a ship a reaction wheel is but it will act the same way, even if placed in really weird places it just doesnt matter(unlike RCS) ?

Engine gimbals are bound to the translation axis that are normally used for RCS. I used the U/D and L/R in this case as its bound to the analog stick on my flight controls but you can bind in your own designs to as you like. To bind a rotator to an axis there is a menu option on the top left 'action groups' and there are a number of options(added for breaking ground) to bind axes to the robotic controls. First thing I did when I started KSP was rebind all the controls so I have no idea what the "proper" control scheme is. I would hazard a guess that it is the IJKL. As far as returning to center goes, it is totally NOT obvious and I did even a video about this but there is an option there(very tiny) just under the bound control to change mode between relative and absolute. Grab yourself a magnifying glass and see if you can find it . Try changing to absolute and see if that helps. Gavin786

I am not sure about it as I said I need to run the numbers and test it out. Its subjective experience right now. I maybe aught not to have advertised it so strongly until I fully did the experiments. I did compare it by putting the same number of wheels at the center of the ship and there was a difference but this could be due to weight distribution rather than increased torq. Initially I place RCS(vernier) at the ends of the nacelles and that for sure 100% made a difference. It is a natural assumption that the reaction wheels obey the same laws of physics but if they dont then well... I recently made a air vehicle based upon a similar principal and I didnt get nearly as much of a torq advantage as I thought by replacing 1 large reaction wheel in the center by small ones on the thrusters.

Welcome Humans, Here I explain the secrets of how to construct gimbaled engines and maneuvering nacelles, which allow high performance in large craft. Here is an example of an otherwise unremarkable large craft with Gimbaled engines and Stabilizer/Maneuvering nacelles : 1. Gimbaled Engines These allow landing without RCS of any kind. In practice the gimbaled engines worked far better than I initially expected they would. They are superb for arresting horizontal velocity during descent and make RCS un-necessary, for a ship of this size it means no vernier engines and thence no oxidizer needed. I suspect that even with engines that possess their own gimbals disabling them and using something like this will have many use cases. Whole engine assembly is free to move on its own axis. There are 2 rotators at the back attached to the fuselage. The rotator connected directly to the fuselage controls the movement of the engine block as a whole and can rotate it though any angle. The rotator connected to next to that is part of the gimbal mechanism and is for the U/D(Y) translation. At the end furthest from the fuselage there is an octagonal strut. This is connected to the main body of the fuselage with 6 struts. This gives essential structural support to the whole assembly. Connected to this octagonal strut is another rotator. This has no motor and is free to rotate. It's function is part to impart stability to the assembly. The nuclear engines are connected to each other in the U/D(Y) translation axis with fixed struts as they will always maintain their relative position. Hinged struts connect the engines in the L/R(X) translation axis. This again is for stability of the assembly and to ensure the engines always retain their relative position. Otherwise each engine is connected to the assembly with a rotator which moves it in this axis. 2. Stabiliser Nacelles Example below of flying this ship 160t, handles like a fighter, and definitely a lot better than Imperial Cutter in Elite. *** Please watch video below on Reaction Wheel Performance where it has been tested - reaction wheel placement may not have such a big effect as it seems -- more testing is needed at this time -- it may be weight distribution and structural stability that gives the feel of higher performance than extended reaction wheels *** Experiments and Advice seems to show that reaction wheel placement does not work as one would expect and it does not matter where on the craft reaction wheels are placed. Results below are likely due to the weight balance of the craft/vs testing reaction wheels in center and not due to reaction wheel placement. I have demonstrated in below video. Other purpose of these stabilisers is to allow the craft to land by supporting the main body and preventing roll over as well as distributing weight. In this instance they may also be retracted for placement in the initial launch faring. For those who know, will and dare to do so the craft may be downloaded : https://kerbalx.com/gavin786/Excursion3-export Gavin786 Testing of Reaction Wheel Placement I decided to make a test of Reaction Wheel placement. Results are mixed bag. For this model there was only a 10%(Well within margin of error) difference in 360 deg turn time. Again it did seem the 2nd model was massively more stable than first where I couldnt line it up easily at all.

Well put your money where your mouth is. What is your solution to problem of building landers without being able to readily test them ? Next guy who is building the bridge you are about to drive across - lets hope he didn't have the same design philosophy.

Mods are not allowed on the console version of this game. I do not know how it is possible to get even past the most basic level of design and flight without some essential features which are not in stock. Most glaring one is the ability to test a craft by moving it directly to any orbit or position. Let us take for example a lander for Mun. Without this mod, every time the designer wishes to test an iteration of the design, it has to be packed onto a rocket, then flown to Mun, then deployed and tested. Does this not drive one nuts ? Quality craft just cant be created with this method of having to fly to Mun every time. Small refinements cant be readily made and tested, every time there is a full commitment to flying out there be it sandbox or career mode it matters not, it must be a terrible ball ache for those who are not members of the PC Master Race. Not being able to test a craft in the proper environment it was designed to operate in is a huge handicap. What about in-flight information, quickly see one's apoapsis and periapsis, the time to both, how much deltav a manouver node will use, horizontal and vertical velocities, and a myriad of other essential information all need Kerbal Engineer(or some other tool). Learning to land on Mun is not so easy on its own and certainly took me a few tries just to learn the skill, even though I split the manouver into 3 parts and was able to independently learn each one, suicide/landing burn, surface landing, and takeoff/reorbit. And that is AFTER I had to redesign the craft a few times so it could even land, not to mention the phase next of optimising performance.. Essential tools like Kerbal Engineer, calculations of TWR on various bodies. Thankfully DeltaV is stock now. Any type of precise adjustments to manouever nodes or parts in editor needs a 3rd party tool. RCS build aid, another great tool if you actually want your ship to be controllable on RCS. I have a system whereby I categorize mods. "White" mods are what I restrict myself to. White mods are informational or assist in the use of core functionality. They never do anything that would not allow a craft to fly and have full function in stock. Nor do they fundamentally alter gameplay by providing functions to automatically perform any flight operations which must be done manually in stock. Temporary parts or functions which allow testing of vehicles before they are deployed such as the move anywhere and NRAP test weights are included in my category as long as the line of not using these when in career mode on any deployed vehicle is adhered to(they are for design and testing purposes only). So I am discussing here mods which only augment core functionality/assist stock ship design, tools that by any sensible thinking really AUGHT to be in the stock game. I just dont know how people can build, test and fly without these things. Obviously there are exceptions and certain specific craft and categories can be built and deployed out of the box and there are certain exceptional people also who have internalized into their subconscious a lot of what is needed to build these things and can do it with pure intuition, but some people just need to see the numbers. Gavin786

Now I finally got the breaking ground parts to work(by disabling autostruts) I was able to build a really nice gimbol for this ship which dispenses with the need for RCS on planet landing. It works beautifully.

* HAVE NOW SOLVED THIS BUG(above, locking bug) It is caused by : AUTOSTRUTS Disable autostruts on any parts which are having this behavour. Its is a VERY frustrating bug as none of your designs will work right if you autostrut them! Gavin786 Try removing autostruts from the offending parts. I had exact same problem and it has solved it.

* HAVE NOW SOLVED THIS BUG It is caused by : AUTOSTRUTS Disable autostruts on any parts which are having this behavour. Its is a VERY frustrating bug as none of your designs will work right if you autostrut them! Gavin786

OK, I have not yet tested on the model above but I did get it working(and a much better version) with rotators. There were the same kind of problems and I have rooted out what it is : AUTOSTRUTS IF you are having any kind of problems with parts just not working as they should it would be my first suggestion is to switch autostruts off in your model, then enable part-by-part as needed. I use(as many ppl) Editor Extensions Redux and its just a matter of habit switching on rigid and struts for every part. HAVING PROBLEMS WITH BREAKING GROUND? CHECK THE AUTOSTRUTS! As ppl no doubt can tell I am actually really pleased with this discovery as up till now I have been bashing my head and not being able to create more than simple designs and even then having them not work correctly. For the above 32 passenger ship that can land on planets, I have now made a full gimbol system that allows me to fully dispense with RCS : * Just tested and got rid of autostruts in design in the video. Everything seems to be working perfect now!

I actually just found the control. It is on the Custom1 axis itself. It is a tiny graphical checkbox below the control. Very easy to miss! Thank you KerikBalm. I have been looking for a way to do this for days. Even made a video asking for help. That is going to be super useful in my builds. Gavin786

I actually just found the control. It is on the Custom1 axis itself. It is a tiny graphical checkbox below the control. Very easy to miss! Thank you KerikBalm. I have been looking for a way to do this for days. Even made a video asking for help. That is going to be super useful in my builds. Gavin786

I have searched high and low for a setting like that. Through the settings.cfg file with fine tooth comb. Where is it ?

Joystick Axis Bug:

This is what is happening, I have found it happens whether or not "Locked" is used. Very very bad bug, makes many designs that otherwise would be great not viable. This is a seriously miserable, game breaking bug and it needs attention soon as. Gavin786 * Problem has by trial and error solved : AUTOSTRUTS. Disable them if you are having similar problems!

Humans, be aware of this : The incredibly useful feature of locking does not work: One would wish to lock the position as it massively increases the stability of the joint. A joint that is flapping around suddenly becomes useful once "Locked" is applied. If "Locked" actually worked. Observe : This issue is useful for the other forum denizens to be aware of, such that I have reposted from the technical support forum.

I didnt see anyone do this yet. I know ion planes have been done but none that use no expendable propellant as far as I am aware. Here are some solar-only powered craft that can fly indefinitely during day hours. 1. Solar Propeller Plane Prop planes are a poodle because the solar panels create a lot of excess drag and planes that do work and fly really nicely become nasty to fly when stacked with solar panels. This does fly however. A launch vehicle is used to get it up to speed and off the ground as I eliminated the undercarriage to give it just a little bit more of a weight advantage. It is a nasty plane to fly but fly it does. 2. Solar Helicopter Loads easier as are all helicopters. And easy(once one learns how to fly helicopters). Nicer vehicle to fly than the plane for sure. Gavin786 * Steamworks is not behaving right now so I will upload the models when I can

This setup is a demonstrator and not practical to put on any real vehicle; the purpose is to show the technique. I was very impressed the the KSP physics engine allows this type of model to work. When set up correctly(on real vehicle) I got pretty sweet results with a loss of around 5% or so(per engine node). Loss is quite a bit higher on this model. To use it on a real vehicle what is important to know is : 1. Struts are vectors that go from source part to their destination, they are not linked to parts intrinsically. It is a pretty dumb implementation if you ask me but its how it works. So if you save a model and the struts look ok when you reload the might not be as they will choose the part that is in the vector not necessarily what you originally connected to. 2. Link all the parts to a parent part. Make sure you are using precise editor or something than allows quality work as tolerances to get this right are small. Do not use the support structure there shown with all the cubic octagonal struts. I will post a heliplane that uses the technique. Helicopters are perfect for demoing and testing this type of thing, I probably do an post on helicopter vs propeller blades sometime as they totally different beasts as I have done loads of experiments on it. TLDR: If you want to test anything like this do yourself a favour and make a helicopter not a plane. Energy is a square factor so to expect to get double the RPM with a perfect zero loss setup would require 4 engines, not 2. I do have figures to hand for this design. For the Dual Motors(4 in total) we got a thrust of 39KN. Engine weighed 781Kg, giving a excess thrust of 49.94 N/Kg For the Single Motor Setup(2 in total) we got a thrust of 21KN. Engine weighed 411Kg, giving excess thrust of 51.09 N/Kg So losses were pretty good as I measured it. Gavin786 * Steamworks is not behaving right now so I will upload the model when I can

Didnt get any traction on last bug I wrote about so made a video hopefully someone gonna watch and do something about it. It is nasty and stops a lot of designs from working because of the weak nature of the hinges and joints when they are unlocked(locking them makes them as strong as any part connection and it makes a big difference - only problem is it doesnt work properly because of a bug).

I have never advocated general purpose procedural parts. Just in certain very specific areas. I think we ALL agree that is a bad idea and not the way to go.There are just 2 areas I think it would be great which is in FUEL/OX ration which has been universally agreed by everyone to be a good idea, the other is conncetors which we have a whole bunch and many types are missing.

Maybe at one point in time they said that. Times change. Now they have a competitor who is doing exactly that and succeeding very well. Only a matter of time before they start taking coin from SQUAD's pocket. That tends to change people's thinking quite a lot. It is easier to use than KSP in many regards and the reason KSP's whole motive for the "Lego" approach is to make KSP more accessible to people. They have already went much farther than lego with breaking ground. Editors control points etc. Folks who have never used animation software will scratch their heads at that to be sure. It is in no way intuitive how controllers, action groups etc fit together. Times must change. And we dont need general purpose procedural parts. That is not the way to go for KSP. How KSP is done is fundamentally very nice and the general "Lego" like approach works well. But there are some situations it needs to change. And it is ridiculous having a huge amount of duplication and redundancy. That actually makes things harder not easier. Gavin786

Let us take this aircraft as an example. It is very difficult to fly. In fact it would not be possible at all without the power curve shown above. I need to take the data from that and make a set of written instructions for myself as to what to do at what altitude. This graph shows how much excess energy(in practice acceleration) the craft will have at different heights and speeds. Basically this graph can be divided into two areas. There is the spike on the left that peaks out at about 12000m and 250ms, and the other which peaks(for my purposes) at about 14000 m and 16000ms. Now there are two ascent curves that one can fly. One will get you to 12000m at 250ms and the other will get me to the 1600ms at 14000(which I can then use to get to orbit). And to get to that second ascent curve is not easy, there is only a very narrow window that will get you there. it is important to keep low, under 1000m actually before one gets to 450 or so ms at which point there starts to be a lot of excess thrust and once can begin the climb inside that red/yellow area where the aircraft has the maximum excess thrust(accelleration) to get nicely and easily to required speed. Now without this software and without this graph, I would posit that it would be at minimum a serious pita to get the correct flight profile to get to speed. In fact most likely people would give up as its a counter intuitive profile. Getting to speed of 500ms at under 1000m is generally not the done thing. Now if one just creates purely OP craft I agree probably one could just dispense with this tool. I like to create craft that push the envelope one way or another and this allows me to do that and see how it will perform at all altitudes and speeds without having to actually go out and fly the craft. And more than that it allows me to find out a lot about how my aircraft will perform that I would never have found out otherwise. It also shows me the maximum (14000m) height I need to keep and not to go higher so I can get to speed. This craft will actually go to 32000m still using the air breathing engines and have a speed still of about 1300ms+ that allows me easily to power to orbit. It does not mean the graph is wrong, it means it is correct. The graph shows me the perfect place to begin my ascent to try and transform that horizontal velocity into vertical velocity to get as high as I can to power to orbit. Why I call this an essential tool. Gavin786

I never saw wind tunnel present a max speed. It shows excess thrust at various speeds and altitudes. Its about excess thrust primarily(main display anyway), which is related to acceleration and not top speed. For example you fly high and you have an aircraft with low drag, you then point nose down, you may very well get upto higher speed than the positive excess thrust(greyed area on the graph) but you wont be able to accelerate or maintain that speed at horizontal flying as there will be a negative excess thrust and you will lose energy until you get to the speed indicated at which you have 0 excess thrust. The other thing wind tunnel shows often is dual humb backed or strangely shaped flight profile. Have you ever noticed that you are at a low speed and you just cant climb above a certain altitude, but sometimes you can ? That is about the flight envelope of your craft and that wind tunnel shows you. Often you can get into "traps" in the flight envelope where you just cant go any faster BUT if you went to a lower altitude, then accelerated you could break the "barrier" at which your thrust increases and you can get upto those speeds and heights. Wind tunnel shows you exactly where these areas are and how you need to fly to get the best performance out of your craft. I maybe post example of that later to show what I mean or maybe someone else can. Its important information I think for most aircraft designers.

I actually think this thread should be in "Technical Support" as its clearly a bug IMHO and one that needs fixed and is super easy to to fix too literally 5 mins.

I think maybe im not being clear what problem is. Basically axis works as a weird relative axis. There is no mapping between axis position and set value. It is not anything to do with response curves, discussing that seems to be going of topic, we can start another thread to talk about it. The problem is : Above axis midpoint its equivalent to pressing the "increment axis" button on the keyboard. Below axis midpoint its equivalent to pressing the "decrement axis" button on the keyboard. I am pretty certain this is a bug or a glaring design error if its intentional behaviour. For the sake of simplicity lets just assume a linear curve as its difficult to understand otherwise. It should be : Physical axis set to 10% it is 10% of value on game axis; Physical axis set to 20% it is 20% of value on game axis; Physical axis set to 30% it is 30% of value on game axis; etc etc. That is NOT happening, it only considers the midpoint of the axis and maps this to an increment or decrement function. Gavin786