kitoban

Sorry there blizzy, although the sliding code has been about as a stand alone mod from xEvilReaperx for a while, I just got permission to incorporate here. Jan that I doubt the issues you are describing have anything to do with this mod. The mod just applies extra markers to the navball based on the orientation of the ship, (math is courtesy of mechjeb) There is no feedback into the control of the ship. Rolling on turn can be attributed to certain ship designs so I would recommend investigating there.

Why's that? I've made sure this is toolbar compatible, although can run without.

Done, should be up on curse v1.3.1

Ok it is now live

Just spotted this myself, it is currently under review on curse at the moment so should be available shortly.

Sorry for the delay, release has just gone live

If you are after the sliding functionality it is already available. I am just combining this in. (With permission) Scaling I am still working on as some of the new 23.5 functionality doesn't scale atm. Plus still need to get the option menu working for toolbar Plugin.

kujuman, will take a look, is the second pull request I've had in the last few days, things always seem to line up at the worst time I am currently moving house so as soon as main PC is up and running I'll take a look. I have been refactoring the code to clean it up for configuration options so hopefully this will allow for any customisation of the feature. This is where I am currently with some of the customisation, it's working here with both xEvilReeperx's sliding code, and some scaling I have been implementing.

Already been talking to xEvilReeperx over this and will be incorporating this. Target ghosting is something I have wanted to add in, just need to work out the calculations and wanted to be sure this isn't going to be intrusive.

Tested this last night and I found it has worked fine in 23.5, will get the title updated.

Enhanced Navball tested fine last night. I've not had any reported issues on this.

Thanks for the message of appreciation, makes the trouble I had creating the mod worthwhile I will say I haven't forgotten about the mod and have been putting in work on the extra feature that have been requested, I've just been going through an extended house move which has been tacking up my time to work on getting the features added in, but they are coming. As far as Meltafire's request: I can look into this, but as this is a process of overridding the control of the navball orientation it might result in an argument between the mod code and the core code, which might be problematic.

Can say I like the idea of where this is going will definitely be keeping an eye on it. One thing that comes to mind on this (not sure if it has been mentioned already) is for the ability to transfer ownership of a mod. There has been a number of cases where someone has picked things up off another modder and I would imagine all the statistics that go with the mod management would be useful to the new owner.

Distortion is down to the 3D nature of the navball UI if you were to see it side on: o x | <--- View o = Navball itself x = markers that are visible projected on a 2d plane | = outer widgets So distortion around the edge is actually you viewing the navball texture wrapped round the sphere of the navball at an oblique angle. As far as magnification goes is a suggestion I have heard mentioned before, but given the nature of craft controls the only time I would imagine the need/opportunity to be this exact would be on a docking procedure, any other time most people seem to stay as near as possible but that is normally at best a certain amount of tolerance. Other than docking can you think of a use case where you need to be precise on the node itself? Docking navball options were something I left off as I had yet to work out the exact guidance that would be considered useful without overbearing (as well as the calculations behind it), I was in discussion with Navyfish about implementing the dock align indicator on to the navball itself, something that Mic_e ended up completing with navball docking alignment indicator while I was busy IRL. While docking I could see a magnification of the alignment node once you start to have all the relevant indicators lined up would be very useful, but could imagine it being annoyingly distracting during a launch or plane landing.

You've hit exactly what I was thinking when I developed the mod: The markers are only visible when it becomes confusing about where off the side they are, the exception to this is the maneuver node which I set to have a ghost any time the node is not visible on the navball, which was partly down to non-familiarity with the anti-maneuver node icon (which were implemented in the same way that they are within the cockpit) and partly due to the fact that you are rarely interested in the anti-maneuver node, whereas the Prograde and Retrograde are used more evenly. As far as how this is represented is up for debate, I decided on using the same icons as these were available and required no extra resource load and people are already familiar with these, but these could arguably be represented in whatever form you wanted.

How often would you want to burn tangential to the vector when the ghosting is present, the ghosting is only present when it is difficult to identify when the prograde and retrograde are visible, or when using a maneuver node, in which case you actually are wanting a specific direction so you would be turning towards it. The aim when developing the navball mod was simply to inform without over cluttering, which I would feel is the danger posed by having too much on the navball at a time. You need the information it provides to be quickly digestible in order to make quick decision about your piloting.

I never seem to have to recommend the mod, other people are always doing this for me Thanks 5thHorseman

Thanks cryptk, have updated the post to reflect this

I posted this over on Reddit and thought it was relevant here as well. The biggest issue I can see with multiplayer is that as much as I like the idea of co-operative gameplay what does this add to the game? Multiplayer objective Beyond simply launching a rocket with a firend and building a space station, what is the ultimate point? You can land as a team on another planet, having someone control the rcs, while another is concentrating on the throttle (maybe this is speculation based on the tweakable sharing they mentioned) Or maybe you could send a rescue for a friend who has low fuel around a planet. Although at the point of finding out you had low fuel you need could do this yourself, as there would be nothing for you to do waiting for a rescue. Resources objective Opens up the world beyond the spawn area that is the starting point. You can create your vehicle, plan you mission land in a shallow gravity well and build infrastructure to support further missions from a new "Spawn location" Create new ships possibly and launch from there. Possibly true orbital construction where you are not having to launch behemoths or dock strange structures together. which can lead to docking rubbery interplanetary ships. Maybe this was turning boring in the Dev's opinions, however they have had it proved time and again that people do things they never considered in the game, a great example of that was Scott Manley and Abyssal Lurkers section doing crazy things that the devs never expected. I think given the chance the player base could do wonders with resources built into the game Summary I think overall the point I am trying to get at is multiplayer sounds like a nice addition to the game but beyond the initial "lets dock in orbit" there is not a great deal that you can really do. An analogy here would be thing of minecraft where you had to pick everything in your inventory when you first spawn into the world, and that spawn point was static. What I would love to see would be both resources and multiplayer, as resources would be a hard feature of the game and take some building up to, therefore would take a lot of skill to build into however if you had a multiplayer there would be those skilled players there to help the newer players out and start spreading within the solar system. Without resources multiplayer is a nice gimmick, but is still a gimmick that is going to be limited by having a static entry into the KSP world. Personally if resources are truely shelved/cancelled for good, I'll be looking into Kethane a lot more, and hope that the Dev's behind it are not too frustrated that they essentially have been putting any further development of this on hold since 0.19 as it was looking like Kethane was going to become obsolete.

Forking it should be fine I think I can do a pull request to get the code into the main branch, will take a look when I have a chance. Adding the UI switches is something I will need to get the navball custmisation (high contrast etc.)

evilC - the core of the calculations are in here: https://github.com/kitoban/EnhancedNavBall/blob/master/EnhancedNavBall/CalculationStore.cs which is mostly sourced from mechjebs calculations for radial+/- etc, so afraid I do not completely understand how they work (in particular what Vector3d.Exclude does) I can only follow the calculations so far... However I have put some further thought into this and think that the radial calculations are incorrect for VTOL purposes as it is reliant on the orientation of the ship, would need to do some part interrogation to determine the up direction according to the capsule (up being above the cockpit as opposed to forward being in front of the craft), which gets tricky when you are also having to calculate for the spaceships as up gets confused with forward... I think it is likely to be this: Vector3d radialPlus = Vector3d.Exclude(velocityVesselOrbit, up).normalized; with velocityVesselOrbit swapped with the orientation of the cockpit to give you what you need, feel free to branch this off and add it in, I can then look to pulling this back into the project (with credits ofc ) Umlüx - Thanks, yeah I have certainly seen interest in the mod increase since scott started using it in the Interstellar series. Development has slowed (as seen above with evilC) but the RL commitments look like they are starting to fall into place which should free up some time to do some further development.

evilC - Makes sense about avoiding the sticking out part, thanks for the reference material that stuff looks really useful, the code is available on github if you do want take a look at recompiling it, I imagine it is a simple matter of applying the calculation for the radial vectors onto the surface vectors in order to get the points. Afraid to say I've just not had any free time to do much more than keeping an eye out for issues. RoboRay - yes I would imagine this would reset the reference point point on the craft, however you would lose the navigation marks on the IVA as the IVA navball does not link to the one in normal view.

Think I follow what you are asking here, but would it not be simpler to mount a probe body orientated in the direction you want to see on the navball and use "control from here"?

Nice work there mic_e! Will have to take that off my list of requested features looks like works in the way I had considered doing in when I got to it. Had a bit of a lull in my coding as things go busy IRL glad to see someone has picked this up. Pretty much sums things up, I still have the experimentation code from earlier guess work where I had indicators flying all over the screen. Took a number of frustrating evenings till I found the right variables to hook into to get the results I wanted.

It looks like the Z position on the speed reference got changed. All the elements of the navball UI are actually in a row along the Z axis, which you view from a dedicated camera. Is interesting that that element got moved. The currentlt code doesn't interact with these elements, but your right it might make it clearer on docking approach to his elements you don't need, i.e. heading, although you do still need the speed represented in some way.