[1.12] Extraplanetary Launchpads v6.99.3

[TauPhraim]

If you attach launch clamps to your ship they will be part of the build. Might help, might not.

Okay thanks, the clamps don't completely prevent it from spawning into the ground (though I think they made the orientation change somehow), but at least they prevent it from flying away, long enough for things to stabilize (I can safely release the clamps afterward).

[yorshee]

I dunno if this is a known issue but I don't get the option to fuel my crafts once they've been built, I only get the 'Finalize build' and 'Teardown build' buttons. I'm using survey stakes as a launchpad, I dunno if that has anything to do with it.

[taniwha]

TauPhraim: you need a -Y stake to specify the bottom of your spawned vessel, and yes, launch clamps will help.

yorshee: That has everything to do with it. The cost of survey builds is you need to find a way to fill your ship. Building on a pad lets you fill the ship but removes the freedom of placement.

[smjjames]

yorshee: That has everything to do with it. The cost of survey builds is you need to find a way to fill your ship. Building on a pad lets you fill the ship but removes the freedom of placement.

Unless it's a mobile pad of course.

[yorshee]

yorshee: That has everything to do with it. The cost of survey builds is you need to find a way to fill your ship. Building on a pad lets you fill the ship but removes the freedom of placement.

Ahh, I see. I managed to fuel it with KAS pipes so everything is all good.

[TauPhraim]

TauPhraim: you need a -Y stake to specify the bottom of your spawned vessel, and yes, launch clamps will help.

Is this correct ? :

* there is no point in trying to choose the vertical/Y direction, because the mod will take the planet's vertical anyway

* however, you can indicate the Y lower bound, with the position of a -Y/Bound (not "Direction") stake

* it should be possible to spawn a ship on a slope without clipping into the ground occurring (ie: it is a "supported" use case)

Is there a documentation somewhere ? If no, I think it could be good to create a wiki on the github repo (or somewhere else). Even if you don't have time to compose documentation, just drop what you have, unformatted (what you wrote in this thread for example, or more), and maybe others will rearrange it (even if they don't, it would still be better than scattered thread comments).

Thanks !

Edited August 26, 2015 by TauPhraim

[taniwha]

TauPhraim: More or less correct. For your second and third points, the image in this post pretty much says it all The post and the release notes following it have some docs, but yes, docs are needed (I plan on writing up some in a form suitable for KIS's book part).

It actually is possible, and sometimes useful, to specify the Y axis (normally, X or Z will become vertical in such a case), and even to specify all three (though the resultant will be orthogonalized), though rather difficult (maybe near a Mun arch).

- - - Updated - - -

Ahh, I see. I managed to fuel it with KAS pipes so everything is all good.

That is the intention

Actually, when the survey system was designed, KAS was all we had, so there was no problem (you were guaranteed of having pipes if you could use the stakes).

[TauPhraim]

the image in this post pretty much says it all

Not all, to me I'm not sure what was just spawned and what was already present, in the image. I will just try with origin/+x/+z, and -yBound and see how it goes. So basically I should place the -yBounds stake somewhere higher on the slope, and only it's altitude counts, not the rest of its position ?

I plan on writing up some in a form suitable for KIS's book part).

I still think a wiki would be valuable: it would probably be faster to write, and personally I prefer alt-tabbing to a wiki than reading inside of KSP (or it opens a PDF viewer maybe, but either way I didn't like it, last time I tried).

It actually is possible, and sometimes useful, to specify the Y axis (normally, X or Z will become vertical in such a case), and even to specify all three (though the resultant will be orthogonalized), though rather difficult (maybe near a Mun arch).

.

If I'm correct, you're currently only reading each stake's position, not its orientation. What about, for the Y stakes (or for a new type of stakes like "Vertical"), also reading the orientation, so that the stake *by itself* can point to a Y direction (as opposed to needing the stake's position + some other reference point) ? I think that would be more intuitive (provided that a stake is perpendicular to the ground it's planted in), and would not require an arch

[taniwha]

TauPhraim: heh, theres a rather large base (36.9m x 36.9m), on launch clamps for that matter, on a very steep hill (about 20° if I remember correctly: steep enough I had to anchor my crane to the ground (KAS pipe) or it would slide down the hill) on Mun. Everything visible in the foreground (except the stakes) was spawned there (though not all at once). The crane was spawned just above the docking port to which it is attached by placing an origin stake directly below the port, and a -Y Bounds stake sufficiently uphill for the bottom of the crane to be above the port.

Stake orientation would be extremely frustrating due to the lack of precision. I believe you can place a stake with centimeter precision (if not better). At 200m (maximum distance between two stakes in a site, and there are ways to get more), you get a bit over 10 arc-seconds of precision (in theory: binary floating point math might put a higher limit on the precision).

The system was designed for ease of use:

• Planting a single stake (with any setting) just works: the built craft will spawn with its root part directly over the stake vertically oriented with it's starboard side (VAB) or nose^* (SPH) pointed east (ie, the same orientation as launching from KSC. ^*I am uncertain whether this has been verified.
  
• Multiple stakes of the same setting act as a single located at the average position of the multiple stakes.
  
• Bounds stakes override Origin stakes for the specified axis. Placing Bounds stakes for all three axes makes Origin stakes have no effect (almost: they can be used for "connecting" distant stakes).
  
• Placing Bounds stakes for both positive and negative directions on an axis will cause the bounding box of the built craft to be centered on the average of the two stakes (on that axis). This makes it easier to place craft with off-center root parts in crowded areas.
  
• Unless all three axes are specified with direction stakes, the 3rd axis will always be vertical. I very well could have made the 3rd axis perpendicular to the other two if two axes were specified, but I decided (after much deliberation) that it would be easier if the third axis was vertical.
  

While the system is designed for ease of use, I also ensured that there is room for catastrophic error, and more importantly, room for experimentation.

[TauPhraim]

The system was designed for ease of use:

• Planting a single stake (with any setting) just works
  

On flat ground only, I think. When you want to spawn stuff on a slope, it becomes much less obvious (in my opinion).

Though I'm not making cranes (yet), I understand that it's fully customizable in order to legitimately build stuff in the air. But spawning basic stuff on a slope must be more frequent than making cranes, I suppose. I see 2 ways to solve this without reworking everything:

• access the spawned ship's bounding box (if possible), and the local slope (hoping it doesn't curve too much) to choose the right altitude that prevents clipping
  
• some easy to find doc/tutorial on how to place things on a slope (I'm not talking for myself, because I think I got it now, and next time I can try, it will work)
  

[taniwha]

TauPhraim: Cranes are irrelevant other than I was describing what was in the picture and how I did it. What you are describing is the surveyor's responsibility. Bounds stakes use the ship's bounding box. Also, it is the engineer's responsibility to ensure that a ship can handle being built on a slope, this may involve including launch clamps in the design.

[edit]One rather important thing that I did forget to mention: having only one Bounds stake for an axis puts that side of the bounding box on the stake's location.

Edited August 26, 2015 by taniwha

[TauPhraim]

By cranes I meant anything that legitimately needs to be some distance off the ground. I agree that for these, it's the engineers' responsibility to place them (although the fact that it's not WYSIWYG makes that painful). It's also their responsibility to ensure the thing won't topple, probably.

Now preventing stuff from spawning clipped into the ground, I have a hard time putting this on the engineer. Maybe for people used to design 3d models or things like that, it's easy, but in a video game it's rather unexpected, and people usually see that as a bug rather than a player failure.

[taniwha]

TauPhraim: Preventing stuff from spawning clipped into the ground is the surveyor's responsibility. This is part of the game that is EL. Now, admittedly, documenting that would be good, but it was my intention from the start and is part of the design of the survey system.

[TauPhraim]

This is part of the game that is EL

This is not the part that I enjoy the best, but I suppose it's a matter of taste

On (almost) another topic, I now have a situation where I get explosions upon trying to spawn a rover. It's not spawning in the ground, and explosions happen with the MKS launchpad as well as with stakes.

If you care having a look, and it rings a bell, the log shows some spamming of an exception, and then something that might be related to EL. Thanks !

Edit: I tested with another smaller rover: this one hovers for a few seconds when I "finalize", and then gets teleported under the launchpad, pushing it in the air. I'd say the big rover suffers the same teleporting, but explodes instead of just pushing the launchpad away, due to being bigger. With the small rover, when clicking "finalize", the finalize button does not disappear, and it apparently allows spawning additional instances of the rover (but the launchpad is flying away by that time).

Edited August 27, 2015 by TauPhraim

[taniwha]

TauPhraim: I need your full log file, not an excerpt.

[TauPhraim]

I could not reproduce this problem after restarting KSP

In the meanwhile, maybe I have another issue for you I'm using UKS and I noticed the Rocket part cost displayed in the VAB is not the same for (at least) one part, depending on how I add it. To reproduce:

- start with any root part

- add a "UKS octogonal landing module" by clicking in the part list on the left and placing it. Cost goes up by 500 rocket parts

- add another, by cloning the placed first one (alt-click). Cost goest up by 600 rocket parts !

I noticed the part list says "mass = 1.5" for it, but once placed from the list, the part says "dry mass 1.25". Whereas placed by cloning, the part says "dry mass 1.5". If the cost is calculated from the mass, it might be related to the problem.

[taniwha]

TauPhraim: is the part's build cost correct in the field?

[TauPhraim]

I tested with a ship having just 3 of that part, the first one root, the second added picking the part in the list, and the third cloning the second.

In the VAB the cost displayed was 1600 (500+500+600), and the ship mass 4t (1.25+1.25+1.5).

In the launchpad menu, the cost displayed was 1800. It effectively cost me 1800 part to spawn it. The spawned vessel had a mass of 4.5t.

Upon reopening the craft file in the VAB, cost becomes 1800 and mass 4.5t too.

So if the correct dry mass is 1.5t, and EL is just using the mass, I'd say the bug is not in EL.

[taniwha]

TauPhraim: the bug is in EL, but in the ShipInfo panel (ie, in the VAB). While both the ShipInfo and Build windows use the same system to determine the vessel cost, there are some differences in feeding the vessel to the system (necessitated by the different situations).

[JewelShisen]

Do we have to have toolbar for this or is there a version that uses the built in stock one?

[goldenpsp]

Do we have to have toolbar for this or is there a version that uses the built in stock one?

Still needs Blizzy's

[JewelShisen]

Still needs Blizzy's

Fun... Can we please get a stock one soon? This is the ONLY mod I use anymore that still forces the use of that mod.

[ss8913]

Can someone explain to me how the runway works? It doesn't look very runway-ish.. is there a way to build an actual long runway on Laythe/Duna/etc with this part?

Also is it normal for ships to not work correctly when first undocked from the launchpad? I release from the orbital dock and then have to quicksave/quickload to make physics, engines, etc work correctly. Known issue? just me? something else?

[taniwha]

ss8913: I've never seen the point of the runway (inherited part). I'm not sure it's long enough for a small plane on Eve, let alone anywhere else.

[Van Disaster]

Can someone explain to me how the runway works? It doesn't look very runway-ish.. is there a way to build an actual long runway on Laythe/Duna/etc with this part?

Something I've wanted to do since this mod & Kerbtown first appeared. You could certainly make a 2km runway part & spawn it, but it wouldn't be stuck to the terrain like an existing static building - and good luck spawning a 2km part without it clipping the ground & going mad if the ground is flat enough that it won't clip then you don't need a runway anyway. I've just removed the original launchpads entirely ( along with most of the legacy parts ), no need for them anymore.

I made a large and heavy launchpad piece years ago ( it's in a couple of pics way back down the thread ) but the stakes made that somewhat redundant - fuelling post-spawn is no more hassle than fuelling at spawn if you're on the ground.