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.

No fatal errors, everything seems to work, apart from the WIP funds, when it comes to Stage Recovery. But recovering your active vessel works as advertised, you get 0 funds from parts, but funds from resources. I love the idea and hope to see it developed. The big issue I see is that there is some sort of stuttering in the VAB whenever clicking on a part, or moving it. It doesn't matter if the inventory screen is open or not. There is nothing visible in the logs, but the first freeze seems to coincide with the moment the Inventory screen updates its title. Also, I hope you'll read this post I made on Dangit's thread: The core values of Dangit, when applied as a dummy lifetime counter to all parts, could serve as a cool framework for Scrapyard's sell values or limit on how many times a part can be used (instead of a max number of reuses).

To be perfectly honest, I don't know what I want exactly, apart from the end result. Scrapyard isn't even done yet, and I don't know how it will work with Stage Recovery, or if it will replace it completely. But here's how such a scenario could look like: - Vessel hits the ground, either through FMRS or Stage Recovery, or normal manual flight. - Stockyard asks the player if he wants to recover the vessel or just the Pilots/Science. If he recovers the vessel... - Dangit reads the impact speed and looks at Stage Recovery's Variable Rate model values. Let's say that the player impacted with speed which would've cost him 50% of the part's value. Let's say he impacted in the water. Dangit would decide to lower the part's reliability based on these values. - Instead of repaying money for the part, Stage Recovery now subtracts money based on how far the vessel landed from KSC and passes the parts to Stockyard's inventory. It then repays the value of any resources found on the craft (fuel, ores, etc) - While in the Stockyard, all parts are inspected automatically by Dang-It, giving the "inspected" bonus for the next launch and showing faults or reliability. But... - Stockyard won't allow the player to use a part if It has a fault. Must repair it first through Dangit's logic and choice for complexity/durability gain etc. It has not yet been maintained, again Dangit's logic. Dangit decided for whatever reason that the part is too old and must be scrapped (even if that part is say a structural part which can't normally fail during flight). Engineers brake the part by accident while trying to repair it (oops). - Allow player to execute a more complex maintenance, which costs more but increases reliability even more for the next flight. - Give Stockyard info about the maintenance complexity, so that it can decide how much using that part will reduce Construction Time and cost. - Optionally, read Stockyard's value of how many times that part has been used, to increase MTBF for brand new parts of that model. Bonus for repairing(or failing to repair) faulty parts (now you know what could break). All in all, it would allow the player a more realistic control of construction time: rushing by using old parts with poor maintenance. reliability: spending more time and money costs: it might cost more to recover/repair/reuse a part, but it increases reliability for future new ones. So, early in the Career, Dangit might run with some really punishing values, forcing the player to recover as much as possible. Later, a more sustainable space program might be possible, with reliability high enough for safe long missions and many recovery and reuse cycles, even with lower maintenance costs, so, faster to build. When the player is not in a hurry, he can focus on safety. How does that sound? We already have all the pieces, they just need to fit together.

Hey @linuxgurugamer awesome job updating so many mods! Question: is it possible to link DangIt to Magico13's Scrapyard mod? They would really go well together. I discussed it with him and this was his reply. Basically, upon recovery, but before Scrapyard kicks in, ground engineers would inspect all parts automatically. Parts not listed as "as good as new" could be "maintained" for cash (uhmm, cost of the current Spare Parts?). Maybe boost maintenance factor a bit, since they're not working with scotch tape and superglue (or are they?). Then, parts which are completely broken (or still old, even after maintenance) would be refused for recovery by Scrapyard. The only thing remaining would be to maybe give Scrapyard a tag for it to show how old the part is in its part list? Is this something you could make? Or at least give us some hints on how to trigger events and feed the values?

Definitely, but Potatos can't run any VR games anyway. I'm not sure how many are actually potato computers, or if the owners simply modded the game to death (which would be bad news for all of us). And even stock performance in KSP drops a lot when you have massive crafts. So performance is honestly my main fear as well. I used to play the Beta Kerbal at 15 fps and I could live with that and all the crashes. But VR requires 90 fps at all times, lest you vomit. You can go down to 45fps and let reprojection do its work, since Kerbal doesn't care much about doubling/blurring, as you don't have too many fast moving objects around you. But not lower than that. - Micro-freezes: We still get those pesky buggers from garbage collection or whatever., and the more mods we use, the more we get. It wouldn't be a big issue, unless it affects the camera rendering as well. - Framerate: VR will always affect the framerate, especially with the badly needed supersampling turned up. You're looking at usually 50% framerate reduction, if not more. However, the stock Kerbal, with a few interface addons on top is not worse than the requirements of other VR games. - Some mods really hurt the framerate. For example, if I leave Vessel Viewer on "no latency" mode, it will cut my framerate from 120 to 80. I don't even want to think about Scatterer... But Vessel Viewer is mostly used to activate all part actions from the IVA. A simple list would do better in VR, instead of the current 3D version of that mod. I have a decent VR computer, with a GTX 1070 and a Q6700 processor at 4.4 GHZ. With my modded Kerbal (no graphics mods, but all settings turned to max), I get around 150-180 fps in external cameras, and between 80-120 in interior camera with some really cool RPM cockpits. So VR with a supersampling of around 2.0 should work just fine for me, as it already is. I'd probably turn down a few graphics options here and there and I'd probably have issues around big bases/stations. But the VR mod for 1.1.3 was way lower than normal, with framerates in the 20-40 region. Camera movement was fine, but doubling was a huge issue. I have no idea if that's a Unity problem or not. If it is, than it might be a nail in the coffin, no matter how much the devs would want to make VR. On the bright side: - most VR games today have framerate issues. The general idea is that "performance will improve as the hardware improves". - any dev trick to increase framerate and reduce sturrering would benefit non-VR players as well. - even a NASA computer would struggle to launch a 1000 part ship.

Gotcha, I'll post it as a suggestion to Linuxgurugamer. Many thanks. By the way, you misunderstood me, the game crashed even when using Scrapyard alone (no other mods). I was just reporting that the others work fine. Happy updating

Hey Magico. Same here. KCT, along with Stage Recovery and FMRS all work fine though. Quick question about Scrapyard and Dangit. Is it possible for Scrapyard to store Dangit values? Assume that a part has a 5000 hours MTBF value. You fly it for 4000 hours, you recover it, then the mechanics do some maintenance to bring that value down to around 2000 hours but you end up with a higher chance of failure if you reuse it. Is that possible to implement? Some customization would work on top of that, depending on the part complexity. Dangit already has a minimum engineer level requirement for specific parts to make them harder to repair. If you could read that value, you could also make it affect the "ground engineers". So a landing leg might restore more durability, but an engine might not. It would all tie in nicely. If we could see the "new" MTBF we could easily decide which parts to keep and which to scrap or keep for shorter missions.

When using FAR, you can safely use Trajectories while in Orbit or when landing on non atmospheric bodies. While in Orbit, the landing prediction will work ok until you hit the atmosphere. After that, it will arch up and mess around. But that seems to happen to Mechjeb's landing module as well. Still there are no errors until you reach around 8000m altitude. After that, the log gets flooded every milisecond with: [ERR 00:12:28.372] [FAR] NaN Prediction Section Error: Inputs: AtmDen: 0.00426203 Mach: 0 Re: 0 Kn: NaN skin: Infinity vel: (0.0, 0.0, 0.0) Turning the Line display off completely stops the error and restores the framerate. If I were to suppose something, it would be that Trajectories doesn't read FAR's speed. I am usually going over 1 Mach when I hit 8000m, yet the log shows a 0 value.

Same here. I didn't use joystick for a long time in KSP, but now that I have a decent Hotas, I am really glad it has support for them. Thankfully, the devs didn't say "too difficult, too expensive, too niche" on that one. Make sure to get the 1.1.3 Kerbal version, and get this mod: https://github.com/Vivero/Kerbal-VR It's exactly as you described it, IVA only. Make sure you use -force-opengl and that your steamVR version is not a beta. Unfortunately, because it's a hacky VR, it doesn't have good fps, but you'll be able to see how it would look. The worst problem is the lack of mouse cursor, so you can't use RPM buttons with that. The funky graphics of KSP really work well in VR. The tiny cockpits are a far cry from IL-2, but they're really fun. I suggest you use infinite fuel and hop around the Mun. In the Lander pod you can actually bend forward and see the ground really well through the lower window. You can also put our head out of the window and look at the craft from outside a bit. But seriously, as long as the VR implementation can use the current interface without any issues, flying in 3rd person would be cool as well, with mouse and keyboard If they allow world-scale to be set by the player based on scene, then you'd be able to see the rocket as a small Lego rocket a meter in front of you, or go real scale.

My answer to this was the rest of the paragraph you quoted. And you know what? Do you think that when flying a low level Pe2 in formation with my squad mates, skimming the treelines and seeing AAA fire coming at us, or flying through a 3D bomb blasts I give a thought to how much it cost the devs? I honest to God don't give a damn. Even if it bankrupted them in the long run and they'd never be able to release another expansion for IL-2, 1000 expansions on 1000 flat monitors wouldn't hold a candle to just one of the amazing VR planes they've made, even with the current technology. An guess what, even at 10% of the KSP playerbase, those guys are still surviving and investing in improving the game like crazy. You're giving me them as an example of why KSP shouldn't have VR? HA!