evilC

Boss called in sick today, so looks like not much for me to do. Plugged in my G27, having a play now. I think I have replicated the issue, but only very briefly. Whatever, looking at the way axis merging is working, I am not happy with it - it is too confusing. To set up axis merging correctly, currently both pedals need to move the slider in the same direction. If you want to invert the result, you need to invert both axes. I think it would be better if you set up the left pedal axis to move the slider left (from a resting position of full right), and the right pedal to move it's slider right. Once you have that set up, set them both to the same virt axis and enable merge, and it should be the right way around. I think this will make the maths for merge mode simpler too - if the axes are set up like I mentioned, then you just need to average the two inputs to come up with the output.

There are benefits of using UJR in addition to or instead of the manufacturer's software. 1) Your CH software will only let you do stuff with your CH stick. If you want to merge your CH stick with TM pedals into one stick, I doubt it would do that. 2) Normal windows sticks generally need to be plugged in before a game is started, a virtual stick does not, as the virtual stick is always "plugged in". This means that if you decide to use a stick with a game, you can just plug it in, (tab out to UJR to config it if you need) and then play. Also, if you decide you do not like that stick for that game, but have another profile in UJR that maps a different physical stick to the same virtual stick, you can swap sticks without having to remap stuff in the game! 3) Functions. Never seen manufacturer software that can merge axes for example. TM TARGET may be able to do it, but I would not be surprised if you needed all TM kit to do it.

First up, regarding donations, they are especially welcome at the moment because we have a fundraiser going to pay for signing of the vJoy driver so that Test Mode is no longer required. Black Talon - I will redirect yours to that fund, thank-you. Now on to your issue. A couple of questions: 1) When this kick happens, do you see anything in the game controllers window (Start -> joy.cpl, double click vjoy controller). If you cannot normally see it, could you try playing KSP in windowed mode with it (And ideally UJR) visible? What do those apps display during the "kick"? 2) Are you 100% sure it is not your pedals? I have a cheap stick that does a similar thing, but it is due to dodgy potentiometers. 3) It does sound like it may well be to do with the axis merging code. To be honest, I have never used it myself much in anger. Any info you could give me to help replicate could help. What kind of pedals are they? I have G27 pedals. If different, could you tell me which way they idle (At 0? 100?), do you need to use invert etc? 4) Finally, I could probably knock up some test code to only handle the pedal merging, which would make debugging much easier. Do you know any coding? What UJR is doing is really rather simple - axis are read in as 0-100 values, and are output as 0-32767 values, so a simple in-> out would be multiplying by 327.67. If you are at all comfortable with coding, I could maybe knock up some test code and between us we could hack away at it until it does the job properly. Hope this helps.

FYI, there has been a major new release of this app since I last posted. It should now be significantly easier to map the virtual stick to ingame functions - no more tabbing out is required, it can all now be done from ingame.

I started having a fiddle with this today, but it seems that you did not carry over the window class from TACLib. Do you have any plans for including UI into the examples? Specifically I would love to see an example of how to do a partless plugin with an icon that brings up a GUI.

I uploaded my replacement DLL here. Existing functionality should not be affected.

I just got the Enhanced Navball mod working with a VTOL mode so you can insert a copy of the retrograde marker at 90 degrees to the real one. Useful in trying to come into land with a forward-facing VTOL craft. Currently not in the main download, but I submitted the changes to GitHub, so you can build it if you want, or I am sure we will have a DLL for you to play with soon. Also, am potentially looking into taking KCA and improving the UI. I need a way to save settings cause re-configuring KCA each time I launch is annoying. If you are not doing any development at the moment, maybe now would be a good time to fork?

OK, I think I did it. VTOL mode prototype submitted to GitHub! (For use with craft that have a VTOL engine perpendicular to the forward direction - think harrier jump jet) I don't think I have permissions to contribute to that project, so I forked. I added you as a contributor, so if you like we can play on this fork without fear of messing up yours. How it currently works: (Tested in Surface mode only at the moment) The Blue (Sky) prograde marker should be visible as you ascend. Keeping your heading indicator (-v-) inside the blue prograde will ensure you burn prograde. The Green (Grass) retrograde marker should be visible as you descend. If coming in from orbit, keep your heading indicator inside the retrograde marker as you burn to ensure you only slow down and do not deviate course. Can also be used to help correct deviation. Note that to move the pro/retrograde marker left/right, ROLL in the direction you wish to move it, NOT yaw! You are correcting sideways slip, you need to roll as your controls are plane style not rocket style! eg if you have the same pitch as the retro marker, but it is to your left, you are slipping left - roll right so some of your down burn corrects your left slip. Some comments: Seems to work pretty much as I envisioned. I certainly had a lot more survivable landings with my VTOL tests than I did before - makes KCA so much more useful! What would also be nice to to change the retrograde marker scale depending on speed. So for example the marker is small when you have no speed (soft landing) and big when you have lots of speed. Any ideas on how to do that would be appreciated. I guess this mod may be a candidate for trying out Taranis' new examples - make it a partless plugin, add an icon and a settings menu so you can turn on/off VTOL mode. That way my code can sit in the main codebase and not bother regular users.

No further progress yet, but I think I know what I need. My current code: Vector3d offsetProgradeSurface = velocityVesselSurfaceUnit; I need to rotate that by 90 degrees. Previously linked sample was for rotating a Quaternion, this is a Vector3d

Woohoo! Progress! I managed to insert a dupe of the prograde marker, so now I just have to figure out how to rotate it, and I think I may be golden.

OK, I built the project and had a play, and it seems that I have been maybe confusing you slightly because I was not aware of exactly what this mod did. I see now that the "Ghost Prograde" feature is for when prograde is not visible - it creates a ghost to show you the direction that prograde is in. This is not the kind of functionality that I require. What I need is to make a duplicate of the retrograde marker, and place it at 90 degrees to where the actual retrograde marker is, regardless of whether it is visible or not. The "ghost" functionality to make it easier to find is gravy. So I guess what I need to do is look at the anti-node / radial injection routines and duplicate those...

Hmm, not sure enough on how it all works to be sure, but surely it is not radial that I am interested in? I want to rotate a ghosted retrograde marker such that if you were in a forward-facing (plane style) vehicle, and were falling to earth (but not flying forwards, just dropping like a rock) then if you were leveled on the horizon, the retrograde marker would be inside the orientation indicator (-v-). I think I maybe see what you are getting at - the ghost indicator might be at the right place on the y axis (ie angle of attack) but it may be pointing at some random place on the x axis (heading). Is this why you are saying to mess with the radial? Whatever - I presume the variable that I am interested in is "ProgradeOrbit". Gonna maybe see if I can dig out VS again and have a play.

Skykooler does EL. AFAIK that has no such issues - it was OC that had the horrific teleport hack. Not sure who wrote that, but seeing as a better technique still has not been found, I guess we can't criticize too much eh? I seem to remember that a couple of the more knowledgeable coders had ideas of how to do it differently, but I never really understood the mechanisms (rails etc) to appreciate what they were saying. If you haven't asked around in the dev channel on IRC, I recommend doing so... I love the idea of science, but the implementation leaves me a little cold - too much working out what experiments are available where, and then too much clicking while you are trying to fly. I am hoping that something like the R&D overview mod can solve these issues though, but I think the dev doesn't know how to work out the available science. I think if KSP were more accessible as a casual game then I would play more - I normally have an hour or two to spare, so I would like to be able to fire up KSP, use a tool like R&D to plan experiments, build ship, fly mission, experiments triggered automatically, land, return trip, done. As it stands I spend way too much time trying to work out what experiments have been done in what biomes on what planet etc. Also, holding off on diving in more until mission cost is implemented. I spent so much of my previous playtime on spaceplanes that I would like to be able to put it into practice to save costs.

I am afraid vector maths and such is not my thing, hence why I tended to do UI and such on projects. I did have a cursory look at the code, but I could not work out where the bit I needed to change was. If you could identify the bit of code (and ideally the variable) that I was interested in, then I could possibly work it out, but I think stabbing away in the dark would be a bit of a waste of time.

Hey all, been AWOL a bit for a while, back playing a bit of career mode casually and stumbled across this thread. Glad to hear someone is finally trying to solve the big problem I had with OC that was stopping me doing the overhaul I so wanted to do - pretty much the exact same list of goals you listed... Obviously my code was open source, so feel free to nick any parts of OC or EL that I wrote that interest you, but I doubt it, it was a bit of a mess Wishing you all the best

Yes, but it ruins the immersion and means you have to have a silly bit sticking out of your ship, plus in career mode, all you have are pods etc. I would imagine it would be a trivial change, the only real issue I suppose is that you have no GUI to configure stuff. A setting in an INI file would be fine, hell I can even compile myself if you tell me what bit of code to edit. I can maybe help you out if UI and saving of settings are not things you know how to do, but it has been a while. Probably the best staring point there is Taranis Elsu's project here. That is based on a project of mine (which was based a project of his), so I should know how to implement a UI using that system, but the whole point of it was to let mod writers get on with writing the mod itself, and not working out how to hook into KSPs UI and settings and such, so you should be able to work it out...

Could you please add the ability to ghost prograde and retrograde by 90 degrees? If you are piloting a craft in VTOL mode (-v- on navball is forwards, but VTOL engines are pointing downwards, where the v is pointing) then something like this would totally make it flyable. As it is, the KCA mod is great, but overly difficult to land.

I have just started playing KSP again, and I like the science aspect, but keeping track of it all is putting me right off. I like this mod, but I feel that it needs to be taken further - basically what is needed to make KSP open to more casual play is a graphical representation of how much science is available for each experiment at each planet, broken down into the various biomes / altitudes. So for example, at a glance I can tell that for the Mun, I have full available science for the "Sensor Array Computing Nose Cone" at all altitudes in the polar regions, but very little other science available. I can understand that this may be more complex - I guess you would need to parse all parts for available experiments, and all planets for available biomes / atmosphere heights etc - but in reality it is just data processing. The biggest challenge would probably be the UI. Some ideas on where this mod could be taken: 1) Auto-science For a mission allow the user to pre-plan which experiments will be performed where. When the craft is in the appropriate place, automatically trigger the experiments. No more trying to perform experiments while also trying to land! I guess this would require hitting a button that scans the craft and detects which experiments are on it, then presenting a UI that allows you to pick which experiments will be performed where. 2) Research Planning. Given that a user had done the setup for (1) without launching a craft, allow them to say "This will happen on day X". Then Mark that research in the log as "Pending" and maybe adjust the progress bars in the research log. Optionally maybe put it in a calendar? To help you plan around launch windows? 3) Assist in craft design and maximizing science return for weight Some sort of functionality to help you work out the best return for a given weight, or what weight would be needed to max out research for a given planet. 4) Launch window planner. Hook into someone else's launch window mod to find optimal times to reach bodies. Place a column in the research log of time to launch window and let users order by that column. 5) Update research log with unreturned experiments. If you want max return from experiments, you bring them back. However, AFAIK the game does not register experiments currently held on craft but not yet returned. This may involve saving some of your mod's data in a per-savegame file (Totally possible IIRC), and may involve sync issues (What if craft is destroyed or experiment falls off on landing?) but probably solvable I think. Anyway, enough of the wish list. If you need help, I can totally recommend the ksb devs IRC channel, there are lots of helpful guys in there. All the best...

H,, I thought I nailed that bug, sorry. it should create it on startup. Do you have the latest version? Anyway, Here is a sample TacWindowTest.cfg: MyWindow { visible = True x = 1475 y = 68 width = 400 height = 256 showonstartup = True }

I just re-added icon.cs to the project also. I don't think it being missing was causing any of the problems though

Hmm, OK, the TacLib project was set to 4.5 [Edit] When I changed project to 3.5, I had to remove the reference to Microsoft-CSharp and comment out the line "using System.Threading.Tasks" The project compiled after I did that, so I guess all is good. I submitted changes to GitHub

I think i goofed anyway. It seems there is an icon.cs in there, but it is not part of the solution. Also, there is a resize.psd, but it looks like the code should be able to hold a missing icon. I saw taranis made some changes in that area, I may need to merge them in. When I find a bit of time i will have a look at it.

Whilst I understand that the main aim of the mod is for sub-orbital VTOLs, I think that for the work involved (Which I perceive to be low, please correct me if I am wrong), allowing any engine to function as an RCS thruster opens so many doors that it would be reticent not to do it. If it really is a quick job, then this allows sub-orbital users to not need to mount main engines at a slant (or include an extra RCS system), plus allows both the sub-orbital and orbital users to perform rotation independent of translation. Plus, surely it could allow VTOL craft to be more efficient. If you need to maintain a hover, and perform a rotation, not all of the power of the main engines can be devoted to lift. Sounds like a win/win to me...

Thanks for clearing that up. I suppose that is one solution, but then you have to go down the path of making a part... It sounds much simpler to me to use the system you already use to attach the menu to mechjeb/pods to attach a button to each engine that sets it as an RCS thruster. Same effect as what you propose, but should be a lot quicker to implement. Surely even with gimbal support, you would need this, as unless you had 90deg gimbal main engines, you could not change attitude without applying translation in a direction you did not want to?

With the new VTOL balancing mod from ZRM, the B9 VTOL engines get a new lease of life, but they could do with some work... As it stands, the engines pivot about the point of thrust, which works fine if the engines are mounted horizontally. However, that is not the "smart" way to align them. If you mount horizontally, you can thrust down, up or prograde. Well down and prograde are useful, but up is pretty useless. If you mount the engines vertically, you could burn down, prograde or retrograde - much more useful! However, if you mount the engines vertically, the pivot point being offset from the attach point makes it cumbersome to line up the engines such that a prograde burn is in line with the CoM. Any chance we could move the pivot point to where the attach point is?