[1.12] Extraplanetary Launchpads v6.99.3

[gamerscircle]

34 minutes ago, goldenpsp said:

Last I recall reading is the source is up on github if you want to compile yourself.  I am pretty sure Taniwha has not release a compiled new version yet.

Just up a couple of post, is this:

 

[goldenpsp]

2 minutes ago, gamerscircle said:

Just up a couple of post, is this:

 

Yea, and is that the build you are using?  That is one maxrebo compiled himself. 

[gamerscircle]

14 minutes ago, goldenpsp said:

Yea, and is that the build you are using?  That is one maxrebo compiled himself. 

Yes, that is the one that I am using.   This one does or doesn't work?

[MaxRebo]

2 hours ago, gamerscircle said:

Yes, that is the one that I am using.   This one does or doesn't work?

I just tried myself (in sandbox), and building ships does work for me. Are you sure your productivity is > 0? I can't really tell what module that 1 sole Kerbal is sitting in, so that might be an issue.

FYI I'm also using MKS like you do so I think we can exclude that being the culprit...

Edited July 1, 2016 by MaxRebo

[gamerscircle]

HI @MaxRebo thank you for trying it out and I completely forgot about the level of Engineer needed.,  Thank you again..

[MaxRebo]

@gamerscircle No problem

[gamerscircle]

8 minutes ago, MaxRebo said:

@gamerscircle No problem

As a follow up, if I have the MKS launchpad and a level 1 eng - that will work.. correct?

[MaxRebo]

3 minutes ago, gamerscircle said:

As a follow up, if I have the MKS launchpad and a level 1 eng - that will work.. correct?

It should. AFAIK only level 0 engineers need a workshop to generate productivity.

[kraden]

I thought they needed to be level 2... perhaps I'm mistaken? Regardless my orbital station just pumped out a ship using this mod.  Had 4 level 2s working on it.  Running 1.1.3 with MaxRebo's fix.

Edited July 2, 2016 by kraden

[Agnemon]

@kraden and @gamerscircle

On 22/6/2016 at 9:53 PM, Agnemon said:

I have created a flow chart of the EL process which maybe of some use to newcomers

https://www.dropbox.com/s/o604qxf4qsmexgm/EL Flow Chart.jpg?dl=0

see if this helps

[kraden]

3 hours ago, Agnemon said:

 

see if this helps

Forgot you posted that.  Thanks! 

[MaxRebo]

13 hours ago, kraden said:

Running 1.1.3 with MaxRebo's fix.

Just to be clear, I didn't fix anything. Taniwha made the necessary adjustments himself. I merely compiled from the bleeding edge github source, which didn't yet make it to an official release.

[gamerscircle]

1 hour ago, MaxRebo said:

Just to be clear, I didn't fix anything. Taniwha made the necessary adjustments himself. I merely compiled from the bleeding edge github source, which didn't yet make it to an official release.

<snort> bleeding edge... thanks for doing it though.

[maranble14]

Can anybody give me a clue as to why this kraken happened? lol

[Dr Farnsworth]

I am having parts spawn off to the side 90 deg. from how they should be oriented. They are not oriented or positioned correctly between the survey stakes. 

Plus, it is instantly building them and not using any rocket parts. Has anyone else been getting these errors?

[taniwha]

maranble14: your surveyor did a poor job: the slope of the land was not taken into account and the build spawned partially in the ground. My recommendation is to use a -Y bounds stake to mark the height of the lowest part of the build. The -Y bounds stake should be uphill from the actual build site. It is easiest if appropriate X and Z bounds stakes are used to mark out the uphill corner of the build instead of relying on an origin stake to mark the location of the root part.

Stakes have two modes with seven settings in each mode (default is Direction:Origin):

• Direction: these are used to control the orientation of the build.
  • Origin: used to mark the location above which the build's root part will be placed, and also forms the reference point for other direction stakes that aren't in pairs.
  • -X and +X: used to specify the lateral (port (-X) and starboard (+X))  axis of the build (both VAB and SPH). If both -X and +X are used, then the origin is is ignored, otherwise the axis runs from -X to origin or origin to +X.
  • -Y and +Y: used to specify the "vertical" axis of the build (relative to the floor in the VAB or SPH). If both -Y and +Y are used, then the origin is is ignored, otherwise the axis runs from -Y to origin or origin to +Y. NOTE: not recommended, very advanced usage.
  • -Z and +Z: used to specify the ventral (VAB) or fore/aft (SPH) axis of the build. If both -Z and +Z are used, then the origin is is ignored, otherwise the axis runs from -Z to origin or origin to +Z.
  • If none of the axis direction stakes are used, then the default orientation is such that the build's +Y axis is the local up,  +X axis points east, and +Z points south (same as on the KSC launchpad).
  • If the axes marked out by the stakes are not perfectly orthogonal, then the build will be oriented such that the errors are balanced.
• Bounds: these are used to control the placement of the build based on its bounding box rather than its root part.
  • Origin: used to mark the location of the root part along any axis that has not been bound.
  • -X and +X: used to mark the lateral (port (-X) and starboard (+X))  edges of the build. If only one of -X or +X is used, then that edge of the build will be exactly on that stake, otherwise the the X-axis center of the build's bounding box will be centered on the midpoint between the two stakes.
  • -Y and +Y: used to mark the "vertical"  edges of the build. If only one of -Y or +Y is used, then that edge of the build will be exactly on that stake, otherwise the the Y-axis center of the build's bounding box will be centered on the midpoint between the two stakes. NOTE: use of the +Y bounds stake is not recommended unless you know what you are doing.
  • -Z and +Z: used to mark the ventral (VAB) or fore/aft (SPH) edges of the build. If only one of -Z or +Z is used, then that edge of the build will be exactly on that stake, otherwise the the Z-axis center of the build's bounding box will be centered on the midpoint between the two stakes.
• Bounds stakes and direction stakes work together: any unbound axis of the build slides along that axis of the reference frame created by the direction stakes (or the default frame if no direction stakes are used).
• There is actually only one origin stake: there is no difference between a bounds origin stake and a direction origin stake. The appearance of there being two origin stakes is due to the overly simple controls.
• If multiple stakes of the same type+setting have been placed, then they will be averaged together to form a virtual stake of the same type+setting. This can be very useful with multiple origin stakes to avoid the build clipping into the stake when the lowest part of the build is directly below the root part.
• If no origin stakes have been placed, then the average of all other stakes is used as the origin point.
• The actual location of the stakes is about 19cm above the ground.
• If no Y bounds stake has been placed, then the origin acts as an implicit -Y bounds stake (otherwise almost all builds would spawn in the ground).

I hope this helps a bit. I plan on putting something like that in the documentation.

15 minutes ago, Dr Farnsworth said:

I am having parts spawn off to the side 90 deg. from how they should be oriented. They are not oriented or positioned correctly between the survey stakes. 

Plus, it is instantly building them and not using any rocket parts. Has anyone else been getting these errors?

This is a sign of an exception being thrown by some addon when EL loads the vessel to check its build cost. In the past, Science Alert was the culprit (thus the message in the OP). If you send me your KSP.log, I can take a look to find out which one.

Edited July 3, 2016 by taniwha

[linuxgurugamer]

On 6/29/2016 at 3:47 AM, MaxRebo said:

@gamerscircleGithub is really easy, and there are lots of tutorials out there. Or do you mean Git itself? Well, same thing applies there. BUT. Neither Github nor Git are the problem. Getting Taniwha's build tree to correctly build and install under Windows requires some trickery and magic, short of using Cygwin (which I refuse to do; anything that doesn't build under MSYS out-of-the-box has an inadequate build system - period). It would simply not be very productive to describe the intricacies of solving the various problems that came up.

So I decided to just do it myself and leave it here:

[1.1.3] ExtraplanetaryLaunchpads-v5.3.2.git#f2d3f73.zip

My career isn't quite at the point where I really use it, so I didn't do extensive testing. No refunds.

So, is the original maintainer still working on this?

Also, did you just recompile on Windows?  Visual Studio?

[Dr Farnsworth]

17 minutes ago, taniwha said:

maranble14: your surveyor did a poor job: the slope of the land was not taken into account and the build spawned partially in the ground. My recommendation is to use a -Y bounds stake to mark the height of the lowest part of the build. The -Y bounds stake should be uphill from the actual build site. It is easiest if appropriate X and Z bounds stakes are used to mark out the uphill corner of the build instead of relying on an origin stake to mark the location of the root part.

Stakes have two modes with seven settings in each mode (default is Direction:Origin):

• Direction: these are used to control the orientation of the build.
  • Origin: used to mark the location above which the build's root part will be placed, and also forms the reference point for other direction stakes that aren't in pairs.
  • -X and +X: used to specify the lateral (port (-X) and starboard (+X))  axis of the build (both VAB and SPH). If both -X and +X are used, then the origin is is ignored, otherwise the axis runs from -X to origin or origin to +X.
  • -Y and +Y: used to specify the "vertical" axis of the build (relative to the floor in the VAB or SPH). If both -Y and +Y are used, then the origin is is ignored, otherwise the axis runs from -Y to origin or origin to +Y. NOTE: not recommended, very advanced usage.
  • -Z and +Z: used to specify the ventral (VAB) or fore/aft (SPH) axis of the build. If both -Z and +Z are used, then the origin is is ignored, otherwise the axis runs from -Z to origin or origin to +Z.
  • If none of the axis direction stakes are used, then the default orientation is such that the build's +Y axis is the local up,  +X axis points east, and +Z points south (same as on the KSC launchpad).
  • If the axes marked out by the stakes are not perfectly orthogonal, then the build will be oriented such that the errors are balanced.
• Bounds: these are used to control the placement of the build based on its bounding box rather than its root part.
  • Origin: used to mark the location of the root part along any axis that has not been bound.
  • -X and +X: used to mark the lateral (port (-X) and starboard (+X))  edges of the build. If only one of -X or +X is used, then that edge of the build will be exactly on that stake, otherwise the the X-axis center of the build's bounding box will be centered on the midpoint between the two stakes.
  • -Y and +Y: used to mark the "vertical"  edges of the build. If only one of -Y or +Y is used, then that edge of the build will be exactly on that stake, otherwise the the Y-axis center of the build's bounding box will be centered on the midpoint between the two stakes. NOTE: use of the +Y bounds stake is not recommended unless you know what you are doing.
  • -Z and +Z: used to mark the ventral (VAB) or fore/aft (SPH) edges of the build. If only one of -Z or +Z is used, then that edge of the build will be exactly on that stake, otherwise the the Z-axis center of the build's bounding box will be centered on the midpoint between the two stakes.
• Bounds stakes and direction stakes work together: any unbound axis of the build slides along that axis of the reference frame created by the direction stakes (or the default frame if no direction stakes are used).
• There is actually only one origin stake: there is no difference between a bounds origin stake and a direction origin stake. The appearance of there being two origin stakes is due to the overly simple controls.
• If multiple stakes of the same type+setting have been placed, then they will be averaged together to form a virtual stake of the same type+setting. This can be very useful with multiple origin stakes to avoid the build clipping into the stake when the lowest part of the build is directly below the root part.
• If no origin stakes have been placed, then the average of all other stakes is used as the origin point.

I hope this helps a bit. I plan on putting something like that in the documentation.

This is a sign of an exception being thrown by some addon when EL loads the vessel to check its build cost. In the past, science alert was the culprit (thus the message in the OP). If you send me your KSP.log, I can take a look to find out which one.

How would you like for me to get the log file to you?

[taniwha]

zipped and put on Dropbox, pastebin, or a similar place.

[maranble14]

26 minutes ago, taniwha said:

maranble14: your surveyor did a poor job: the slope of the land was not taken into account and the build spawned partially in the ground. My recommendation is to use a -Y bounds stake to mark the height of the lowest part of the build. The -Y bounds stake should be uphill from the actual build site. It is easiest if appropriate X and Z bounds stakes are used to mark out the uphill corner of the build instead of relying on an origin stake to mark the location of the root part.

Stakes have two modes with seven settings in each mode (default is Direction:Origin):

• Direction: these are used to control the orientation of the build.
  • Origin: used to mark the location above which the build's root part will be placed, and also forms the reference point for other direction stakes that aren't in pairs.
  • -X and +X: used to specify the lateral (port (-X) and starboard (+X))  axis of the build (both VAB and SPH). If both -X and +X are used, then the origin is is ignored, otherwise the axis runs from -X to origin or origin to +X.
  • -Y and +Y: used to specify the "vertical" axis of the build (relative to the floor in the VAB or SPH). If both -Y and +Y are used, then the origin is is ignored, otherwise the axis runs from -Y to origin or origin to +Y. NOTE: not recommended, very advanced usage.
  • -Z and +Z: used to specify the ventral (VAB) or fore/aft (SPH) axis of the build. If both -Z and +Z are used, then the origin is is ignored, otherwise the axis runs from -Z to origin or origin to +Z.
  • If none of the axis direction stakes are used, then the default orientation is such that the build's +Y axis is the local up,  +X axis points east, and +Z points south (same as on the KSC launchpad).
  • If the axes marked out by the stakes are not perfectly orthogonal, then the build will be oriented such that the errors are balanced.
• Bounds: these are used to control the placement of the build based on its bounding box rather than its root part.
  • Origin: used to mark the location of the root part along any axis that has not been bound.
  • -X and +X: used to mark the lateral (port (-X) and starboard (+X))  edges of the build. If only one of -X or +X is used, then that edge of the build will be exactly on that stake, otherwise the the X-axis center of the build's bounding box will be centered on the midpoint between the two stakes.
  • -Y and +Y: used to mark the "vertical"  edges of the build. If only one of -Y or +Y is used, then that edge of the build will be exactly on that stake, otherwise the the Y-axis center of the build's bounding box will be centered on the midpoint between the two stakes. NOTE: use of the +Y bounds stake is not recommended unless you know what you are doing.
  • -Z and +Z: used to mark the ventral (VAB) or fore/aft (SPH) edges of the build. If only one of -Z or +Z is used, then that edge of the build will be exactly on that stake, otherwise the the Z-axis center of the build's bounding box will be centered on the midpoint between the two stakes.
• Bounds stakes and direction stakes work together: any unbound axis of the build slides along that axis of the reference frame created by the direction stakes (or the default frame if no direction stakes are used).
• There is actually only one origin stake: there is no difference between a bounds origin stake and a direction origin stake. The appearance of there being two origin stakes is due to the overly simple controls.
• If multiple stakes of the same type+setting have been placed, then they will be averaged together to form a virtual stake of the same type+setting. This can be very useful with multiple origin stakes to avoid the build clipping into the stake when the lowest part of the build is directly below the root part.
• If no origin stakes have been placed, then the average of all other stakes is used as the origin point.
• The actual location of the stakes is about 19cm above the ground.
• If no Y bounds stake has been placed, then the origin acts as an implicit -Y bounds stake (otherwise almost all builds would spawn in the ground).

I hope this helps a bit. I plan on putting something like that in the documentation.

This is a sign of an exception being thrown by some addon when EL loads the vessel to check its build cost. In the past, Science Alert was the culprit (thus the message in the OP). If you send me your KSP.log, I can take a look to find out which one.

Thank you for the detailed info! It is much appreciated! I will take that into account from now on when I build off planet
 

[taniwha]

I have released 5.4.0 of EL. I haven't done much testing myself, so I'm relying on the testing done by others using Max Rebo's build (thank you!). This makes EL compatible with KSP 1.1.3 and includes the very very WIP documentation (pdf).

Changes from 5.3.2:

• Updated to work with KSP 1.1.3.
• Rudimentary documentation included (EL_Manual.pdf)
• Recycler resource transfer reworked to avoid problems caused by rounding errors.
• Recycler state properly restored from save files (note: for in-progress recycling, not whether the recycler is active: that's a safety feature).

The documentation is written using LyX. It will eventually get diagrams and such. It is for both users and modders.

Edited July 3, 2016 by taniwha

[linuxgurugamer]

33 minutes ago, taniwha said:

I have released 5.4.0 of EL. I haven't done much testing myself, so I'm relying on the testing done by others using Max Rebo's build (thank you!). This makes EL compatible with KSP 1.1.3 and includes the very very WIP documentation (pdf).

I'll edit this post with the release notes when I've got time (need to go out with the family).

Thank you

[JohanMax]

On 2016-07-01 at 5:47 PM, taniwha said:

In what way is it not working?

Activated recycler, got both workshop and a smelter on station as well, drive ship to be scrapped into recycler. Nothing happens. Normally this is where the ship would be "deleted" and scrapmetal show up in the smelter.. I can still turn on and off recycler, and set it as target and everything else. Just, nothing happens.

Anyway, just tested 5.4.0, and recycler seems to work again for me, a bit slow when it "eats" a ship but maybe this is a new thing? I dunno, but I could watch each bit of the ship vanish as it cycled through it. Also I noted it became Metal directly, so I assume the scrapmetal step is deprecated?

[taniwha]

JohanMax: I'm glad 5.4.0 is working for you (it does have recycler fixes in it). The gradual "eating" of the recycled vessel has been there for a while (since KSP 1.0). Recycling bins have never gone to scrap metal (though I do want to make them do so, I just haven't gotten around to it).

[taniwha]

Dr Farnsworth: Thank you for the log file: as I suspected, a buggy part(?) module:

[EXC 17:13:04.909] NullReferenceException: Object reference not set to an instance of an object
        PersistentRotation.Main.OnVesselWillDestroy (.Vessel vessel)
        EventData`1[Vessel].Fire (.Vessel data)
        Vessel.Die ()
        ExtraplanetaryLaunchpads.ExBuildControl.getBuildCost (.ConfigNode craft)

It looks like Persistent Rotation does not like the vessel being destroyed in the same frame in which it was created. I suggest taking it up with Persistent Rotation's developer (if need be, send him my way).

Edited July 3, 2016 by taniwha