Robin Patenall

Actually I had a brain wave last night and managed to test it but didn't get around to posting. I set the "placementMaxRivotVelocity" in the ModuleGroundPart of the stake to something very large (100, but I was going to test lower values) to ensure that the stake riveted to the ground no matter what happened and then set a CoMOffset to move CoM below the bottom of the stake model so that it would be balanced when vertical (I used %CoMOffset = 0.0, -0.5, 0.0). I was going to do a bit more testing tonight, to refine the values, before suggesting the fix but it seemed to be a promising workaround. The correct fix of setting the ModuleGroundPart kinematicDelay value to 0, doesn't work as it seems to ignore values < 1. (This is of course all in the @PART[ELSurveyStake]:NEEDS[!KIS]:FOR[NotSoSimpleConstruction] patch in KerbalInventorySystem.cfg)

Edit: Oops, just seen the line of text under the 1.0.99.3 release about the issue with this. Does anybody know how to get the Survey Stakes to work properly with the stock inventory? Every time I go to deploy them, they fall over. To be clear: I have a Kerbal with Survey Stakes in inventory on the ground (I've tried the launchpad, runway and just off the runway on the grass) I deploy the stake by clicking on the down arrow in the bottom right of the inventory slot I get the stake floating in mid air in front of the Kerbal and the deploy UI ([Space] to to place the part, [J,L,H,N,I,K] to rotate ) just like deploying science experiments I hit space The Survey Stake falls over It isn't riveted to the ground like normal and I can kick them around, but they still actually work when building craft . I've used the cones from Sandcastle which do the same thing as Survey Stakes and they deploy (and rivet to the ground) fine. Is it because the stake wouldn't stay steady long enough? It's just that I don't want the boundaries / axis of my "things may magically appear here" area to go wandering off if a Kerbal walks over it.

I was looking at swapping out EPL with SimpleConstruction but it does look like there are compatibility issues with Sandcastle. Mostly because there is no MetalOre or ScrapMetal in SimpleConstruction which causes issues with B9PartSwitch. There are also issues with the densities of some on the resources which means that the simplest changes (changing MetalOre to Ore and dropping ScrapMetal) caused the RocketParts container to act like a Tardis and the Smelter to behave oddly.

Lots, and lots, of math, but I let my PC do it. I wrote a python script the would check each Lat / Long / Altitude to see if that point had an unobstructed line of sight to any of the ground stations. There was some optimisation that would stop at the lowest height that had CommNet coverage as I believe (but didn't prove rigorously =) that if there is a connection at a given height then there is always a connection above that. It wasn't that efficient, but it never took that long to run and I worked with smaller map images while debugging before using the high resolution maps for release. I found a list of the Lat / Log of the ground stations but had to get the altitude with the WayPoint Manager mod. I assume that they broadcast from terrain ground level (mostly as I know there are actual objects there) and this does appear to match up with the tests I made in game but I'm always open to be proved wrong. I had to make a reasonable assumptions about how KSP calculates CommNet occlusion (i.e. the occluding object is a sphere with radius = Planet Radius * Occlusion Modifier) but this matches what others have said in this forum and does appear to be correct. Edit: DarthGently is right, CommNet appears to ignore terrain, I've seen active connections pass through mountains even when the Occlusion Modifier is 1. The altitudes on the maps are above sea level and yes if land on high terrain you may get a signal where are you might not in the same position at sea level. In fact one of my reasons for building the maps was my loss of signal just before landing in the waters East of the KSC near the Island airstrip. The KSC is about 70m above sea level and you don't need to go far to lose signal just before impact (important for powered landing) The minimum height ALS for connection at the Island airfield is about 450-500m

I got annoyed at losing control of my unkerbaled vessels when I was using hard mode as Kerbin does not have full coverage when the CommNet occlusion modifier is 1.0, so I generated maps which show where you have a CommNet signal vs altitude. I've put a post in the Tutorial forum as I thought that others might find the maps useful, which also includes lower altitudes (10m to 60km) for people trying to do powered landings

Having played with KSP on hard mode, I found it quite annoying that you don't get full CommNet coverage of Kerbin when you are in orbit unless you are very high. I kept losing control of vessels with only probe cores when I was launching or attempting to do a re-entry burns, so I thought that I'd create a map so I could see the altitude you need to have CommNet a signal when in hard mode (or when you've set the Occlusion Modifier to 1.0). I ended up creating two, one for orbital heights (75km to 250km) and one for surface heights (10m to 60km). Each colour patch indicates where there is no CommNet signal at a given altitude. The most interesting bit is that there is a large CommNet blackspot East of the KSC, just about the place that you might be attempting to circularise and it goes very high, this means that launching a vessel with just probe cores onboard really needs a relay satellite to be in place first. Looking at the map, it looks like an initial relay satellite might be best launched into a polar orbit giving you much more time (via North Station One) to circularise before you lose connection. I've done a bit of testing and it does seem to match the reality of the game. Hopefully these will be helpful to people Orbital Heights Large (4096 x 2048) and Small (1024 x 512) Surface Heights Large (4096 x 2048) and Small (1024 x 512)

I thought that you'd be interested that your EMUV combined with a Clamp-O-Tron Jr and a 1.25m heatshield (with a small amount of ablator) gives a neat little Kerbal re-entry vehicle, so long as the Kerbal has a parachute. It can easily de-orbit on the RCS and you even keep the EMUV. I'd expect that the docking port / heatshield bits could be attached to a station, stacked even, so that the EMUVs could dock with them if they were needed rather being attached at all time.

I have managed to get undeniable proof that the LY-01 Fixed Landing Gear isn't made of dynamite and doesn't have logic that makes it explode at any time it's within 1 meter of the ground. I actually managed to do a huge loop of KSC 09 to Island 09 to KSC 27 to KSC 09 to Island 09 to KSC 27 with out a single explosion, although I wouldn't want to do it without having NavUtilities Continued installed. When Squad added more support for flight, they really should have included some sort of ILS / VOR Do you think it's bad that I've only managed this after binge watching a YouTube channel that explained loads of historic aircraft disasters in great detail?

One of my scientists expressed an interest in not passing above the Kermin line for a while due to a slight case of mind-numbing terror (being recused from a small pod, in Kerbin orbit, going round and round and round with nobody to talk to, and more importantly no snacks, will do that to you). So we found her something to do to assist the space program by doing Science from difficult to reach locations on Kerbin using an experimental vessel that uses lifting surfaces rather than thrust to keep it off the ground. The engines even use the atmosphere so the craft doesn't need to carry oxidizer, just liquid fuel. (One of the other research teams scoffed at this and said that they had an even better engines that didn't use oxidizer, only liquid fuel, but we've seen some of the materials they use glowing blue and being carried around using 5m long tongs, so we'd prefer that they kept themselves, and their lead lined overalls, to themselves) She managed to fly to the far North and collect Science from the Tundra, Northern Ice Shelf, and Ice Caps while flying, touched down and while splashed down (the R&D team did complain that she'd voided the warranty on the engine by running it underwater) . On the way back, she stopped off in the Desert to pick up a bit more (we think that she just wanted to warm up, something we don't blame her for) and even managed to get Science while splashed down (as an after thought we think, comparing that timestamps on the science with her social media posts shows that she was gloating about swimming in the desert lake for at least an hour before any science got done). She returned to the KSC with almost 360 science stored. She might be sent on more missions to the Southern Ice Shelf and the Badlands, but it depends on how much Bob get annoyed at her.

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)

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.

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.

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)

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.

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?

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)

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.

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

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.

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.

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 .

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.

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?

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.

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.