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

[scottpaladin]

FYI it's not part of FTT It's a Karbonite extension

You'll have to forgive my confusion; its hard to keep all the mods you're involved with straight.

Edited September 2, 2014 by scottpaladin

[RoverDude]

You'll have to forgive my confusion; its hard to keep all the mods you're involved with straight.

Oh I have the same problem.... I keep a spreadsheet and flowcharts. So the best way to keep them straight is to just download them all

[Draft]

Well, a thought that I had afterwards was that the conversion shouldn't be unavailable in a gravity field, just really inefficient - so that the ideal would really be to mine it someplace like Minmus and then pop it out to high orbit for conversion. That takes care of the issues of on-ground conversion (no longer economical) and atmo-skimming conversion (doable, but now stupidly time-inefficient compared to the other way).

@Scottpaladin - the MM config will detect FTT and disable the distiller modification if it's installed.

I like the sound of that, though I'm not entirely sure that would solve the issue considering how ORS resources work- inefficient surface conversion isn't necessarily inferior to efficient orbital conversion if the end product masses less than its inputs either way and if you have an effectively-limitless supply of your inputs while on the surface. Tricky question.

Also I haven't got any interest in installing FTT (Sorry Roverdude), so I'd certainly hope that the EDSL+Karbonite alone setup remains supported in the long run.

[RoverDude]

I like the sound of that, though I'm not entirely sure that would solve the issue considering how ORS resources work- inefficient surface conversion isn't necessarily inferior to efficient orbital conversion if the end product masses less than its inputs either way and if you have an effectively-limitless supply of your inputs while on the surface. Tricky question.

Also I haven't got any interest in installing FTT (Sorry Roverdude), so I'd certainly hope that the EDSL+Karbonite alone setup remains supported in the long run.

No worries but I think there's some confusion here.

The overlap is that we'd be using this resource in K+ which is new resource, new mining places, plus parts pack (the fusion drive and a very large solar collector, plus associated parts and drills). FTT is... erm... freighters Granted, it will have more mining stuff later, but that's on the other side of the ven diagram.

So another way of putting it... if you want to turn Karbonite into Karborundum via manufacturing, then this mod is your best bet. If you want to mine for it, use K+ because you need drills, detectors, etc. (and get the bonus if a fusion drive to use Karborundum since I needed a reason for people to drill for it).

[TMarkos]

I like the sound of that, though I'm not entirely sure that would solve the issue considering how ORS resources work- inefficient surface conversion isn't necessarily inferior to efficient orbital conversion if the end product masses less than its inputs either way and if you have an effectively-limitless supply of your inputs while on the surface. Tricky question.

Also I haven't got any interest in installing FTT (Sorry Roverdude), so I'd certainly hope that the EDSL+Karbonite alone setup remains supported in the long run.

I intend to fully support standalone, Karbonite-only and FTT players as distinct modes of operation. I think flexibility is a good quality in a mod, since it doesn't lock players into a certain configuration to use the mod's capabilities. I originally developed this as a reaction to MKS/OKS and the need to send repeated missions over a long period of time to a single location, and I think that need resurfaces independently of which resource mods you have installed.

[RoverDude]

I intend to fully support standalone, Karbonite-only and FTT players as distinct modes of operation. I think flexibility is a good quality in a mod, since it doesn't lock players into a certain configuration to use the mod's capabilities. I originally developed this as a reaction to MKS/OKS and the need to send repeated missions over a long period of time to a single location, and I think that need resurfaces independently of which resource mods you have installed.

You're killing he here

Let me try it at a different angle. What DLL are you currently looking for to tie in your alteration to the distillers? FTT (which is freighter parts) has no independent DLL. Karbonite has it's core one, plus some ancillary ones that cover generators and such (i.e. the stuff that makes the drills work). This is important because having a conversion method available at the same time as mining/extraction is pretty mod-breaking on my side - it basically adds something new resource wise, but no new mechanic or driver (that's why I want to make sure we sort this before I release, which is likely happening in a matter of days).

Background for the thread (TMarkos - obviously you already have all of this info, more for folks catching up and wondering why I'm in this thread):

TMarkos uses a rare and expensive resource for this mod. Karbonite Plus (K+) adds a rare and expensive resource. Rather than having two new resources that are both rare and expensive versions of Karbonite, might as well just have one resource. My update is purely on the extraction side - i.e. this stuff exists already as a valid CRP resource, but the only way to get it out of the box (and this also is live) is on Eeloo, Eve, and within 2KM of the sun. There are not, at this point, any parts that allow that extraction to take place.

The scope of my next mod is purely a parts pack (and some DLL changes to core Karbonite to allow some interesting things to happen). So drills, the solar collector, etc. and - most importantly - a new fusion drive, because people need a reason to get this stuff (other than ESLS). Otherwise, no value and no reason to use the mod. So my carrot in this case is a 15K dV fusion engine. My stick is very difficult access to a non-tweakable resource. And again, no reason to have two new resources with such a strong overlap.

FTT has as much to do with this as ham does with hamsters

If what we are saying is that ESLD needs to operate on a converter for folks who do not extend Karbonite with K+ (which makes perfect sense) then the rub is we have no DLL that ties to this. Which is no bueno. I am more than happy to make a dummy one (it will just be empty code but there to trigger MM) to help out with this, but I have to understand if we're on the same page.

Thinking outside the box for a bit. Choice 2 is to pull the Karbonite dependency entirely and just have a CRP one. You can use the Karbonite models and retexture them (I have a blank one for the distiller that WaRi made), use the ORS Extensions DLL that Karbonite uses (I broke this out specifically so people could do stuff without needing a full Karbonite install because ORS rocks), and then just turn the distiller off if you see the Karbonite DLL. Again, if you want an extension that makes a converter only work in microgravity, that's pretty easy and I'd be happy to code it into the ORS extensions.

DLL wise: ORS -> ORS Extensions -> Karbonite. The Karb DLL just adds animations and stuff mostly, or Karbonite specific things.

So really... three choices based on what level of dependency you want. Going from lightest to heaviest.

1. Depend only on ORS / CRP (you need to add your own distiller/converter and let me know if you want code for microgravity only conversion). Turn off if you see Karbonite.

2. Depend on Karbonite only. Turn off if you see a yet-to-be-made dummy DLL (I will need to make this)

3. Depend on K+ (the mod pack that adds the engine, scanner, and mining drill for Karborundum) and do nothing other than NOT have a conversion option, as that is gameplay-breaking for K+.

[Draft]

Ah, there's my confusion solved- What you're calling K+ now is what I'd heard somewhere was going to be the later phases of FTT.

So the use cases are:

1a) EDSL alone- (No extraction of Karborundum or Karbonite, no conversion of Karborundum, tweakable Karborundum)

or

1b) EDSL with bundled ORS- (No extraction of Karborundum, basic extraction of Karbonite, with conversion of Karborundum, non-tweakable Karborundum, tweakable Karbonite)

2) EDSL with Karbonite- (No extraction of Karborundum, full extraction of Karbonite, with conversion of Karborundum, non-tweakable Karborundum, tweakable Karbonite, disables the basic extraction/conversion tools from 1b if necessary)

3) EDSL with Karbonite+- (Full extraction of Karborundum, full extraction of Karbonite, no conversion of Karborundum, non-tweakable Karborundum, tweakable Karbonite, disables the basic extraction/conversion tools from 1b if necessary)

yeah?

IAMAP but it looks like regardless of whether ORS and skeleton Karbonite is included with EDSL, MM's gonna need to tell whether to allow conversion based on the presence of K+ somehow.

[TMarkos]

You're killing he here

Let me try it at a different angle. What DLL are you currently looking for to tie in your alteration to the distillers? FTT (which is freighter parts) has no independent DLL. Karbonite has it's core one, plus some ancillary ones that cover generators and such (i.e. the stuff that makes the drills work). This is important because having a conversion method available at the same time as mining/extraction is pretty mod-breaking on my side - it basically adds something new resource wise, but no new mechanic or driver (that's why I want to make sure we sort this before I release, which is likely happening in a matter of days).

Background for the thread (TMarkos - obviously you already have all of this info, more for folks catching up and wondering why I'm in this thread):

TMarkos uses a rare and expensive resource for this mod. Karbonite Plus (K+) adds a rare and expensive resource. Rather than having two new resources that are both rare and expensive versions of Karbonite, might as well just have one resource. My update is purely on the extraction side - i.e. this stuff exists already as a valid CRP resource, but the only way to get it out of the box (and this also is live) is on Eeloo, Eve, and within 2KM of the sun. There are not, at this point, any parts that allow that extraction to take place.

The scope of my next mod is purely a parts pack (and some DLL changes to core Karbonite to allow some interesting things to happen). So drills, the solar collector, etc. and - most importantly - a new fusion drive, because people need a reason to get this stuff (other than ESLS). Otherwise, no value and no reason to use the mod. So my carrot in this case is a 15K dV fusion engine. My stick is very difficult access to a non-tweakable resource. And again, no reason to have two new resources with such a strong overlap.

FTT has as much to do with this as ham does with hamsters

If what we are saying is that ESLD needs to operate on a converter for folks who do not extend Karbonite with K+ (which makes perfect sense) then the rub is we have no DLL that ties to this. Which is no bueno. I am more than happy to make a dummy one (it will just be empty code but there to trigger MM) to help out with this, but I have to understand if we're on the same page.

Thinking outside the box for a bit. Choice 2 is to pull the Karbonite dependency entirely and just have a CRP one. You can use the Karbonite models and retexture them (I have a blank one for the distiller that WaRi made), use the ORS Extensions DLL that Karbonite uses (I broke this out specifically so people could do stuff without needing a full Karbonite install because ORS rocks), and then just turn the distiller off if you see the Karbonite DLL. Again, if you want an extension that makes a converter only work in microgravity, that's pretty easy and I'd be happy to code it into the ORS extensions.

DLL wise: ORS -> ORS Extensions -> Karbonite. The Karb DLL just adds animations and stuff mostly, or Karbonite specific things.

So really... three choices based on what level of dependency you want. Going from lightest to heaviest.

1. Depend only on ORS / CRP (you need to add your own distiller/converter and let me know if you want code for microgravity only conversion). Turn off if you see Karbonite.

2. Depend on Karbonite only. Turn off if you see a yet-to-be-made dummy DLL (I will need to make this)

3. Depend on K+ (the mod pack that adds the engine, scanner, and mining drill for Karborundum) and do nothing other than NOT have a conversion option, as that is gameplay-breaking for K+.

Yeah, I think I'm making some errors of phrasing. When I say "FTT" I really mean "K+" as I was thinking of K+ as being basically "FTT Phase 2". I should probably stop thinking of it as part and parcel.

Here is my current MM config. Hopefully this clears up what I'm trying to do. Obviously the "FTT" reference in here is a placeholder and will be changed to whatever your dummy DLL is called.

@PART[KA_Distiller_125_01]:NEEDS[Karbonite,!FTT]
{
	MODULE
	{
	 name = USI_Converter
	 converterName = Karborundum
	 conversionRate = 1
	 inputResources = ElectricCharge, 4, Karbonite, 2
	 outputResources = Karborundum,0.0016,False
	}	
}

@PART[KA_Distiller_250_01]:NEEDS[Karbonite,!FTT]
{
	MODULE
	{
	 name = USI_Converter
	 converterName = Karborundum
	 conversionRate = 1
	 inputResources = ElectricCharge, 3.6, Karbonite, 2
	 outputResources = Karborundum,0.0016,False
	}	
}

@RESOURCE_DEFINITION[Karborundum]:NEEDS[!Karbonite]
{
  @isTweakable = true
}

That means Karbonite disables tweakability, and the ability to extract Karborundum disables the ability to convert Karborundum. For the converter, I would love an option for the USI standard converter that is basically a variable which allows you to define how efficient/wasteful the process is. Set it to 0, then all inputs are converted to outputs. Set it to .99, and the process consumes 100% of inputs while only producing 1% of outputs. I think this will prove to be more generally useful for the converter class as a whole than a dedicated microgravity sensor, the implementation of which is trivial given a prebuilt efficiency modifier in the converter.

[scottpaladin]

The scope of my next mod is purely a parts pack (and some DLL changes to core Karbonite to allow some interesting things to happen). So drills, the solar collector, etc. and - most importantly - a new fusion drive, because people need a reason to get this stuff (other than ESLS). Otherwise, no value and no reason to use the mod. So my carrot in this case is a 15K dV fusion engine. My stick is very difficult access to a non-tweakable resource. And again, no reason to have two new resources with such a strong overlap..

Ah, K+ is just a parts pack and Karborundum is getting rolls into the plugins for Karbonite. Good to know.

It seems like other mods being able to check whether Karborundum specifically is actually gatherable would be useful in the long run. I've got an idea on my list of things to work on that I think Karborundum fits the bill for, but I think it'd be nice if Karborundum could remain tweakable in unless the player has installed the stuff they need to go and get it themselves. If the solution for that is a dummy dll to check against, maybe it'll be better to go ahead and have one.

Edit: I now see TMarkos' post above: since I'm more than a ways off doing my thing, I'll have to wait and see how this gets handled so I'm not conflicting with how the resource is handled by others.

Edited September 3, 2014 by scottpaladin

[TMarkos]

Ah, K+ is just a parts pack and Karborundum is getting rolls into the plugins for Karbonite. Good to know.

It seems like other mods being able to check whether Karborundum specifically is actually gatherable would be useful in the long run. I've got an idea on my list of things to work on that I think Karborundum fits the bill for, but I think it'd be nice if Karborundum could remain tweakable in unless the player has installed the stuff they need to go and get it themselves. If the solution for that is a dummy dll to check against, maybe it'll be better to go ahead and have one.

Edit: I now see TMarkos' post above: since I'm more than a ways off doing my thing, I'll have to wait and see how this gets handled so I'm not conflicting with how the resource is handled by others.

Well, K+ just adds parts to deal with the pre-existing Karborundum maps that RoverDude included in CRP the other day. Technically, you could harvest Karborundum in any game that had the Community Resource Pack installed, as long as you had a part to harvest it with. That makes detection a bit more difficult, hence nontweakable being the default state - it's defined in the CRP along with the maps for harvesting it.

[scottpaladin]

Well, K+ just adds parts to deal with the pre-existing Karborundum maps that RoverDude included in CRP the other day. Technically, you could harvest Karborundum in any game that had the Community Resource Pack installed, as long as you had a part to harvest it with. That makes detection a bit more difficult, hence nontweakable being the default state - it's defined in the CRP along with the maps for harvesting it.

Ah, I had assumed that the partmodules for extraction were from Karbonite but looking at them now they're labeled as ORSModuleRailsExtraction, so that's what you get when you assume.

[GrimT]

Might I make some suggestions?

I've read through all of the posts here and I am both thoroughly impressed and slightly intimidated by what this mod proposes to introduce to my game (which I will most likely do).

If I've followed the conversation properly it seems as though there is a decision to be made in regards to dependencies. IMO I think it would be beneficial to use the K+ pack (of which I've just learned today... Roverdude it looks like you've just expanded my mod list yet again) but still allow for a conversion method from Karbonite at the tremendous conversion loss ratio TMarkos suggested with the option to increase conversion efficiency by attaching a 'booster' part to a collector/distiller(or convertor), the rate of which would be decided upon by you all. I suppose this could potentially introduce exploits to the system but if the technology was only attainable in the tree at a point which seemed to counter-balance that it may already be more efficient to collect the resource via current methods. Additionally another method to throttle the efficiency gained is to incorporate additional logistics by introducing an additional resource to the conversion process (this would most likely require a separate convertor part but I have no idea) in addition to the Karbonite. In other words, Karbonite goes in - Antimatter is used for a more advanced and efficient compression method but you would ultimately need to refuel your antimatter stores. That's just an example but my suggestion would be to select a resource that could not be collected coupled with Karbonite at the same time easily, if at all, or add a steep electrical requirement.

Additionally, do you have plans to add course correction efficiency parts that could be added to the craft to decrease the Karborundum jump requirements?

To expand on that last suggestion (which will tie into my next), a potential technology... lets call it warp on orbital position system (WOOPS) that allow you to chose a wide berth orbit of a celestial body in the subsystem (planet/moons) or the actual warp beacon itself. Cheesy acronyms aside, I think this would be a less frustrating logistics solution in the long-run that would come at an increase to cost of 'something' that you can determine later. Whether it be an increase cost from each beacon's karborundum along the way with no cost to the last beacon used, which would encourage people to refuel beacons from the outer-rings going in, or some other method.

Lastly, are the Karborundum tanks going to be able to be refilled. I ask because I feel that relaunching and positioning these expensive waypoint beacons will grow tiresome, not to mention the lazy man (me) will want to use the current infrastructure in place to warp replacements in which will also come at a resource cost as well. Granted, I cant imagine refueling them will be much better in terms of logistics.

In regards to aesthetics because personally I'm big on those, I would love to see something similar to what parameciumkid has done with his warp mod's warp animation (I suspect its an animation) located here http://forum.kerbalspaceprogram.com/threads/66921-Part-Plugin-parameciumkid-s-Jump-Drive-v0-5-(new-models-and-sound-effects!)

Sidenote: I have not been able to test your mod or the one linked, and quite honestly a lot of the information provided in the diagrams/pics/posts went straight over my head so I'll end up having to study them a bit more to fully grasp how this functions. So that being said, if any of my suggestions are unfeasible, or how the mod currently functions or would break it entirely, I apologize.

[RoverDude]

Well, K+ just adds parts to deal with the pre-existing Karborundum maps that RoverDude included in CRP the other day. Technically, you could harvest Karborundum in any game that had the Community Resource Pack installed, as long as you had a part to harvest it with. That makes detection a bit more difficult, hence nontweakable being the default state - it's defined in the CRP along with the maps for harvesting it.

Yep, it makes more sense for there to be a specific case TO have it tweakable (i.e. the absence of a drill). Because if it becomes easy to get, it breaks it's scarcity.

You know... I have another idea.

If the goal is to have ESLD independent (which is good) but also ensure rarity/scarcity of the resource, an in-orbit converter, no matter how inefficient, is going to defeat this. Heck, players will just spam 200 particle collectors and time warp.

So how about this mechanic... Have the converter require a secondary ingredient that cannot be mined, but must instead be purchased and launched. Looking at CRP, we have a few. EnrichedUranium being one (just as an example), where massive amounts have to be expended, the DepletedUranium handles the waste mass, and you now have something that can be manufactured for a silly cost (way more than the value of the Karborundum in it's natural state).

The net effect is that you can make the stuff but it's expensive and labor intensive, non-warpable, etc. - but it does give you an out. Or, if you have KSPI, you can mine the uranium. Or if you have K+ you can mine the Karborundum. And without the need for an MM config, it prevents any potential issues down the road

[TMarkos]

Yep, it makes more sense for there to be a specific case TO have it tweakable (i.e. the absence of a drill). Because if it becomes easy to get, it breaks it's scarcity.

You know... I have another idea.

If the goal is to have ESLD independent (which is good) but also ensure rarity/scarcity of the resource, an in-orbit converter, no matter how inefficient, is going to defeat this. Heck, players will just spam 200 particle collectors and time warp.

So how about this mechanic... Have the converter require a secondary ingredient that cannot be mined, but must instead be purchased and launched. Looking at CRP, we have a few. EnrichedUranium being one (just as an example), where massive amounts have to be expended, the DepletedUranium handles the waste mass, and you now have something that can be manufactured for a silly cost (way more than the value of the Karborundum in it's natural state).

The net effect is that you can make the stuff but it's expensive and labor intensive, non-warpable, etc. - but it does give you an out. Or, if you have KSPI, you can mine the uranium. Or if you have K+ you can mine the Karborundum. And without the need for an MM config, it prevents any potential issues down the road

That sounds feasible. Have to muck around with balance issues to settle on something that works and isn't tedious, but I'll try a few combos of resources and see what emerges.

Might I make some suggestions?

I've read through all of the posts here and I am both thoroughly impressed and slightly intimidated by what this mod proposes to introduce to my game (which I will most likely do).

If I've followed the conversation properly it seems as though there is a decision to be made in regards to dependencies. IMO I think it would be beneficial to use the K+ pack (of which I've just learned today... Roverdude it looks like you've just expanded my mod list yet again) but still allow for a conversion method from Karbonite at the tremendous conversion loss ratio TMarkos suggested with the option to increase conversion efficiency by attaching a 'booster' part to a collector/distiller(or convertor), the rate of which would be decided upon by you all. I suppose this could potentially introduce exploits to the system but if the technology was only attainable in the tree at a point which seemed to counter-balance that it may already be more efficient to collect the resource via current methods. Additionally another method to throttle the efficiency gained is to incorporate additional logistics by introducing an additional resource to the conversion process (this would most likely require a separate convertor part but I have no idea) in addition to the Karbonite. In other words, Karbonite goes in - Antimatter is used for a more advanced and efficient compression method but you would ultimately need to refuel your antimatter stores. That's just an example but my suggestion would be to select a resource that could not be collected coupled with Karbonite at the same time easily, if at all, or add a steep electrical requirement.

Additionally, do you have plans to add course correction efficiency parts that could be added to the craft to decrease the Karborundum jump requirements?

To expand on that last suggestion (which will tie into my next), a potential technology... lets call it warp on orbital position system (WOOPS) that allow you to chose a wide berth orbit of a celestial body in the subsystem (planet/moons) or the actual warp beacon itself. Cheesy acronyms aside, I think this would be a less frustrating logistics solution in the long-run that would come at an increase to cost of 'something' that you can determine later. Whether it be an increase cost from each beacon's karborundum along the way with no cost to the last beacon used, which would encourage people to refuel beacons from the outer-rings going in, or some other method.

Lastly, are the Karborundum tanks going to be able to be refilled. I ask because I feel that relaunching and positioning these expensive waypoint beacons will grow tiresome, not to mention the lazy man (me) will want to use the current infrastructure in place to warp replacements in which will also come at a resource cost as well. Granted, I cant imagine refueling them will be much better in terms of logistics.

In regards to aesthetics because personally I'm big on those, I would love to see something similar to what parameciumkid has done with his warp mod's warp animation (I suspect its an animation) located here http://forum.kerbalspaceprogram.com/...ound-effects!)

Sidenote: I have not been able to test your mod or the one linked, and quite honestly a lot of the information provided in the diagrams/pics/posts went straight over my head so I'll end up having to study them a bit more to fully grasp how this functions. So that being said, if any of my suggestions are unfeasible, or how the mod currently functions or would break it entirely, I apologize.

I think that the logistics flow of refilling these beacons will develop more depth over time, as harvesting isn't currently available and we're still debating the best implementation of conversion. I don't think I'll be integrating antimatter, since that would require a dependency on KSPI.

There are parts that modify efficiency - the Superconducting Coil Array reduces base jump cost, and your selection of beacon will modify both the jump cost and the precision of your arrival.

Your idea for the WOOPS would be tougher to balance out, since right now interplanetary transfers involve use of the destination beacon to offset differences in orbital velocities. I suppose I could introduce the option for interplanetary beacons to transmit in local mode like the smaller beacon sizes and widen the targeting area dramatically, but I can't see a system where the area of emergence isn't centered around the beacon - that's a bit too much like Hyperedit for my taste.

I do intend to look at adding sounds, but visual effects are going to take a backseat to keeping the transition smooth and lag-free. If I can make a visual effect work without affecting any part of that, then it may be in the mod in a post-RC phase.

[GrimT]

I think that the logistics flow of refilling these beacons will develop more depth over time, as harvesting isn't currently available and we're still debating the best implementation of conversion. I don't think I'll be integrating antimatter, since that would require a dependency on KSPI.

There are parts that modify efficiency - the Superconducting Coil Array reduces base jump cost, and your selection of beacon will modify both the jump cost and the precision of your arrival.

Your idea for the WOOPS would be tougher to balance out, since right now interplanetary transfers involve use of the destination beacon to offset differences in orbital velocities. I suppose I could introduce the option for interplanetary beacons to transmit in local mode like the smaller beacon sizes and widen the targeting area dramatically, but I can't see a system where the area of emergence isn't centered around the beacon - that's a bit too much like Hyperedit for my taste.

I do intend to look at adding sounds, but visual effects are going to take a backseat to keeping the transition smooth and lag-free. If I can make a visual effect work without affecting any part of that, then it may be in the mod in a post-RC phase.

Thanks for the response!

in regards to woops, I'm not sure if I understand correctly or if I'm not explaining well enough. I guess what I'm saying is this computer system at the tail end of the tech tree would be capable of matching orbits adjacent to the target destination beacon within its soi, I suppose that is quite similar to hyperedit though. The antimatter resource was just an example though, I've been playing with a number of mods all added at the same time so I'm not really sure what mod adds what resource currently.

In any case, I'm very impressed by the work you've been doing and look forward to seeing this progress. I'll be installing this mod as I prefer the complexity, difficulty and level of realism it adds as opposed to the alternatives available. So great job and thank you!

[TMarkos]

Thanks for the response!

in regards to woops, I'm not sure if I understand correctly or if I'm not explaining well enough. I guess what I'm saying is this computer system at the tail end of the tech tree would be capable of matching orbits adjacent to the target destination beacon within its soi, I suppose that is quite similar to hyperedit though. The antimatter resources was just a suggestion though, I've been playing with a number of mods all added at the same time so I'm not really sure what mod adds what resource currently.

In any case, I'm very impressed by the work you've been doing and look forward to seeing this progress. I'll be installing this mod as I prefer the complexity, difficulty and level of realism it adds as opposed to the alternatives available. So great job and thank you!

Adjacent to the beacon, yes - there's a device called the Alignment Matrix that lets you cancel the velocity vectors (more or less) at the cost of a LOT of Karborundum. I thought you meant anywhere within an orbital band in the target system SOI.

[GrimT]

Adjacent to the beacon, yes - there's a device called the Alignment Matrix that lets you cancel the velocity vectors (more or less) at the cost of a LOT of Karborundum. I thought you meant anywhere within an orbital band in the target system SOI.

Oh no Sir. Pin-point warps would in my mind only be feasible based on co-ordinates which you would need to base off of a known location. The further out from that would be less accurate imo. Celestial bodies would be easy to calculate a direct jump orbit to however the dependency on a resource/other tool to facilitate the warp negates that. Plus I think warping into a close orbit to a planet would not only be dangerous to the craft but detrimental to the intended target itself... but all of what I'm saying is purely speculative and largely based on sci-fi movies/books/games haha

I'm happy to hear there are already adapters to adjust/fine tune functionality of the base system planned or in place. I'm excited to give this mod a spin!

[smart013]

I really, really like the sound of this mod. Right now i'm using paramedicums mod, and thinking about switching to this. BUT ... how great is the risk that infrastructure now build and installed is made unusable in the next versions? Yes, i know, i always have to expect this, but some kind of mild assurance would be nice

[TMarkos]

I really, really like the sound of this mod. Right now i'm using paramedicums mod, and thinking about switching to this. BUT ... how great is the risk that infrastructure now build and installed is made unusable in the next versions? Yes, i know, i always have to expect this, but some kind of mild assurance would be nice

I don't anticipate any breaking changes. At worst, you'll have new models for the surface-attachable parts that are likely going to be a bit bulkier, but I've been taking pains to keep part names the same so it doesn't delete crafts. I already balanced Karborundum usage amounts, so I won't have another reason to change fuel costs. Although you always have to allow for unplanned things to intrude, if nothing unexpected arises there should be no major break in functionality between now and release.

[Pigbear]

I suspect that setting up a beacon around the sun harvesting karbondonum would make it pretty much infinite.

[RoverDude]

I suspect that setting up a beacon around the sun harvesting karbondonum would make it pretty much infinite.

The only rub... is that to harvest around the sun you're looking at altitudes below 2000m

(Edit)

Where I am going with this... is that if there's variance in your arrival point, you will probably at some point poral into the middle of a star. Solar operations would probably require a beacon further out followed by a rendezvous with the collector station to shuttle the stuff back and forth.

So a solar harvesting point is the most dangerous, Eve is hard to get off of, which leaves Eeloo as your most likely mining spot.

Edited September 5, 2014 by RoverDude

[scottpaladin]

The only rub... is that to harvest around the sun you're looking at altitudes below 2000m

(Edit)

Where I am going with this... is that if there's variance in your arrival point, you will probably at some point poral into the middle of a star. Solar operations would probably require a beacon further out followed by a rendezvous with the collector station to shuttle the stuff back and forth.

So a solar harvesting point is the most dangerous, Eve is hard to get off of, which leaves Eeloo as your most likely mining spot.

Wouldn't you also run into a problem with the sun's gravity well too?

[RoverDude]

Wouldn't you also run into a problem with the sun's gravity well too?

Possibly, although on-rails should still work.

[scottpaladin]

Possibly, although on-rails should still work.

Well, I haven't taken a gravioli detector to low Kerbol orbit and done the observation, but surely 2000m is well within... Actually, I have a few minutes to test....

Looks like 1g is at about 90,000,000m. And if I'm reading the wiki and doing my calculations right, the "hard limit" of 1.25 target radius is at about 10,000,000m. So you'll

still have a trip to make 2000m altitude even if you're jumping in at a beacon.

[Nhawks17]

RoverDude, since you are here. Considering this mod uses Karbondonum, I'm still confused as to if you need Karbonite plus or not. Can you use JUST Karbonite and have this work or is K+ a dependency, I've read through the wiki and can't really determine if its required or not.