Jump to content

Robin Patenall

  • Posts

  • Joined

  • Last visited


11 Good

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I tested a rover design on simulated (i.e. Sandbox mode with cheat to orbit) Moho to check it didn't overheat and the design changes I made after testing it on the Mun. Things I learnt: A Probodobodyne RoveMate can control the landing stage, but it's not great. A CommNet relay needs a probe core, so just sticking a relay antenna on the lander section (controlled by the rover probe core) won't work when the rover detaches. A lander with a proper probe core is much easier to land. The rover design is nice and stable. The Bon Voyage set up now puts the rover on it's wheels not it's tail. The rover is not prone to flipping and can get up a 14 degree slope, stop and do science. The Mun test was useful, as I know not to go over blind ridges at 20m/s and accidently catch vacuum (not good for deployable solar panels) I need a ScanSat altimetry map before I drive around, especially over blind ridges because, Oh *****, that was the edge of a mountain. The fixed solar panels are much more robust. The reaction wheel in 'SAS Only' mode works well, once I turn it back on (need to set an action group as right clicking it while tumbling is not easy) The rover design can go down and across a 40-42 degree slope without flipping and in a controlled manner with careful use of the brakes, wheel controls and SAS. There are 1400m mountains on Moho. The rover design doesn't overheat on Moho
  2. Nope, Kerbisynchronous Equatorial Orbit. Fixed above the KSC at 2.8Mm altitude with a combined antenna power (once finished) of 7.2Tm allowing communication out to Plock at maximum range with a RA-100 at 9% signal strength (as long as my maths is correct). The same mod is giving me a contract to do the same thing at Kerbin L4 or L5 so the sun doesn't get in the way. I'm in two minds about doing that one, but the same launch system I used for the current one should get the pieces there as long as I don't expect to be reusing the second stages. The trick is getting my engineer back once they've put it together, so I might experiment with doing the required engineering work in LKO and send the, now very un-aerodynamic, pieces to dock by remote.
  3. Mine's at least back at the KSC, but is getting lectured by his boss for stowing away in the emergency return capsule that was being sent up with the third antenna module (of a proposed seven) to Kerbin's deep space relay satellite in KEO . This, of course, necessitated the return of said emergency return capsule with him in it. He's probably lucky that the orbital fuel depot being planned wasn't anywhere near set up yet otherwise he might have been been returned via a command seat welded to the top of one of the second stages which will be making a multi-pass aerobraking manoeuvre to return from KEO with as much of the excess fuel as possible.
  4. Update: I've checked that even simple docking arrangements don't glue if they were done outside the VAB. I've attached a save file with examples to the Git issue that Zer0Kerbal raised with examples of the difference docking scenarios .
  5. I'll admit I didn't test a simple docked scenario, so maybe it's related to the multidock. I first tried with a multidock that was done in the VAB and one set of docking ports glued correctly but the other didn't with an error about not having 2 parts on attachment nodes when I attempted to glue. I then built a multidock craft that didn't start docked, and docked it in flight, and then found all the docking ports (both sets had the undock option) refused to be glued with the same error. If it was related to the multidock I'd have assumed that I'd still be able to glue one set. The set I managed to glue I assume was different as it was done in the VAB. I believe, although I'm not a modder, that docked joints are not handled as part of the vessel part tree but is some other way as otherwise multidock could never work, so when you look for the parent and child parts of the part to glue it only finds one. I suspect that ports docked in the VAB are actually done as part of the vessel tree which is why they act differently. I'll try check the simple docking scenario and get a save file for you with the multidocked craft I was using already docked.
  6. I had a look at this (specifically the new beta) and it looks really helpful for the construction of an station I'm going to attempt soon, mostly as I've just found out that I don't appear to be able to remove a decoupled decoupler with an attached engine fairing with EVA construction and don't want spent stack separators floating around. It look really good. One thing I was interested to check was whether you could glue kaboom docking ports and what happened if you tried to do this is a multi-docked vessel (that is, two parts of a vessel docked with multiple pairs of docking ports). Partially, because it would be helpful to me, but mostly because it was something I thought would horribly break given the tree like vessel structure. Turns out: You can glue kaboom docked docking ports but only those docked at the VAB (which is only ever one pair in a multi-docked set) You don't appear to be able glue kaboom docking ports docked in flight. I can't break this as easily as I thought by doing something ridiculously ill-advised I understand that might be asking for the Mun, but is glue kabooming docked docking ports something that might be considered for the future?
  7. The preKSP1-11 patch should be fine on KSP1-11 and above as it's predicated on not having a part that is in 1.11, and should do nothing in 1.11 and above (it was ignored when I checked the MM logs during testing). This is based on the stuff that is in the thread below and currently in the Near Future mods (https://github.com/post-kerbin-mining-corporation/NearFutureElectrical/blob/master/GameData/NearFutureElectrical/Patches/NFElectrical1-10.cfg), but please feel free to leave it out, as I said I don't have and old copy of KSP to test against. I based the cargo size on the pico ports being 1/4th the weight of a Clamp-O-Tron Jr (0.005t to 0.020t) so, given the same density, they be 1/4 the volume (35l to 140l). A quick idiot check based on the pico port being 0.3125m in diameter (half of 0.625m) gives a 35l box that is approximately 0.3584m high, so it seems to be in the right ballpark. Edit: Having written that down and thought about it for a couple of hours, I'm not so sure my logic is sound. I assumed that the density would be the same as it would be made of the same material but now I think about it, it's the overall density of the part the matters which can change. A naive scaling of the Clamp-O-Tron Jr gives a volume of 17.5l, so perhaps 20l would be better than 35l. This does mean that a Kerbal could go EVA with a EVA jetpack and a PicoPort to fit, which might actually be better idea. My original plan was to avoid this as I felt that having to get a rescue craft, a stranded Mun lander and an engineer all within EVA construction range was a reasonable punishment for leaving most of my hero Kerbals in very low Mun orbit with no fuel because I cant read DeltaV chart.
  8. Hi @linuxgurugamer, Here's a zip with just the changed files https://drive.google.com/file/d/1NdEeF59VJKOwd6bzxd3VaUnbcm6X0CZE/view?usp=sharing, that should be unzippable to the SHED directory. I added the cargo part module to the parts and removed them in Pre KSP 1.11 with a MM patch so that this works without MM in up-to-date versions of KSP but requires MM for older versions (I believe there's an issue with parts with a cargo part module not having a PAW in KSP < 1.11) as this seemed the best way to do it. But, as I said I have no way of testing this.
  9. HI @linuxgurugamer, I've been playing with these PicoPorts and I found a bug and a missing feature and have come up with fixes for both of them. When used with your DockingCamKURS, the camera is pointing in the wrong direction. The PicoPorts aren't flagged as cargo parts so you cant put them in inventory and use then in EVA construction, which I felt was something that should be added, as the Clamp-O-Tron Jr. can be. This is my first attempt at modding but the patches seem simple and I've tested them on 1.12.2. I've included the MM fix for removing the ModuleCargoPart on KSP < 1.11 sa this mod is compatible with 1.9.x but haven't found a way of testing that. Assuming you'd like to have these, would you like me to have a go at trying to do a Git fork / pull request with these (I'll do two, one for each issue) or would you prefer another method?
  10. Hi @linuxgurugamer, I thought I'd chime in with an issue I'm having, I am running KSP 1.11.1, but I suspect that it's more related to my late 2013 iMac. The issue is basically that everything works except the image which is just a magenta block. Looking at the logs it looks like an issue with the shaders not being compatible in some way. I tested this on a reasonably modded version (half the mods seems to be supported by you, where do you find the time?), but reproduced the issue in a clean copy with just the dependencies. Environment KSP : (OSXPlayer) en-us (64bit) OS: Mac OS X 10.15.7 CPU: Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz (8) RAM: 32768 GPU: NVIDIA GeForce GTX 780M OpenGL Engine (4096MB) Problem Camera (docking camera and part camera) only show magenta background under the overlay. The actual overlay, controls and UI appear correctly and are working. Mods Installed ClickThroughBlocker v0.1.10.15 / v1.0.0.0 ToolbarControl v0.1.9.4 / v1.0.0.0 DockingCamera v1.3.8.0 / v1.0.0.0 Reproduction steps Build a simple craft in the hanger which includes a camera. Lauch the vehicle to the runway and put on brakes. Open Docking Camera UI from toolbar, right click on camera and tur nit on. Camera UI appears with image only as a magenta background. Logs (I think that this will work) https://drive.google.com/file/d/1zXpr-_Y-R_8FBhvR2mbaFB34aC739Mov/view?usp=sharing Additional notes : I suspect the important part of the logs are where Unity is having trouble finding / loading the shaders. (Filename: /Users/builduser/buildslave/unity/build/Runtime/Shaders/Shader.cpp Line: 558) WARNING: Shader Unsupported: 'DockingCamera/NightVisionClear' - Pass '' has no vertex shader ERROR: Shader Shader is not supported on this GPU (none of subshaders/fallbacks are suitable) WARNING: Shader Unsupported: 'DockingCamera/NightVisionClear' - Setting to default shader. Desired shader compiler platform 15 is not available in shader blob I hope this helps with looking at the issue, should I look into raising this on Github as well?
  • Create New...