[1.12] Extraplanetary Launchpads v6.99.3

[cgwhite4]

Xavier Laxworm: After finalizing the build but before releasing the vessel, try adding fuel to the system so that you are full even with the tanks on the vessel you are building.  If you are operating on the surface of a celestial object (like I am) and attached to a mining rig with drills and an ISRU, use these to top yourself off before releasing.  The system will have no choice but to give the constructed vessel a full tank of fuel when you release (because there will be nowhere else for the fuel to go).  If you are operating in orbit, you will probably need to dock with a fuel tanker (or multiple tankers depending on fuel capacity of tanker and constructed vessel), transfer fuel from the tanker(s) to the tanks on your constructed vessel, and then undock from the tanker (so its tanks can't work against you).  Make sure all fuel tanks on the constructed vessel and anything attached to your orbital dock are full before releasing, or the fuel will likely end up transferred to any non-full tanks not on your vessel.

I have used this procedure (specifically, the surface variant of it) for all launches not from Kerbin, and have even had 1 successful mission from a launchpad since KSP 1.2 came out.

[taniwha]

3 hours ago, Xavier Laxworm said:

I can build things but when you finallize builds on an orbital dock or launchpad, no fuel is transferred.

The transfer is done when you release, not when you finalize. The finalize button is there only to prevent the build from happening automatically.

6 hours ago, Dr. Jet said:

Confirmative: augers are broken. 

I'll take a look at them.

6 hours ago, Dr. Jet said:

Question: Why not to use stock deploying drills models and ModuleResourceHarvester for MetalOre harvesting? It will solve major half of the problems.

Because ModuleResourceHarvester does not do what I want (support Kethane). However, ExExtractor does use the same base classes as ModuleResourceHarvester, so it's probably just some fine detail have changed (or the usual problem: PEBCAK).

[Dr. Jet]

13 hours ago, taniwha said:

Because ModuleResourceHarvester does not do what I want (support Kethane). However, ExExtractor does use the same base classes as ModuleResourceHarvester, so it's probably just some fine detail have changed (or the usual problem: PEBCAK).

Well, using stock MODELS along with your ExExtractor module will solve at least problems with deployment (lack of it) and surface detection.

BTW, stock drills already DO mine MetalOre - as a part of asteroid mining function (they mine everything that exists on asteroid as long as vehicle has free tanks for it).

Edited October 17, 2016 by Dr. Jet

[Tarheel1999]

@taniwha I have a question about modifying recipes.  I've looked at both the OP and the documentation included in the download and couldn't find the answer (or missed it I guess).  At what point during the KSP loading process does any modifications to EL_DefaultStructureRecipe and EL_ResourceRecipe have to occur. For example if I make a patch modifying both of those recipes with a NEEDS[LaunchPad] will that work? Or does the EL_DefaultStructureRecipe node need to be in the game database before EL loads. Thanks.

[taniwha]

Tarheel1999: I have no idea, really. EL inserts itself between MM and the part loader, so I would think it wouldn't matter.

That said, if you can create an use EL_DefaultStructureRecipe by hand, I would expect it to work with MM.

This is one of those areas that hasn't had good testing yet, but since EL_KerbalRecipe works, I expect EL_DefaultStructureRecipe to.

If that's a little incoherent, I'm sorry: it's 0:14 and I need to get to bed.

[Johnny Appleseed]

Is anyone else having a problem getting EL in ckan? It is not showing up as an available yet.

[goldenpsp]

12 minutes ago, Johnny Appleseed said:

Is anyone else having a problem getting EL in ckan? It is not showing up as an available yet.

Wouldn't know, don't use it.  Taniwha has stated in the past he doesn't manage the CKAN metadata.  Maybe ask the CKAN people.

[Tarheel1999]

1 hour ago, taniwha said:

Tarheel1999: I have no idea, really. EL inserts itself between MM and the part loader, so I would think it wouldn't matter.

That said, if you can create an use EL_DefaultStructureRecipe by hand, I would expect it to work with MM.

This is one of those areas that hasn't had good testing yet, but since EL_KerbalRecipe works, I expect EL_DefaultStructureRecipe to.

If that's a little incoherent, I'm sorry: it's 0:14 and I need to get to bed.

It looks like we found the solution in the USI-MKS thread.  Recipes can be altered with:

@EL_ResourceRecipe[TYPE]:NEEDS[Launchpad] {RECIPE}

Using this you can overwrite EL's recipes.  To change the default recipe you need to use:

EL_DefaultStructureRecipe {RECIPE}

I am assuming this is because EL never defines EL_DefaultStructureRecipe. 

[taniwha]

4 hours ago, Tarheel1999 said:

I am assuming this is because EL never defines EL_DefaultStructureRecipe. 

This would be correct (mostly: there is a hard-coded definition that gets replaced if there's a definition in config files)

For those having trouble with the augers: I haven't tested in 1.2 yet, but do make sure the tip of the auger is actually in the ground. If at least 1/4 (to be certain, actually much less) of the drill is in the ground, it very definitely should work. Just because there's no deploy animation doesn't mean there aren't physical conditions that must be met.

[edit]A little tip: I have carried an auger to the site exactly twice: once flying (KSP 0.20), once driving (KSP 0.21). All other times, I have built the drilling (and smelting) module on-site, even before EL had survey builds.

Edited October 17, 2016 by taniwha

[Murdabenne]

Hint: you might want to ask CKAN questions in the CKAN thread.
 

 

Edited October 17, 2016 by Murdabenne

[cgwhite4]

I tried retracting the landing gear on the module of my base containing the two augers, resulting in that module's engine bell acting as landing gear and putting the drills slightly further into the ground.  Unfortunately, this had no discernable effect, and to get them any lower, I would have to somehow cause the "rapid unscheduled disassembly" of that module's engine, directly above which is a fuel tank, and that base's fuel tanks are all full.  I should also note that whether that module is on its landing legs or on its bell, a non-zero metal ore rate is indicated above the word "stalled", but the main Metal Ore resource bar indicates a rate of zero and does not move.

[taniwha]

11 hours ago, cgwhite4 said:

I should also note that whether that module is on its landing legs or on its bell, a non-zero metal ore rate is indicated above the word "stalled", but the main Metal Ore resource bar indicates a rate of zero and does not move.

Somebody should have mentioned that in the first place, as that is useful information. I've reproduced it. I'll poke to see what's changed (unfortunately, I have not found any indication of why the auger is stalled)

[Johnny Appleseed]

15 hours ago, Murdabenne said:

Hint: you might want to ask CKAN questions in the CKAN thread.
 

 

Yes yes, I get it already. I only asked here first as this is the only mod that was not showing up. All the other mods i use are already there. So before i go to CKAN and say "hey, whats up with EL?" and get told to shove off to the EL thread. I thought i'd ask the the ever friendly bunch in EL if i was only one having the issue. That said no one has replied. I will extrapolate from that: no one here uses CKAN or no one here is having that problem. Thank you very much, you have all been very helpful. Thanks for the link to, you have saved me a search of the forum.

[taniwha]

I have released version 5.5.1 of Extraplanetary Launchpads.

Changes from 5.5.0:

• Add support for specifying the flow mode for extractors, defaulting to ALL_VESSEL.
• As a result, fix the stalled augers.

 

[Johnny Appleseed]

Woop Woop! Thanks

 

[cgwhite4]

5.5.1 installed, augers back online.

[Murdabenne]

There is why I posted that - sorry if the tone is a bit offputting, its ahrd to carry tone in text.  This thread and mod, like almost all mods, have NOTHING to do with CKAN.  Asking here about CKAN is about the same as asking here about MechJeb.  Nothing done here has any effect on CKAN. Here is how it works: CKAN is its own app, they have the metadata, they use the metadata to generate entries in their database, they periodically scan their metadata for changes, then scan the database for changes.  They have a Jenkins build system that periodically rebuilds the data base, and posts it to their server, which your client queries. All that takes time, and depends on then the new metadata is posted, when the cron jobs re run, when the new database builds are triggered, etc. Sometimes the author posts metadata as a convenience, but often the metadata is maintained by volunteers with the CKAN group.  Notice how nothing in there regarding how quickly CKAN works is in the control of the mod's author - its all CKAN?

The reason why I am going on about this is that continued bothering of the authors with CKAN questions nearly got CKAN banned (by licensing terms) from being able to carry metadata and easy access to some apps/mods.  So please understand why one shouldn't post CKAN questions to mod threads.

 

Edited October 19, 2016 by Murdabenne
clarification

[ss8913]

17 hours ago, Johnny Appleseed said:

Yes yes, I get it already. I only asked here first as this is the only mod that was not showing up. All the other mods i use are already there. So before i go to CKAN and say "hey, whats up with EL?" and get told to shove off to the EL thread. I thought i'd ask the the ever friendly bunch in EL if i was only one having the issue. That said no one has replied. I will extrapolate from that: no one here uses CKAN or no one here is having that problem. Thank you very much, you have all been very helpful. Thanks for the link to, you have saved me a search of the forum.

I use CKAN, also not seeing this or taniwha's other great mod (modular fuel tanks) (he may have others lol) ... anyway, taniwha told me that he doesn't CKAN anything, that other people have in the past, and.. pretty much what he said this time, talk to the CKAN folks; I have not yet done so, however.

[Johnny Appleseed]

Thank you for the replies, i understand the situation a little better now. I don't understand all the politics there seems to be, but at least i know why it is not there anymore. I'll just have to wait for it it show up. Having had it finally working just before the update i would rather duplicate the setup then struggle again.

[Fendrin]

Hello, while adding Launchpad capabilities to a part I wonder how to use the "SpawnTransform" field properly. "SpawnHeightOffset" is not enough, the ship is facing in the wrong direction. SpawnTransform seems to be of type string? Is it the id of some node?

[taniwha]

@Fendrin: That sort of info is already in the documentation^* (page 12 in 5.5.1), but yes, SpawnTransform is a string, and it specified the name of a transform within the model.

^*It seems I should add type info.

[Fendrin]

8 minutes ago, taniwha said:

@Fendrin: That sort of info is already in the documentation^* (page 12 in 5.5.1), but yes, SpawnTransform is a string, and it specified the name of a transform within the model.

^*It seems I should add type info.

Yes, I have found the documentation, it just does not help me a lot. It seems that there are no files available other than the ".mu" one. I guess that means I can't fix that part to work with this mod, right?

[TopHeavy11]

Glad to see it's updated to 1.2!

[taniwha]

@Fendin: No, the .mu file and the .cfg file are all that is necessary (plus textures, of course). Using hierachy.py (needs mu.py) can be used to find all the transform names in the model (just the simple name is needed, not the full path). Assuming, of course, there is a suitable transform in the model. If there is not, using MODEL nodes (details unknown to me) and this model (just an empty model NathanKell needed to add thrust transforms to existing parts) is one solution, or I can help hack the .mu directly (using my mu tools)

[Fendrin]

There is a "LaunchNode" in the mu file specified. It seems to point into the wrong direction. I can load the mu file into Blender using your plugin. But I can't export it, I run into the fog problem and Blender is completely new and just huge to me. So even if exporting would work I am not able to change the vector of the node yet.

Thus I gladly accept your help with modifying the file. It is at https://github.com/bartblommaerts/warpship/blob/master/Installation/GameData/WarpShip/Parts/Spacedock_Small/Spacedock_Small.mu. I am not firm with gimp and artwork but I am good at coding and scripting. There is also a bigger and an even bigger version of the SpaceDock, all with their own mu files. I guess a scripted solution could handle all 3 files in one approach.

edit: Got it working properly. Sorry for wasting your time. It was called "LaunchPos" and addressing it correctly did the trick. Thanks for your help :-)

Edited October 19, 2016 by Fendrin