[1.0.4] ESLD Jump Beacons - [Dev 0.6a]

[MarcAlain]

Perhaps the dev could build in a switch in the VAB that selects what the beacon is to be refueled by.

[rasta013]

I've just started using this as I prefer the idea over the Alcubierre magic drives that just seem way to easy to use. That said, I've also restarted in sandbox as well and have been considering how to get to the extremely difficult to obtain Karborundum and have another idea. Using ModuleResourceConverter, karbonite and a quick little MM patch you can add the conversion of whatever you want in Karborundum. Here's an example of what you can do and I personally utilize the Karbonite 2.5m converter:

@PART[KA_Converter_250_01]

{

MODULE

{

name = ModuleResourceConverter

ConverterName = Karborundum

StartActionName = Start ISRU [Karborundum]

StopActionName = Stop ISRU [Karborundum]

AutoShutdown = false

GeneratesHeat = false

UseSpecialistBonus = true

SpecialistEfficiencyFactor = 0.1

SpecialistBonusBase = 0.05

Specialty = Scientist

EfficiencyBonus = 1

INPUT_RESOURCE

{

ResourceName = Karbonite

Ratio = .5

FlowMode = STAGE_PRIORITY_FLOW

}

INPUT_RESOURCE

{

ResourceName = LH2

Ratio = 70.5

FlowMode = STAGE_PRIORITY_FLOW

}

INPUT_RESOURCE

{

ResourceName = ElectricCharge

Ratio = 300

}

OUTPUT_RESOURCE

{

ResourceName = Karborundum

Ratio = .001

DumpExcess = false

FlowMode = STAGE_PRIORITY_FLOW

}

}

}

This gives a conversion rate of ~3.6 Karborundum/hour but will use an immense amount of karbonite, LH2, power and time to generate significant quantities. It's also slow enough and demanding enough of input resources that you'll likely be using it at a base location instead of toting it around with you. I produce my LH2 from Ore using the ISRU already and adding in this little bit makes it nearly impossible to give a portable implementation of this conversion process. This is just one example of how you could setup a conversion process to make it easier to obtain but still requiring you to setup an infrastructure to support it. Obviously, this is meant to add in elements for a sandbox game and would make a career far to easy to exploit but it is something to use.

[MarcAlain]

If one jumps to a beacon, do they have to worry about their origin velocity or angle? Or do they take on the vector of the orbiting beacon?

[MarcAlain]

If one jumps to a beacon, do they have to worry about their origin velocity or angle? Or do they take on the vector of the orbiting beacon?

Nevermind, figured it out This mod is exactly what I've been looking for! It would even allow my "primitive" nuclear and xenon powered spacecraft to still be viable after the the breakthrough to warp technology.

Is there a way to adjust how much karbondrum is used when you jump via the configs?

Edited August 13, 2015 by MarcAlain

[TMarkos]

Nevermind, figured it out This mod is exactly what I've been looking for! It would even allow my "primitive" nuclear and xenon powered spacecraft to still be viable after the the breakthrough to warp technology.

Is there a way to adjust how much karbondrum is used when you jump via the configs?

Not easily, no. The fuel usage is defined by some hardcoded equations in the mod dll.

It would be easier to just make karborundum more available, which is easily accomplished by downloading the configs in the extras folder off of either Kerbalstuff or Github. There are configs that let you add Karborundum to Tylo, Dres and Ike, as well as one that just makes it tweakable in the VAB. You may also consider using K+ or FTT, which add more storage and acquisition options for fuel. Specifically, FTT has a huge whopping karborundum tank and K+ has some new extraction tools, various tanks and a solar collector.

[Nupol]

Yesterday i created a Thread and asked for some help on a KSP Stargate. hab136 suggested I should ask here because it is essential the same thing like a Stargate.

I am a total noob at scripting and only can model / texture the assets and maybe add some animations.

I would be pleased to work in co-operation with you.

regards

Edited August 25, 2015 by Nupol

[TMarkos]

Yesterday i created a Thread and asked for some help on a KSP Stargate. hab136 suggested I should ask here because it is essential the same thing like a Stargate.

I am a total noob at scripting and only can model / texture the assets and maybe add some animations.

I would be pleased to work in co-operation with you.

regards

That's a cool-looking model, although it looks more like the Tollan gate due to no symbols around the rim.

Unfortunately you may have been given some false optimism, I note the person who sent you here said I had basically written the code already but that's not quite the case. It's true that my mod has the script you need to do point-to-point transit arbitrated by vehicles you're not currently flying, as well as things like line-of-sight checking and gravity wells and whatnot.

What I don't have is the code that would let you know if a ship has gone through the gate or not, which is actually surprisingly hard to do. How do you define "through"? Is it as soon as any part contacts the event horizon? Is it when the center of mass is through? Figuring out the absolute coordinates of all the parts on a ship relative to the stargate is doable, but not easy. How do you detect ships that fit or won't fit through the gate and handle it appropriately? These questions involve analyzing the geometry and layout of the two vessels, which is much, much more complex than simply transposing it to another point in space. You're not the first one to think of a stargate mod, nor the first to try to adapt my code to it, but nobody that I'm aware of has made it past that hurdle.

Now that I've got the PSA out of the way, though, please don't let me discourage you from trying. You have an excellent model and I don't mean to imply that the challenge is insurmountable - just that it would get pretty complex, so you should know what you're getting into. You're welcome to any code you want from my projects and I'd be happy to explain my shoddy comments or lend advice if you get stuck. You might also take a look at RoverDude's alcubierre drive for the event horizon, he made a cool-looking transparent bubbly thing for his drive and it strikes me that some of the same techniques might lend themselves to making a cool-looking event horizon within the gate.

[Nupol]

Thank you for your answer and explanation. After reading your post i thought about something simpler than how a classic stargate works. Since my version is a fictional version of a fictional stargate () It dont has to be working like a classic one. Just fly the ship inside. Maybe the gate recognizes a active vessel in a certain range (doesnt matter how big the ship is) then you can activate the jump to another gate and the vessel will be teleported near the other stargate. But as i said i am a total noob at scripting so i dont know if this could be done easily.

regards

[hab136]

Unfortunately you may have been given some false optimism, I note the person who sent you here said I had basically written the code already but that's not quite the case. It's true that my mod has the script you need to do point-to-point transit arbitrated by vehicles you're not currently flying, as well as things like line-of-sight checking and gravity wells and whatnot.

As the referrer, I considered that the hard part. I'm very impressed with ESLD!

How do you define "through"? Is it as soon as any part contacts the event horizon?

Easy answer: Yes. Touching the event horizon is the easiest method (just check for a collision): https://github.com/taniwha-qf/Extraplanetary-Launchpads/blob/master/Source/Recycler/Recycler.cs#L73-L84

It's also visually the best, unless you could find a way to hide the ship coming out the other side.

Hard but best answer: Look for the sequence of: CoM of ship is on "front side", CoM is within 1 m of plane of stargate (passing through), CoM of ship is on "back side", all parts are now on "back side". If CoM goes back to "front side" (they backed out after poking in part way), then start checks from beginning.

Hiding the ship on the other side: TextureReplacer has apparently figured out reflections; some clever application of that same system could show the space behind where the ship would be in order to hide it. You'd have a large square plane of reflection, that would "reflect" what was 500m behind it ("behind" being away from the camera).

However even if you did hide the ship, what would you do about IVA? Easy - make a "barrel of blue" that extends from the Stargate on the other side. Just a visual cylinder (no need for collision mesh, but it would be okay if it had one) with the event horizon texture. That way if anyone looks in IVA, they'll just see the event horizon in every direction.

Here's my terrible MS paint diagram (note that the reflection plane should be between the "back side" of the gate and the "barrel of blue", thus hiding it):

How do you detect ships that fit or won't fit through the gate and handle it appropriately?

Easy answer: don't. If the user transports a 500 m wide ship through a 20 m wide gate, that's their problem.

Medium but unrealistic answer: make an invisible collision mesh cylinder that extends from the front of the stargate, so that ships have to fit to reach the event horizon.

Medium but dangerous answer: https://github.com/BobPalmer/WarpDrive/blob/master/Source/WarpEngine/WarpEngine/USI_ModuleWarpEngine.cs#L440-L460

The Alcubierre warp drive makes a bubble, and anything outside the bubble gets decoupled. The stargate could check a cylinder emanating from the "front side" of the gate. Anything in the cylinder fits, anything else gets left behind.

Hard but best answer: if you can hide the ship coming out of the other side visually, then just leave a circular hole in the middle of the stargate collision mesh. Either the ship will fit, or it will collide.

Perfect is the enemy of good. It's perfectly reasonable to start with something that works, and then incrementally improve to something better as people have time.

[Stoney3K]

Easy answer: don't. If the user transports a 500 m wide ship through a 20 m wide gate, that's their problem.

Medium but unrealistic answer: make an invisible collision mesh cylinder that extends from the front of the stargate, so that ships have to fit to reach the event horizon.

Medium but dangerous answer: https://github.com/BobPalmer/WarpDrive/blob/master/Source/WarpEngine/WarpEngine/USI_ModuleWarpEngine.cs#L440-L460

The Alcubierre warp drive makes a bubble, and anything outside the bubble gets decoupled. The stargate could check a cylinder emanating from the "front side" of the gate. Anything in the cylinder fits, anything else gets left behind.

Hard but best answer: if you can hide the ship coming out of the other side visually, then just leave a circular hole in the middle of the stargate collision mesh. Either the ship will fit, or it will collide.

Perfect is the enemy of good. It's perfectly reasonable to start with something that works, and then incrementally improve to something better as people have time.

If you want to be true to the "classic" rules of Stargate physics:

There's an Atlantis episode where they address exactly this issue. The ship they were in failed to retract its engine nacelles and because of that, got "stuck" with the engines jammed against the gate front, and half of the ship past the event horizon.

From that, they concluded that "the stargate only sends objects in one piece". Meaning, your transit would begin after the rearmost part of your ship has travelled beyond your "event horizon". If the ship is too big and it gets stuck, or backs out before it's completely through the ring, nothing would happen.

Visually, you could make a part which looks like a cylindrical worm hole without a collider, and which you can spawn when the dialing sequence to your remote endpoint is successful. The player's ship will transition straight into that part, and once completely immersed, you could transport it to where you want (which is the exit side of your remote gate). Because your vortex part envelops the player's ship on all sides, they would see nothing of the transition except for the vortex itself. With a set of colliders, it would also restrict the player's motion to within the vortex, or trigger certain death if the player inadvertedly ventures beyond it.

On completion of the transit, your part would disappear and de-spawn, possibly with some kind of animation, revealing the new destination to the player. This is how jump drive animations work in most games.

If Unity supports colliders that only notify when something is inside it, and which allow objects to pass straight through, you can make your "vortex" part the trigger, as long as you dimension it sensibly enough to accomodate typical player ship sizes.

It may not look *exactly* like the movie stargates, which have a transition volume which is completely flat, but something which resembles the Babylon 5 jump gates (which are volumetric) will definitely be possible.

Anyway, cooking up an actual stargate may warrant its own topic. This mod is too cool to get its thread hijacked.

Edited August 28, 2015 by Stoney3K

[Stoney3K]

@TMarkos: I'd be happy to help out on expanding this mod to a 'release' status. I'm proficient in C# so I can assist in any code issues (such as making that resource usage configurable, hint hint) and have modeling experience in Blender and Sketchup.

Are there any issues, gameplay wise, you would like to see fleshed out before you consider the mod releasable for a 1.0 alpha version?

[TMarkos]

@TMarkos: I'd be happy to help out on expanding this mod to a 'release' status. I'm proficient in C# so I can assist in any code issues (such as making that resource usage configurable, hint hint) and have modeling experience in Blender and Sketchup.

Are there any issues, gameplay wise, you would like to see fleshed out before you consider the mod releasable for a 1.0 alpha version?

Thanks for the offer, I sent you a PM with more thoughts on the matter.

Reading the posts on the previous page about potential mechanics, it occurs to me that the easiest thing to do would be to temporarily control the camera into chase mode, set up the barrel-o'-blue and reflective panel, then progress forward until the camera view was inside said barrel. At that point, transit the ship, swap to the other gate with the camera in a barrel on the other side, then progress forward until the camera is on the other side of the barrel. Clean up the barrel, release camera control, done.

That should be quick, maybe a second or two of elapsed time after the camera is in position. I think the mechanics are all there, but it'd be tricky to play with until you got the visual effect just right.

[sabreheim]

not sure exactly how to use this mod, tho the concept is awesome.

so total noob request here - is there a nice youtuber out there that would be willing to do a 'how-to' for this mod?

[TMarkos]

not sure exactly how to use this mod, tho the concept is awesome.

so total noob request here - is there a nice youtuber out there that would be willing to do a 'how-to' for this mod?

I'm no youtuber, but I'll respond to any questions you have.

First thing you want to do is find some Karborundum, since without it you can't do anything fun. By default it's not easy to get - you can mine it from Eve, Eeloo or from some asteroids. If that sounds like a pain, there are configs in the download that also make it available on Tylo, Ike, or just in the VAB if you don't want to be bothered going to get it.

Second is just putting beacons up. You'll have to move them out a bit from the planet to turn them on, and once you have two beacons you can take a third ship (this ship needs an antenna) and use the beacons to move it around.

[FatherLawrence]

I'm starting up a new galaxy playthrough (using Galactic Neighborhood for multiple star systems) and was wondering if these beacons have a maximum range? Even with RoverDude's Orion drives, traveling to another star can take 50 years (and Alcubiere drives take forever in real time; these are extreme distances). For reference, some of these stars are 10-20 Terameters apart.

[FungusForge]

I'm starting up a new galaxy playthrough (using Galactic Neighborhood for multiple star systems) and was wondering if these beacons have a maximum range? Even with RoverDude's Orion drives, traveling to another star can take 50 years (and Alcubiere drives take forever in real time; these are extreme distances). For reference, some of these stars are 10-20 Terameters apart.

Imma hyperedit a beacon a few terameters out and find out.

EDIT: so it appears you'll just have to carry literally several tons of karborundum on each beacon. Where a probe going around in-system jumps with an LB-100 would cost ~3 karborundum, the same probe was clocking 7500 karborundum for the distant jumps.

You can cross the distance with these beacons, but it will be stupid expensive.

Edited October 24, 2015 by FungusForge

[FatherLawrence]

Imma hyperedit a beacon a few terameters out and find out.

EDIT: so it appears you'll just have to carry literally several tons of karborundum on each beacon. Where a probe going around in-system jumps with an LB-100 would cost ~3 karborundum, the same probe was clocking 7500 karborundum for the distant jumps.

You can cross the distance with these beacons, but it will be stupid expensive.

Yeah, I just performed a similar test with a test vehicle maybe one tenth the size of the colony ship I wanted to fly out, and it spit out a cost of 8e16 karborundum Since even the largest 15m Karborundum tanks in FTT have something like 1.8e8 in capacity, it would take thousands of those tanks or ridiculously tweakscaled versions, and mining enough to fill those would be impossible XD

With that in mind, I've got an idea/request for whenever the author decides their life needs more complication: What about another beacon that's designed for interstellar travel that drastically reduces cost for extreme distance jumps? Something like a minimum jump distance of 1 terameter (since I'm sure there's almost no way to use that in-system) but has different scaling costs where it starts out very expensive on the low end but doesn't scale much higher with mass or distance, so that sending a probe isn't much cheaper than a colonyship. That would make interstellar jumps possible, while difficulty still comes from getting the second beacon all the way to another star system the old-fashioned way.

Edited October 25, 2015 by FatherLawrence

[F_X]

Did anyone test it with 1.0.5?

[iliketrains0pwned]

The parts load in, but they don't seem to be working. Can anyone do a quick fix to update it?

[TMarkos]

[quote name='iliketrains0pwned']The parts load in, but they don't seem to be working. Can anyone do a quick fix to update it?[/QUOTE]I'm kinda busy currently but I'll try to take a look at it if I have time in the next few weeks.

[Booots]

I've been experiencing a bug while using this mod (in 1.0.4) where, after jumping, the sending beacon's orbit has changed. In the tracking station and map view, the orbit predictions all appear normal. But flying a craft to rendezvous with it, even with a supposedly perfect intercept misses by a matter of tens of kilometers. Even then, map view shows the two craft as in close proximity. Brute force rendezvousing by thrusting straight at it until within physics range or switching to the beacon vessel forces the map view to update with its actual orbit which always seems to be lower. I've tried using the tracking station to switch to the beacon immediately after the jump to make sure it's not a bug with launching or rendezvousing, and this also reveals a degraded orbit as soon as physics loads.

This is all with the AMU and HCU activated.

Has anyone else experienced this issue? Could it be an unintended side effect of introducing random position error to the jumping vessel?

[iliketrains0pwned]

On 11/30/2015, 1:29:31, Booots said:

I've been experiencing a bug while using this mod (in 1.0.4) where, after jumping, the sending beacon's orbit has changed. In the tracking station and map view, the orbit predictions all appear normal. But flying a craft to rendezvous with it, even with a supposedly perfect intercept misses by a matter of tens of kilometers. Even then, map view shows the two craft as in close proximity. Brute force rendezvousing by thrusting straight at it until within physics range or switching to the beacon vessel forces the map view to update with its actual orbit which always seems to be lower. I've tried using the tracking station to switch to the beacon immediately after the jump to make sure it's not a bug with launching or rendezvousing, and this also reveals a degraded orbit as soon as physics loads.

This is all with the AMU and HCU activated.

Has anyone else experienced this issue? Could it be an unintended side effect of introducing random position error to the jumping vessel?

I haven't experienced that issue at all. The GUI doesn't show up, the parts faze through the ground, they freeze the VAB if you try to delete them, and you can't even move them once you attach them during assembly. 

[Luxord52]

Anybody got a solution for the issues in 1.0.5? I would love to bring my network back up with RemoteTech, but until this is working again, my plan goes a little bit down the drain.

[Stoney3K]

On 25-10-2015 23:22:06, FatherLawrence said:

Yeah, I just performed a similar test with a test vehicle maybe one tenth the size of the colony ship I wanted to fly out, and it spit out a cost of 8e16 karborundum Since even the largest 15m Karborundum tanks in FTT have something like 1.8e8 in capacity, it would take thousands of those tanks or ridiculously tweakscaled versions, and mining enough to fill those would be impossible XD

With that in mind, I've got an idea/request for whenever the author decides their life needs more complication: What about another beacon that's designed for interstellar travel that drastically reduces cost for extreme distance jumps? Something like a minimum jump distance of 1 terameter (since I'm sure there's almost no way to use that in-system) but has different scaling costs where it starts out very expensive on the low end but doesn't scale much higher with mass or distance, so that sending a probe isn't much cheaper than a colonyship. That would make interstellar jumps possible, while difficulty still comes from getting the second beacon all the way to another star system the old-fashioned way.

I think that if you want to do interstellar jumps, you could scale them with the same dynamics but in Kerbol orbit only, so a beacon that is in high Kerbol orbit would be cheap on fuel but it would be stupendous on the energy requirement which you would need to accomplish on solar panels a million miles away from the sun. That makes it more challenging, since you could use fuel cells but it would burn through any consumables in a split second. Think of a Mass Effect jump relay here.

Getting the second beacon to the other end in the "old-fashioned way" may not be particularly difficult, as long as you have enough delta-V to get to your destination, which becomes quite easy when you use ion engines.

Maybe the notion of "a lot of fuel" isn't really challenging to begin with, since you can drop an array of drills/ISRUs anywhere on your favorite planet and timewarp until the tanks are full, haul the fuel off the surface, and repeat. This is anything but a challenge since time is not a limited commodity in stock KSP. There may be more challenge in only allowing certain situations (interstellar jumps, interplanetary jumps, etc.) when other conditions are met, which may not be possible to achieve with timewarp only.

Edited December 13, 2015 by Stoney3K

[Luxord52]

Well, it seems I may have found part of the problem: KSP is tossing a Too many Polygons error on the beacon parts. Perhaps a slightly poly cheaper collision mesh would work.