karamazovnew

Definitely works better than the previous version. I'll leave a link here so all can see for themselves: https://github.com/Vivero/Kerbal-VR Well, the VR mod works in the VAB but is "real scale" and it's just for walking around, not building. I love building plane models so having a 2 meter high big rocket is what I'd go for myself. The stock cockpits look really nice in VR. I've gotten used to the real scale in IL-2 BoS or DCS. But these are a bit smaller, due to the size of a Kerbal. This mod has its flaws (no interface, only available in IVA and VAB/SPH, camera is not particularly smooth, a few graphical bugs) but it really nails in the idea that the stock game itself is fit for VR.

Howdy all. Seems like the download link is completely broken, and I wasn't smart enough to keep a backup. So I'm gonna start redoing the mod from scratch for 1.3.1. This time I'm gonna post all the code here, just in case I lose the files again. First step is ready, just a remake of the old RemoveStockFuelPrice.cfg file. This time I am doing it in a less aggressive way (probably safer as well). Feel free to test it, although it doesn't do much by itself (It actually makes all monoprop tanks cheaper, since I haven't yet remade the fuel prices). I haven't yet touched Xenon (as in the old mod, NearFuture mods will probably deal with Xenon). - RemoveStockFuelPrice.cfg code (click spoiler to see)

Awesome, thanks a ton Linux.

Ok, roger on that. By the way, I just realized how useful this mode can really be when I enabled Semisaturable Wheels's values directly in the menu (previously you had to click twice on his buttons to display them in a different interface), then disabled the button itself. Absolutely awesome.

Yeap, that's what I meant. A normal player would just select a name from a predefined list, sort of how tank fuel switchers or procedural parts textures work. I see how an ID is much easier, since iyou can reforce the renumbering of cameras in case the player uses 2 cameras with the same name. Can of worms really But consider this as a request for MAS. And speaking about MAS, I already see how to switch through multiple pages with the same button (ex, Navball, HSI). But in RPM you could make a huge tree of hierarchical screens with the CONTEXTREDIRECT method (ex, B9). Will that also be available in MAS?

Awesome. Wait, are we talking about the same thing? I just want a button that disables the "Customize PAW" entry from all parts (disables the module). Something sort of similar to this:https://forum.kerbalspaceprogram.com/index.php?/topic/149686-13-alshains-modlets-electric-lights-localizer-helper-advanced-tweakables-button-bulb/ But I am guessing that's not possible, is it? What about a different route... What if by pressing a toolbar button, you enter a special mode, similar to what KIS does when you hold the G key. As you know, in that mode, when you mouse over a part, it shows some info. When you click it, it does something to that part (disconnects it in this case). So instead of using a module added to all parts just to be able to select the part, you would: - make the module invisible in the menu. You'd still have it for each part, to be able to store your information, it just won't appear in the right click menu anymore. - instead of the "Customize PAW" entry, you press a toolbar button that now requires you to select a part. Pressing the button again would disable this mode. The KIS source should give you some inspiration. There were also other mods that used this feature, I think.. Crew Manifest? I could be wrong. - when you mouse-over the part, it can show you some information "No PAW items hidden" in green, "Some PAW items are hidden" in red would probably be the most useful and you'd be able to see at a glance while mousing over the craft. - when you click a part, the select mode stops and the PAW window is shown. It should already know which part it refers to, because you've given it that info through the click code. You can then proceed to enable or disable the needed entries as it's currently done. Having the mode as external would probably help you to save the data "per part". Anyway, I'm just suggesting. This mod has already saved me a lot of screen space and I wouldn't be here If i didn't like it Kudos and good luck.

Sorry, I didn't explain the problem correctly. The Paw menu works fine in EVA if I right click the Kerbal. But it doesn't appear when I right click another object, while in EVA. I was trying to get rid of the "Disassemble Part" menu entry that appears on every object due to the MKS mod. That one only appears during EVA. And call me crazy, but I'd rather we had this menu in the VAB as well. For example the kOS mod adds a "Rename item" entry to all parts. Actually wait, that would just replace the single kOS entry with the "Customize PAW" entry. Can you add a toolbar button (blizzy as well preferably) that when pressed (toggle) will show the "Customize PAW" entry? That would make the mod absolutely perfect (until you manage to do the "per part" thing, hehe).

@MOARdV Question 1: is it possible to create a camera that is recognized by other RPM screens (ASET, B9) as internal/landing cameras? I've noticed that ASET uses cameraTransform = ALCORExt_B_CamTransform|ALCORExt_A_CamTransform|ALCORExt_C_CamTransform|ALCORExt_D_CamTransform|ExtCam1 Meanwhile, RPM uses cameraIDPrefix = ExtCam in the camera cfg file, and then adds the camera ID through the object interface to get the ID and merge the name for its use: cameraTransform = ExtCam1|ExtCam2|ExtCam3|ExtCam4|ExtCam5|ExtCam6|ExtCam7|ExtCam8 Now, instead of doing that, can't you allow us to go through actual names directly, such as "Ext Cam1 -> Ext Cam 2 -> ALCORExt_B_CamTransform -> B9_something_camera" instead of going "ID 1,2,3,4,5" etc? Preferably the list would be drawn from a cfg file where we can add other camera names ourselves if needed? Question 2: I've never seen anyone use the Monochrome shader, and that's a really lost opportunity here. Currently, they have to be defined per screen, but why not do it per part? You'd need the following features (bear in mind I'm not a Kerbal programmer, so this is purely pseudo-code): - add a new variable to the JSI External Camera and docking port cameras MODULE { name = JSIExternalCameraSelector cameraContainer = RCSthruster rotateCamera = -90,0,0 cameraIDPrefix = ExtCam //this one wouldn't do anything anymore, actually //from the suggestion before: cameraIDs = ExtCam1,ExtCam2,ExtCam3, ALCORExt_B_CamTransform, Karamazov_really_weird_camera // now the new one RPMcustomCameras { EarlyBW { unlockTechs = flightControl } ModernCamera { unlockTechs = unmannedTech } KaramazovWasHERE {unlockTechs = start} } } - one library file, let's say "RPM_Custom_Camera_Shaders.cfg" that would look sort of like this: RPMCUSTOMCAMERA { name = earlyBW Description = MOARdv's BW Russian 1950s // all the rest from here are optional, any missing ones would be used directly from the MFD Screen config file rpmcustomshaders = BWheavyNoise (defined below) yawLimits =.... yawRate = ... yawLeft = .... yawRight = ..... pitchLimits = ..... pitchRate = ..... pitchUp = ...... pitchDown = ..... } RPMCUSTOMCAMERA { Name = ModernCamera Description = Camera with steering and NV rpmcustomshaders = ColorClean, BWClean, NightVisionBWLowGainLowNoise, NightVisionGREENHighGainHighNoise (all defined below) ...... } RPMCUSTOMCAMERA { Name = KaramazovWasHERE Description = Karamazov's new OP CANIKON telescope I just added myself .... } etc... you get the idea, Now for the shaderrs themselves: RPMCUSTOMSHADER { name = BWheavyNoise cameraEffectShader = .... cameraEffectVariables = .... cameraEffectTextures = .... } RPMCUSTOMSHADER { name = NightVisionGREENHighGainHighNoise cameraEffectShader = .... cameraEffectVariables = .... cameraEffectTextures = .... } etc. etc. This would allow you to create presets (at least to show us what's possible) and allow us to add more. The plugin would look at the camera's available shader/steer/zoom presets and if they're unlocked in the techtree, will show them to the Right click menu in the VAB/SPH (but not in flight, hehe) and allow us to select one of them. The first one should be "Default RPM camera" which would just be empty and look at the MFD40x20.cfg file. For the rest, once set, the plugin would load the settings in their definition, and fill up what's missing with the default values from the MFD40x20 file. - finally, assign a new task in the MFD40x20.cfg file to allow the user to scroll through the filters available for that model. Example: nextShader = 8, prevShader = 7 or whatever (I recommend the circle button anyway (and only nextShader is required, since cameras will not use 100 fulters) This would instantly allow us to create a mod with various cameras, ranging from old grainy black and white ones to new ones, and unlock them through the career. How does that sound? Possible? Doable? If done like this, it wouldn't affect any existing mod that uses RPM. They'd all work as they currently do, if the player chooses "Default RPM camera" and he'd have all current "ExtCam1, ExtCam2 etc." names available from the start. ASET and B9 would just have to add in a line in their screen configs to add in the new "nextShader, prevShader" function/buttons. EDIT: Finally done editing, I must've rewritten it 100 times

Still works fine in 1.3.1. But I have a request. Is it possible to add it to the EVA menu as well?

I've been trying the last release with 1.3.1 and I can't change the facility type for new objects. The window doesn't show any entries, and the log is spammed with: [EXC 05:22:15.794] NullReferenceException: Object reference not set to an instance of an object UnityEngine.GUI.DoTextField (Rect position, Int32 id, UnityEngine.GUIContent content, Boolean multiline, Int32 maxLength, UnityEngine.GUIStyle style, System.String secureText, Char maskChar) UnityEngine.GUI.DoTextField (Rect position, Int32 id, UnityEngine.GUIContent content, Boolean multiline, Int32 maxLength, UnityEngine.GUIStyle style, System.String secureText) UnityEngine.GUI.DoTextField (Rect position, Int32 id, UnityEngine.GUIContent content, Boolean multiline, Int32 maxLength, UnityEngine.GUIStyle style) UnityEngine.GUILayout.DoTextField (System.String text, Int32 maxLength, Boolean multiline, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) UnityEngine.GUILayout.TextField (System.String text, Int32 maxLength, UnityEngine.GUILayoutOption[] options) KerbalKonstructs.UI.FacilityEditor.drawFacilityEditorWindow (Int32 id) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [EXC 05:22:15.798] ArgumentException: Getting control 3's position in a group with only 3 controls when doing Repaint Aborting UnityEngine.GUILayoutGroup.GetNext () UnityEngine.GUILayoutUtility.DoGetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) UnityEngine.GUILayoutUtility.GetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) UnityEngine.GUILayout.DoBox (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) UnityEngine.GUILayout.Box (System.String text, UnityEngine.GUILayoutOption[] options) KerbalKonstructs.UI.FacilityEditor.drawFacilityEditorWindow (Int32 id) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)

@nightingale The buttons for toggling active/offered waypoints and orbits at the top of the Tracking station don't work for me. Clean install, only CC 1.23.3 installed. I can provide a log but there's no warnings or errors in it, the interface loads fine with: [LOG 19:22:58.316] [AddonLoader]: Instantiating addon 'TrackingStationUI' from assembly 'ContractConfigurator' [LOG 19:22:58.317] [AddonLoader]: Instantiating addon 'TitleTrackerHelper' from assembly 'ContractConfigurator'

Aye aye. I ended up stopping to use FAR anyway, since it didn't work at all with one of my other mods. Just wanted to add that the "extra blue-line no calculation" error mentioned above did occur again during one recent Mun landing. No idea what triggered it. If it happens again, I'll post a log file.

OMG, finally! Now I understand why the RCS rebalance wasn't working at all. The second part of the code in SETI-GeneralSetting.cfg is needed, just in case RWSaturable misses some parts that get a ModuleReactionWheel during SETI. SETI thus forces a recheck. The first part however shouldn't be there and it messes things up. Comment it out or delete it. Your file should look like this. Be careful though, that if you had the "SETIrebalanceReactionWheels" folder, RCS rebalance will now do its work and slash your torque. In my case, that's exactly what I was looking for. //------\\ //---Semi-Saturatable Reaction Wheels---\\ //------\\ //---Thank you, Rokanov //@PART[*]:HAS[@MODULE[RWSaturatable]]:NEEDS[RWSaturatable]:AFTER[RWSaturatable]:BEFORE[SETIrebalance] //{ // @MODULE[RWSaturatable],* // { // @name = ModuleReactionWheel // } //} @PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[RWSaturatable]]:NEEDS[RWSaturatable]:AFTER[SETIrebalance] { @MODULE[ModuleReactionWheel] { @name = RWSaturatable %saturationScale = 10 !bleedRate,* {} bleedRate { key = 0 0.025 0 0 key = 1 0.025 0 0 } !torqueCurve,* {} torqueCurve { key = 0 1 -1 -1 key = 1 0 -1 -1 } } } Alternatively, you could delete RWSaturable's RW config file, as then SETI wouldn't see any RWSaturable modules to begin with and the first part of that code wouldn't do anything.

You're not wrong. But that is already done by the existing framerworks. SteamVR SDK works with anything DirectX10. However, KSP is built on Unity 5.4 which already has VR. Heck, you can do your own game in VR if you want: https://www.youtube.com/watch?v=kIATVY0sXuU So, unless there's something really fishy between Unity and KSP, the devs could get it up and running within a week, if they're lazy. It's the other issues that I worry about, such as - how the interface is handled - how it affects existing mods and their way of handling the interface (hopefully, it shouldn't affect them at all) - how it can be used for gameplay - how bad it moves

Not only that, but too many people confuse the Oculus/Vive masterrace VR with the phone plastic bolt-on versions. The difference between the two, quality wise, is astronomical. Ok, I exagerrated, but I was just trying to make a point. In the early 80's, I'm guessing there were a lot of mail discussions about why not to put mouse controls in games, because nobody has a mouse, except those elitist Amstrad users (or whatever). Right now, VR is expensive mostly because you need a good PC. That's not something that's gonna change, even in 10 years, because the best VR of its day will always need a monster PC. But headsets themselves will get cheaper. Would you be willing to spend 300$ for a good VR? Well, right now Oculus sells at 399$, so it's not far. Right now we only have HD resolution, but once the 4K or 8K resolution headsets will come out, the HD ones might be quite cheap. And yes, I've seen a few folk not being able to use VR for long or at all, due to sickness. But those that didn't instantly puke, soon developed a resistance to it. I actually quite envy them. I miss that "oh my god! cold sweat on my back" moment when I first made my first loop in War Thunder, more than one year ago. The biggest problem VR now has is there aren't really that many proper games for it. I have enough to keep me busy and my face sweaty all day long, but I am looking forward to Fallout4 VR, because it will be the first mainstream game to take the plunge and offer a proper world. So there's a special room for Jeb and Co in this emerging VR market. And with the game already made, it only needs VR support to enter that market. I keep hearing this "niche" word, but I remind you that we have TrackIR support and that 6DOF controller thing (check the options screen). So these devs are not scared of attending to the niche.