Jump to content

Robin Patenall

  • Posts

  • Joined

  • Last visited

Everything posted by Robin Patenall

  1. Hi @linuxgurugamer, I think that the ModuleCargoPart module got left out of the new default configuration for the rover wheel, meaning that it can't be used with stock construction. It got added to the old default configuration in enkido's commit back in October, but not the originally disabled one. For anybody looking for a temporary fix add : MODULE { name = ModuleCargoPart packedVolume = 116.8 } just before the last close brace in "GameData\ASET\PRC\KRoverWheel-stock.cfg" (Copied from the old default configuration)
  2. My head canon is that the Not-Rockomax Micronode was made the wrong size, if it was double the size it would be perfect to connect the modular girder segments together. I've been working on a personal mod that creates (among other scaled parts) modular girders that are the same length but half the size in the other dimensions and the micronode fits them beautifully. In fact, I added a double sized micronode (a mininode if you will) just to be used with the normal sided girders. My vote for the most useless part is anything to do with planes. I still think that the ability to build, fly and land a plane without blowing up in KSP is actually some in-joke that experienced players keep telling the newbies and any purported sightings of planes (spaceplanes or otherwise) around the KSC are actually UFOs.
  3. That all looks good to me, thanks. Re: the cone explosion. I'd not used EL before (my brief dalliance with off Kerbin building was with Global Construction, which uses a significantly different method of targeting) and started with the simplest method to test, which is with a single origin marker. Without reading through the whole EL forum thread, I suspect that the reason you can use multiple markers to indicate the build location (an thus not have a marker directly under the vessel being built) was to prevent the issue I was having when building things that touch the ground at the centre. Using 2 (+X and -X) cones definitely solved the issue during my testing.
  4. Had a bit of a play with this and it all looks good apart from a couple of minor things. The part description of the Sandcaster 3D printer need fixing (it starts #LOC_SANDCASTLE....), I think you've missed a something in Sandcaster.cfg Is the any reason that the SurveyCone can't have ModuleGroundPart added if KIS isn't installed. I'm a bit annoyed that the EL survey stake just falls over if I don't have KIS and therefore I can't use it (and as far as I can see ONLY that), but making the Cone a ground part allows me to do surveyed stuff without KIS. I put a quick and dirty patch in (more of less copied from EL survey stake) and it all seems to work apart from the issue that the cone self destructed when the MK1 Cockpit I was building tried to occupy the same location but I don't know if this is an issue with what I did, Sandcastle or EL (it certainly stopped happening when I added legs to get the cockpit off the ground). (After having written this, I did test and I can drop the Survey cone with an engineer in EVA construction mode, so #2 isn't quite as important, but it would be useful for non-engineers)
  5. If you have Making History or Restock Plus, I think you can do this with Engine plates. Normally you put an engine plate at the bottom of your fuel tanks then attach the engines to it and then attach the next stage to the node that floats off the end, which will decouple when the engine plate is staged. I think that you should be able to turn one upside down, attach to the front of your rocket with a parachute where the engine(s) would go and your thing on the floating node. The only issue is I don't think that either Making History or Restock Plus have a 0.625m version, the smallest being 1.25m, so it might be a bit large for some configurations.
  6. Has anybody written a resource teleporter mod? I had a look but I couldn't see anything. I was thinking what would be the minimum extra game play needed for KSP2 over KSP1 and realised that (apart from multiplayer) you could mostly get away with something to grow Kerbals, something to allow orbit / off planet construction (like Global Construction) and some way of easily moving resource around (like Kerbal Space Transport System but more general). The Kerbal growing and construction mods seem to be available but none of the automated flight mods seem to be general enough and I realised that if it was reduced to resource teleportation it would be much easier. I am envisioning a teleporter container that holds a resource (FO / Fuel / Oxidizer / Xenon / Ore / Whatever is needed for construction) and allows the contents to be magically teleported to another teleport container that can hold some of the same resource at the expense of electric charge per unit mass (possibly at both ends). The teleport could have a maximum range or require more EC per unit mass depending on the distance. Possibly, this could be limited to teleporters in the same sphere of influence and the EC based on the required change in potential energy (gravitational and kinetic) This might be manually done (click teleport in PAW, select from the valid destination teleporters, and beam me up Scotty) or possibly have teleporters paired so that material automatically goes from a source teleport to a destination teleport as there is space to hold it and EC. This would make using something like Global Construction to build space infrastructure much less tiresome as you wouldn't need to keep moving resources around. You could put a construction yard in Minmus / Mun orbit with an ore harvester on the surface, teleport the ore into orbit and convert it into FO / Matpacks at the construction yard to build and launch large ships. Is there anything like this? Does it sound like it would be useful? Or is there a fundamental flaw with the idea?
  7. Love the look of the yard frames, I'm currently setting up a construction space and they'd be great to add to it. Just a question, is it possible to allow a Kerbal to grab onto them and move along them like ladders? I'd assume along the edges of the individual panels. One of the issues I have at the moment is that I've going to have to send up a rocket with loads of ladder segments so my engineers can grab my current structure in more places so that they are anchored while in EVA construction mode. I know I'd be able to do the same thing with the yard frames but having it built in would be much easier (for me at least, I don't know how easy it is to add to the part)
  8. Forgive me Bob, for I have sinned. I've just launched a Duna mission consisting of a flotilla of tiny probes as I didn't check the transfer window planner before I accepted the contract and I am 100 days past the best point. To prevent this from happening again, I checked all possible stock targets for upcoming windows and in 30 days or so I have a Dres window that a copy of my Duna science probe should be able to reach (which says more about my Duna mission than any potential Dres mission). Except, I realised that there was no way solar panels were going to cut it and I'd have to use RTGs, which I haven't researched yet. So the problem is I need 1300ish science in the next 30 days. I've sort of done Minmus, so I decided to sent a station with a mobile lab, lander, rover and lots of fuel to the Mun and do all the biomes, each experiment done three times, once for transmission, once for return and once for the science lab . I'll even pick up all the science in Kerbin orbit, which I've already collected, and load it into the science lab to kick the research off. First Sin. I thoroughly tested my rover around the KSC. This was absolutely not science farming and the fact the it gave me about half the science I needed was completely beside the point. (Actually, it did show up a design flaw in the rover, so it was useful) Second Sin. After absolutely not science farming the KSC once, I realised that I could add a mini-grabbing unit to the rover, repeat the grand tour of the KSC and then grab the launch clamp of the Mun rocket while it was on the pad to transfer the experiments to a experiment storage box I'd added to it. I could then put the experiments into the lab once I was in orbit and I'd get more data. I filled the lab up with about 60% of the experiments I collected. It felt.... dirty.
  9. 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
  10. 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.
  11. 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.
  12. 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 .
  13. 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.
  14. 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?
  15. 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.
  16. 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.
  17. 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?
  18. 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...