[1.12] Extraplanetary Launchpads v6.99.3

[Apaseall]

I'm spawning mc-1000's n 2000's with a few flat pack pathfinder. Every time. Plus now for fun the whole base n anything attached via pipes lifts off the ground during warp. Luckily it lands nicely when warp ends. It was a bit of a shock though! Things seem to consistent now, which is nice.

[taniwha]

@Apaseall: you need to hold x or h when placing the stake in order for it to attach to the ground and thus not fall over (unless it gets knocked), you should hear a hammering sound. This should be somewhere in the KIS instructions.

I'm not sure what happens with physics hold on. I think I've been too busy making sure my bases don't explode before worrying about hitting a button (and I usually have to open the build window anyway).

As for the stakes: actually, a single -Y bounds stake behaves exactly the same as a single origin stake. I'm not sure it's in your copy of the manual (but will be in the version linked from the OP), but section 3.2 goes into detail about stake operation. But for the moment...

The positions of all Origin stakes (Bounds or Direction: no difference for Origin) are averaged to find the site's center. IE, the point above which the craft's root node will be placed with the bottom of the craft's bounding box touching the center (unless other stakes are used). If there are no Origin stakes, then the positions of all stakes are averaged (this is to ensure there is a center). This means that using two Origin stakes is sufficient to create a site where the build craft will not hit the stakes if they are sufficiently separated (about the size of the craft is enough). Also the center of the site is actually about 19cm above the ground (by design: this gives a little leeway on uneven ground).

The default orientation of the site is such that editor (SPH/VAB) up is local up and the parts pointing towards the door will point towards east. This is where Direction stakes come in. +X is towards the editor door (east on the launch pad), +Y is up and +Z is north, I guess (I get confused by the left-handed system). The positions of all direction stakes with the same axis are averaged and the line joining the site's center to the axis point forms the relevant axis of the site. Do note that Y Direction stakes can be dangerous and must be used with extreme care (ie, in conjunction with bounds stakes), otherwise your craft absolutely will be built paritially in the ground. Also, when the site's axes are not mutually perpendicular, they will be rectified so up is up (unless you have Y Direction stakes) and the other errors minimized.

By default, the craft is built with the root directly over the site's center. Adjusting this is where Bounds stakes are used. In general, do not use a +Y Bounds stake, as that is the top of the craft's bounding box. It is there because there may be times it is useful. Anyway, again, all stakes with the same setting are averaged. The way bounds stakes work is that if you have only one bounds point on an axis then that side of the craft's bounding box will touch that bounds point: eg, with a +X Bounds point, the door facing side of the craft will "slide" along the bounds point as "adjustments" are made on the Y or Z axis. However, if two bounds points are specified for an axis (eg, +X and -X), then the craft's bounding box will be centered over the point halfway between the two bounds points on that axis. Any "sliding" occurs along the site's axis planes (for a site with X bounds stakes, the sliding will be in the site's Y-Z plane).

What does all this mean?

Here's how to do a build for a large craft on unfriendly terrain (eg, the side of a Mun crater: title page of EL's manual:)...

1. Place an Origin stake somewhere convenient. This will form a reference for the direction stake.
2. Place either an X Direction stake or a Z Direction stake (sign as convenient) to determine how your craft will be rotated around its up axis. More importantly, this gives very clear meaning (to yoU!) to the bounds stakes you will use. I learned this one the hard way .
3. Place three bounds stakes: X Bounds and Z Bounds where you want that corner to be (eg, +X and +Z are the north east corner of the KSC launchpad), and a -Y Bounds stake slightly above the X and Z bounds stakes. 

NOTE: step three is where the direction stakes shine: once you know how your craft will be turned, you have a very good idea where each corner will be. You want your X and Z bounds stakes to be the corner over the highest terrain for the site with the craft over the lower terrain. If you get mixed up, your craft will spawn over (and in) higher terrain. You then put your -Y bounds stake a little bit higher than the X and Z bounds stakes, and your craft will spawn clear of the ground. Do be aware that for steep terrain your craft may spawn quite far from the ground, so launch clamps are highly recommended.

 

This didn't quite fit, but...

The line connecting the Origin stake to the Direction stake, projected onto the local horizontal plane, will form that axis of the site (-X stake will be the -X axis of the site). The other axes will be worked out automatically using local up as +Y and the other unspecified axis from the cross product.

 

I have updated the "live" manual to have a screen shot (page 14 as of this writing) of a hillside site showing a working setup.

Edited February 27, 2018 by taniwha

[Apaseall]

@taniwha Thanks for the reply.

Yes to get the KIS/KAS sound for attachment you need to use H whilst having the mallet equipped.

The screen shot for the live manual is landscape and a bit tricky to read, any chance you could work some magic to make it portrait orientation?

Other than that I probably will be working with three stakes real soon, as I will be wanting to make some part efficient storage. Bound Origin, -Y and +X. I look forward to having fun working out how the saved craft orientates.

[taniwha]

7 hours ago, Apaseall said:

The screen shot for the live manual is landscape and a bit tricky to read, any chance you could work some magic to make it portrait orientation?

I made it landscape to maximize the image's size on the page. Your pdf viewer should have an option to rotate the page (in firefox's built in viewer, it's in the tools menu (>> button in the upper right)).

[Apaseall]

1 hour ago, taniwha said:

I made it landscape to maximize the image's size on the page. Your pdf viewer should have an option to rotate the page (in firefox's built in viewer, it's in the tools menu (>> button in the upper right)).

Ah yes, found the rotation. As usual trying to view a 3D image in 2D is not as easy as it seems. I wonder if two dotted lines would help? I think the base of the launch towers is a rectangle with one corner bounded by the +Z Bound Stake and the +X Bound Stake? A dotted line from the +X Bound Stake projected along the ground towards the actual footprint of the spawned craft (the launch towers) and another one from the +Z Bound Stake. All I am suggesting is a little annotation on the drawing to aid the user in visualizing the situation in conjunction with your written descriptions. As they say, an image is worth a thousand words, but an image with a couple of notes added goes much further. Anyways hopefully I will be able to get round to planting more Stakes soon, once I stop getting distracted by building a rover and the sudden spate of KSP crashes.

[taniwha]

Yeah, it was the only reasonable screen-shot I found that showed the stake icons.

Rovers are especially difficult since KSP 1.1 due to the wheels (though crashes? that's unusual). I suggest a launch clamp to hold the rover slightly off the ground.

[TDplay]

hi i have an issue to report sorry =c

I've just noticed that renaming a Launchpad in the SPH (and probably VAB too but not verified) causes the area where the rename thing is to be unusable for the rest of the session in KSP whenever you're in the SPH (probably VAB too again but not verified).

I'm running 5.9.0 (latest as of now) so not an old version issue.

[taniwha]

@TDplay: considering the trouble I have with KAC's popup sometimes, this doesn't surprise me. I really wish using Unity's canvases from code was easier (because then I would use them instead of OnGUI).

I'll take a look and see what I can do.

Edited March 2, 2018 by taniwha

[taniwha]

@TDplay: I must thank you, not only was there a problem with the input lock code, but renaming a pad in an editor caused an NRE. Now fixed. Unfortunately, there are game-breaking changes in EL's dev code so I need to hold off until KSP 1.4 drops before doing an update. In the meantime, you can move the window to somewhere unobtrusive before closing it.

[TDplay]

@taniwha Thanks, glad to know I helped you develop your excellent mod. I can quite happily wait for 1.4 (and the rest of my mods to update... _{And I'll need to update my own (unpublished) mod TDPIndustries Permanent Bases for Pathfinder... looking forward to that because i'll probably have to reanalyse pathfinder's code...}) for this minor issue to be fixed.

[Apaseall]

@taniwha Is there some formula for determining the ProductivityFactor for parts? Or is the assignment more of a judgement call?

edit.

I have been doing some work with patches/parts that might be of interest to you: https://www.dropbox.com/s/s7e7mzl4s1pulwg/Ex_Launch_Patched.1.rar?dl=0

Edited March 4, 2018 by Apaseall

[taniwha]

@Apaseall: For workshops? Mostly a judgment call. However, I take things like the part's primary purpose into account, thus why command pods have very low productivity. The various "passenger" parts have slightly higher productivity because I figure there might be more room for tools and better accessibility. It's easy to imagine the science lab coming with some tools. Also, I did not want to alter the masses or costs of stock parts, thus again the low productivity. The rocket workbench (funny tower in pods) I settled on 1 being a good factor because though there's little room for tools, it has fantastic accessibility (also, I figured out how to make use of it long after coming up with the build system). The main workshop I consider to be the limit. If you look inside it, you'll see that despite the big parts storage in the center, it's quite spacious, particularly the lower "deck" (though, admittedly, looking down there can be problematic). The 5 is pretty arbitrary (I certainly do not recommend using higher, rather I recommend lower in general), but it comes into the mass and cost of the part. That 15t is made up of 6-8t hull (guesstimate based on 4t for a Jumbo-64) and the rest heavy equipment. And then that equipment is expensive.

If you meant how long it takes to make a part, that's just 5 kerbal-hours per ton of dry-mass.

Back to the initial assumption...

When it comes to part cost, I worked out a cost for RocketParts based on the prices of the various stock tanks with a 20% markup (and then back-calculated costs for Metal and MetalOre). I then went through the parts calculating their cost in RocketParts, the value of those parts, and a markup which varies from 1.1 (structural parts) to 44 (science parts). The workshop is at 25. While writing this I realized that productivity factor should come into the markup (it currently doesn't: it's a flat 25)

If you're curious, take a look at partcost.py in my cfgnode repository.

[Apaseall]

As you can see I took a number of items into account. Mainly I went for the mass per kerbal. What I thought was there seemed to be quite a penalty for low mass per kerbal. That I took with the description to mean that things were rather a tight squeeze. Bonuses for the right equipment if it was designated as a work shop. With smaller bonus for equipment if it was a science lab. I was trying to work on some form of PF per kerbal, plus space bonus plus equipment bonus. Space bonus being tiny or negative for small spaces, determined by the mass per kerbal. Anyway it was more of a curiosity/have I got it right sort of thing. I did try a few equations in a spreadsheet, the first one was way off, the second I used as a guide to see if my PF was way out. I ramble. Thanks for the reply.

Regarding the patches and work I did with the parts. My aim was to remove duplicate parts and use tweakscale. This was only to reduce the number of parts I actually see in the sph or vab. Then I did a little reformatting, brackets mostly. Finally I did not like that everything was named part. I did not get round to renaming the models though. I know squad do or did the whole part/model thing, but I rather like the mods that do not. I made the changes for myself, I keep them in a separate folder. It is not comment on your work, just a sign of my mind lol.

Thanks for the mod, I see you mention you are doing some work for 1.4 KSP? I dropped you these files I guess in a bid to get you to name stuff lol.

vi in linux? old school

Edited March 4, 2018 by Apaseall

[Problemless Mods Wanter]

Hello,

After I click the Finalize button, my main, host ship disappears / separates and I'm left with a resource-less (even though adjusted), uncontrollable craft. If I switch to my main ship from tracking station, the UI still has the Finalize button. If I click, same thing happens again in a loop.

I'm suspecting a few things;

- I'm on a server (DMP)

- Actiong Groups ReExtended mod

- Part count

- Even though I tried to stay flush, I may have inter positioned some of my structors in a way which interferes with the launch pad.

I tried to research my issue on the internet but couldn't exactly find a similar one.

Can anyone tell me if the thing I'm having is a known issue or not. Or whether the mod is incompatible with DMP or AGX or not?

Edited March 4, 2018 by Smart Parts Wanter

[taniwha]

@Apaseall: Your approach seems quite reasonable. Not relevant, but I have issues with Tweak Scale thus why I don't support it.

The part.cfg and model.mu thing is legacy from back when that was (or seemed to be) required, and then a little bit of habit. Newer parts are much more sensibly named.

Heh, vi is nigh on unusable, but vim is pretty nice (first noticeable difference is undo/redo). I've been using Linux for everything for over 20 years now. Before that it was MSDOS and a bit of windows 3.1 and 95 so I could run multiple dos boxes (using DJGPP and an editor I had written myself).

@Smart Parts Wanter: At a guess, I'd say DMP spat the dummy and threw an exception in code being run by EL thus interrupting the finalization process. It's also vaguely possible AGX didn't like something. I have yet to see part count matter. The answer will be in your KSP.log (I am 99.99% confident it's an exception being thrown).

If you are using a launch pad (rather than a survey station), then the lowest part of your built vessel will be clear of the pad (for a survey station, being clear of the ground depends on the ground and how you constructed the site).

That said, just last night I built a ship that spawned overlapping at least one of my gigantor solar panels. I did not notice until I released the ship, it and the station went spinning in opposite directions and there were bits of gigantor floating in space, with one panel embedded in the built ship. The point being that the clipping caused no trouble until the two ships were separated (which comes as a bit of a surprise because they start separated and are joined into one, I guess I do the joining fast enough that the colliders do not get fully activated).

Edited March 4, 2018 by taniwha

[Apaseall]

@Smart Parts Wanter I use Action Groups Extended, which is the same mod with a slightly different name, without any issues.

[taniwha]

@Apaseall: Thanks. That makes DMP prime suspect. I imagine it doesn't like the short-lived vessels EL creates. I know that FAR did not at one stage. It took a lot of convincing from me to get ferram to fix his code. He had a good reason, though: he didn't want to work around bugs in other mods, but I managed to convince him the bug was that he made some unjustified assumptions. I actually agree with his thinking which is why I don't do anything about exceptions in other mods breaking EL. Instead, if I am motivated enough, I go into the problem mod, fix the bug there, and send in a patch .

Edited March 4, 2018 by taniwha

[Problemless Mods Wanter]

13 hours ago, taniwha said:

@Apaseall: Thanks. That makes DMP prime suspect. I imagine it doesn't like the short-lived vessels EL creates. I know that FAR did not at one stage. It took a lot of convincing from me to get ferram to fix his code. He had a good reason, though: he didn't want to work around bugs in other mods, but I managed to convince him the bug was that he made some unjustified assumptions. I actually agree with his thinking which is why I don't do anything about exceptions in other mods breaking EL. Instead, if I am motivated enough, I go into the problem mod, fix the bug there, and send in a patch .

So am I the only one who is trying Extraplanetary Launchpads with DMP? I would have assumed that these two big mods would have been played together by thousands by now. How can one live without these two combined?

Anyways dear @taniwha I'm looking at the log files since yesterday but to be honest can't quite make much of it. It says the vessel is keep being loaded and unloaded. The are also couple of mentionings from some parts and other mods.

Would you be kind enough to take look at it yourself and perhaps translate for me?

[taniwha]

I am very willing to take a look at your logs. That was actually the hint .

[Problemless Mods Wanter]

5 minutes ago, taniwha said:

I am very willing to take a look at your logs. That was actually the hint .

Great! =D How can I send them to you, shall I paste the whole thing or the parts where I'm trying EL, just here?

[Problemless Mods Wanter]

Here, I uploaded the 60mb file to here https://ufile.io/2z9xu

If it's gonna be helpful, search for " Yörünge Fırlatma Sahası " that's the name of the ship and you can look around LOG 18:20~35. It's around time 18:20 - 18:35 where I'm trying.

If you figure out what is happening, please do tell us.

[taniwha]

It looks like OLDD_camera is throwing a lot of  exceptions when parts are destroyed by the drag cube system. I suggest passing your log onto that dev.

Only problem is that the exceptions are in an event handler and KSP catches those to prevent their effects spreading.

[Problemless Mods Wanter]

1 hour ago, taniwha said:

It looks like OLDD_camera is throwing a lot of  exceptions when parts are destroyed by the drag cube system. I suggest passing your log onto that dev.

Only problem is that the exceptions are in an event handler and KSP catches those to prevent their effects spreading.

I wasn't expecting this mod at all... interesting...

I notified the dev. of that mod. Thank you so much for sparing time to help me solve this.

[taniwha]

I don't know if fixing that mod will fix this problem, but it will help clean up the log making it easier to figure things out.

[taniwha]

Just a post 1.4-release status update...

EL seems to be largely unaffected, just some Unity deprecations I had to clean up, but I need to do careful testing, make sure there aren't any hidden surprises. Also, I have a pile of save-breaking changes in the works and I don't want to cause too much trouble with them.