[1.11.+] ESLD Jump Beacons Revived (1.4.0)

[Booots]

@wile1411, thanks for all the testing!

There already is the ability to change the weightings in the jump cost function in the cfgs for each beacon. I haven't looked at it in a long time, but I'm pretty sure it was working for me.

I like your thoughts about using the part upgrades feature. I haven't done that before so I'll have to look into how it's done. As for the techboxes all being available from step one, I haven't thought about it recently; I've been working on a new mod (tangentially related to making beacons work as infinite-range comms between each other).

^Which, now that I've written it that way, I think the no comms degradation or signal delay through beacons might be OP. Thoughts on making it balanced?

[cyberKerb]

2 hours ago, Booots said:

^Which, now that I've written it that way, I think the no comms degradation or signal delay through beacons might be OP. Thoughts on making it balanced?

Thanks for cfg info - I'll take a look.

For the comms, I like how stock has it's distances and commnet setup. I'm currently playing around with the CommNet Constellation mod to reduce the clutter on the connections in my game. If you had no comm degradation over the distances that you'd use these beacons (eg Kerbin to Jool or further), that would be like having 1 satellite that had a 1x10¹⁰⁰ power and covers everything on the map. At that moment, what's the point of bothering with a commnet if it doesn't guide gameplay in any meaningful way.

[Booots]

On 8/18/2017 at 6:05 PM, wile1411 said:

For the comms, I like how stock has it's distances and commnet setup. I'm currently playing around with the CommNet Constellation mod to reduce the clutter on the connections in my game. If you had no comm degradation over the distances that you'd use these beacons (eg Kerbin to Jool or further), that would be like having 1 satellite that had a 1x10¹⁰⁰ power and covers everything on the map. At that moment, what's the point of bothering with a commnet if it doesn't guide gameplay in any meaningful way.

Sorry, I think I was misunderstood. The beacons only have infinite range to another active beacon. So the one beacon won't cover everything on the map, but it will link to another beacon regardless of distance. So you can use these as your deep space network nodes but still need to relay to things in their local area. My thinking is that if you can send matter at lightspeed, you should be able to send information.

[cyberKerb]

1 hour ago, Booots said:

Sorry, I think I was misunderstood. The beacons only have infinite range to another active beacon. So the one beacon won't cover everything on the map, but it will link to another beacon regardless of distance. So you can use these as your deep space network nodes but still need to relay to things in their local area. My thinking is that if you can send matter at lightspeed, you should be able to send information.

Ah - my bad.  If it doesn't affect the CommNet transmission limitations, then I think I see what you meant. however, I thought beacons being able to talk to each other regardless of distance is how it works now, isn't it? With my testing with those large Solar Systems, there was no way for them to communicate back to Kerbin, but I was still able to jump to them. I'll have to recheck I had CommNet limitations turned on... If the questions is "should it"? Best answer is probably just then let the player decide with an option in the custom difficulty settings or config file. Unfortunately you'd have to code both options for it to be available.  

*sigh* Just reread the last few posts and realised you were talking in context of a new mod with tangent implications to ESLD, sorry! I'm not 100% sure on how you mean - I misunderstood what you meant by still being "able to send information"? I'm (wrongly) assuming you're talking about sending science back to Kerbin. Is it all related to the new mod?
(Maybe it's just too early in the morning for me- time for coffee )
 

Edited August 20, 2017 by wile1411

[ganinian]

First of all thanks @Booots for updating and maintaining this, appreciate it man!

So I've been messing around with the part configs, trying to get the jump costs down to a reasonable amount for RSS, but I have no idea what most of the values do and how exactly they affect the jumps. Does anybody have an idea? Specifically the "coef " value under ESLDBeacon module, thanks

Edited August 23, 2017 by ganinian

[Booots]

@ganinian, see this post for details on what all the variables do:

But I've just realized that at the moment, there's nothing you can do do scale only the distance without affecting the relationship with mass. So the next version that will be coming out soon will add a 'scale' variable that defaults to 1 but can be changed to accommodate RSS and other scale mods. Thanks!

[Zhetaan]

@ganinian:

The coef variable is a cost modifier, but it only works on one term.  Specifically, it's a correction factor to account for the fact that there's enough going on mathematically that one needs to prioritise how to program the beacons; the first thing to do is to get the relationship of mass and distance to behave the way you want, and the second is to scale that relationship to work within the intended ranges of mass and distance.  Of course, if you like, I can tell you how to change the scale to suit RSS, but without a general scaling factor, we're going to have to do it the way @TMarkos originally did, on a per-beacon basis.

The total cost calculation has three terms:  we'll call them the mass term, the mass-distance term, and the base fee term.  These are all added together to give the total cost in the jump.  By default, the base fee is zero, so we can ignore it for the most part.

The mass term is just the mass to be sent times a flat multiplier called baseMult.  The mass-distance term is a complicated piece of work, but the important bit is that the complicated parts are also multiplied by a flat multiplier, and that is coef.  With some algebraic machination, we can show that the total cost value can be modified simply by applying the same factor to both of these variables--in other words, we can get the cost to play somewhat nicely with RSS by dividing baseMult and coef by some value.  The question is whether this results in the correct cost.  I chose values that would roughly shift the cost down by an order of magnitude with respect to distance while holding tonnage constant; in other words, the amount of Karborundum in stock to send a vehicle of a given tonnage a given distance should send the same vehicle ten times the distance in RSS.  I do not know how this affects AMU costs; you may find that the price to match velocities becomes prohibitive when you try to go to Neptune.

For the LB-10, divide coef by 3 to get 0.0035024370.  The baseMult value is zero, so you don't need to do anything to it.  Add a zero to the end of distPenalty (it's only set for the LB-10) if you want to get roughly the same relative amount of jump before the distance penalty activates.

For the LB-15, you can get away without modifying it at all, oddly enough.  Its usage window shrinks in RSS, but it was never very big to begin with.  If you really, really want to do so, divide coef only by 2 to get 0.0005286855 and this will get you close enough for now.  Only modify coef; there's an odd exponential-hyperbolic hybrid relationship involved that I will explain later. 

For the LB-100, divide coef and baseMult by 1.3  to get 0.19230769 for baseMult and 0.6819290 for coef.
 

To explain why there's no way to scale the distance without affecting the relationship with mass:

The problem is that while we can scale the base cost, the cost doesn't scale linearly with tonnage and distance.  That's why the scaling factors are different for each beacon.  If it were as simple as dividing everything by ten (because that's the scaling factor of RSS over stock) then this would be easy.

Calculating a modification of baseMult is simple enough--it's a straight factor.  Figuring tripDist is almost as easy, because it's a variable raised to an exponent that is constant for each beacon.  The little detail that confounds the calculation is the relationship of massFctr and massExp to coef.  For the LB-10 and LB-100, massExp is 1 so the form of the expression over varying tonnage is x^x; it's tricky, but doable.  For the LB-15, massExp is 2, the form is ³x (that's tetration if you're interested), and that's another story.

To hold the cost constant for a given tonnage while modifying coef, we have to modify massFctr as well.  We must be able to do this to scale the cost at all, for any beacon--in this case, we want to hold the cost at whatever it would normally be times the predetermined scaling factor.  We're essentially setting the price ahead of time and building beacons to that price.  The issue is that, much as cost doesn't vary linearly with tonnage and distance, massFctr doesn't vary linearly with coef.  It doesn't even vary inversely.  Instead, it varies inversely with the logarithm of coef.  For the LB-10 and LB-100, massFctr is so small that we can mostly ignore the effect of raising the tonnage to itself--the end result is that we hold cost nearly, but not exactly constant--but for the LB-15, we can't do that because the tonnage is raised to itself raised to itself, which has the effect of overpowering the rest of the calculation and making tonnage a lot more important to the final value.  This is the same effect that makes the LB-15 such a shoddy high-mass beacon ... but on the other hand, it also holds the cost nearly constant over a vast range of distances if the mass is small.  That is also why it is not necessary to modify baseMult for that beacon.

What @Booots is doing by adding a new variable is taking the entire cost calculation and applying that predetermined scaling factor I mentioned earlier, and that really is the only whole-system solution.  What I propose is simply a stopgap to simulate that effect until the next release.

Edited September 12, 2017 by Zhetaan

[Booots]

I've released version 1.0.0. Unfortunately, I haven't found time to add the requested overall cost multiplier. That will probably come this weekend.

This update is for KSP 1.3.1 and fixes the out-of-power bug! I think. I had it working perfectly fine in testing in an earlier version of KSP but haven't had time to test it at all on 1.3. Please let me know if there are any bugs!

[DStaal]

Quick note: I see that the version file in the most recent version lists this release as for KSP 1.2.2.

[Booots]

On 12/11/2017 at 8:35 AM, DStaal said:

Quick note: I see that the version file in the most recent version lists this release as for KSP 1.2.2.

Oops, thanks. It should read KSP 1.3.1 but I always forget to edit that thing.

[eddiew]

Hi @Booots, loved the idea of this mod when I first saw it, but never got to use it at the time, so good to see it revived  

Can I ask; is there any config setting that would make jumps free? Or even better, change it to use resource of my choice - electricity, ore, liquid hydrogen, whatever? Also, is there a setting to control how much ec/s the beacon consumes when activated?

Reason for asking; I'm setting up a new career with Galileo's planet pack and OPM, which provides 2 star systems to explore. I'm looking to create a pair of stargates that will already exist at the start of the game (just welded parts, really, with the appropriate ESLD modules in the config) to give me a shortcut between the two stars. My inner RP would love to 'encounter' the local stargate and then have to find a way to stick something silly like 2000 ec/s worth of generation onto it to power it up.

I mean, I could bluff my way through most of that and cheat the refuelling of them if I really wanted to, but it'll be more fun to play if it's actually got to be done  

[Booots]

2 hours ago, eddiew said:

Can I ask; is there any config setting that would make jumps free? Or even better, change it to use resource of my choice - electricity, ore, liquid hydrogen, whatever? Also, is there a setting to control how much ec/s the beacon consumes when activated?

There should be a line in the config for the beacon where it says the resource to use. Unfortunately, I've had reports that it might be buggy and revert to using Karborundum regardless of what the config says. I'm going to be looking into that in the new year to make sure it's working perfectly.

[JadeOfMaar]

@Booots I've begun exploring this mod myself (prodded by @eddiew) and have patched it to use a different resource. I haven't gotten to send anything through th beacons yet but what I've managed to notice is the tankage for the new resource is added beside, not replacing, the Karborundum tankage but that may be my needing to learn the new things in MM 3.0.

[JadeOfMaar]

My patches seem error-free but the parts still require Karborundum in-flight. I tried to change the beacons' Karborundum tank but my new resource either added beside it or the plugin re-added the Karborundum tank after being changed. these things are clearly hardcoded.  

[Booots]

37 minutes ago, JadeOfMaar said:

My patches seem error-free but the parts still require Karborundum in-flight. I tried to change the beacons' Karborundum tank but my new resource either added beside it or the plugin re-added the Karborundum tank after being changed. these things are clearly hardcoded.  

Are you using the existing beacons? I think I remember hard-coding the parts with the standard beacon names (or with the standard beacon name within the module) to use Karborundum when I was more concerned about backward compatibility. They shouldn't be re-adding the tanks, though, just using Karborundum for the jump. Like I said, though, I'll be taking a look at it after Christmas - I don't really have time to get into the code before I leave my dev computer for the holidays.

[JadeOfMaar]

No problem. Take your time and enjoy your holiday.

[Booots]

@JadeOfMaar Thanks! Merry Christmas / Happy holidays to you too! 

[eddiew]

7 hours ago, Booots said:

There should be a line in the config for the beacon where it says the resource to use. Unfortunately, I've had reports that it might be buggy and revert to using Karborundum regardless of what the config says. I'm going to be looking into that in the new year to make sure it's working perfectly.

Yeah, I did spot that and changed it to ElectricCharge, but it ate Karborundum anyway   But thank you for maintaining the mod, I look forward to it maturing and stabilising in the new year ^^

Meanwhile, I wonder if I can add some sort of resource converter for my personal stargates that would turn EC into Karborundum... a converter that needs vast amounts of ec/s...

[JadeOfMaar]

4 hours ago, eddiew said:

Meanwhile, I wonder if I can add some sort of resource converter for my personal stargates that would turn EC into Karborundum... a converter that needs vast amounts of ec/s...

Given the fact that we can't swap out Karborundum (and normally I'd reject the idea but), yes you can. PM me if you need a helping hand and a few second opinions.  

[eddiew]

23 minutes ago, JadeOfMaar said:

Given the fact that we can't swap out Karborundum (and normally I'd reject the idea but), yes you can. PM me if you need a helping hand and a few second opinions.  

Cheers   Never tried a resource converter from EC to anything, but I figured out how to turn ore into Argon for my (huge+heavy) Near Future ISRU unit, so I'm hoping it works the same way ^^

To be fair, these will be "ancient" stargates and not parts that will be used in the VAB. I quite like the idea that they just sort of recharge their own karborundum reserves over time. The one at Grannus will "just work", the Ciro gate will need a power supply adding to start its generator. They may also function in much stronger gravity fields, so one might be in the rings of Sarnus... My inner RP is strong today  

[eddiew]

If anyone else is pondering how to use ESLD beacons without having to install Karbonite*, you can add the following module to your beacons' configs:

	MODULE
	{
		name = ModuleResourceConverter
		ConverterName = Karborundum
		StartActionName = Start Karborundum Synthesis
		StopActionName = Stop Karborundum Synthesis
		AutoShutdown = true
				
		GeneratesHeat = false
		DefaultShutoffTemp = 0.8

		UseSpecialistBonus = true
		SpecialistEfficiencyFactor = 0.2
		SpecialistBonusBase = 0.05
		ExperienceEffect = ConverterSkill
		EfficiencyBonus = 1

		INPUT_RESOURCE
		{
			ResourceName = ElectricCharge
			Ratio = 5000
		}
		OUTPUT_RESOURCE
		{
			ResourceName = Karborundum
			Ratio = 5
			DumpExcess = false
			FlowMode = STAGE_PRIORITY_FLOW
		}
	}

The short version is that it will give the beacons a button to [Start Karborundum Synthesis], and top their supplies up given a big kick of electricity.

Obviously, this is quite cheaty, so everyone thank @JadeOfMaar for helping with the cheaty config for it /fingerpoint   My example generates no heat and thus requires no cooling. It does however need 5000 ec/s to synthesise and will only produce 5 Karborundum/s, so you're going to have to supply it with some seriously hefty and reliable power generation (Near Future nuclear reactors come to mind).

You may also prefer to have the ModuleResourceConverter take a second input, maybe 50 units of ore, or any mine-able material that is in your mod collection, in order to reduce the sense of guilt this config will give you  

Again, thanks to @Booots for picking up maintenance of this mod. I'm anticipating having some fun with it over the coming weeks ^^

 

* For the record, I have a lot of respect for the USI mod suite, but a lot of it is geared towards life support and sustainable colonies and resource supply chains, which don't really fit with my 'explore and move on' play style. As such, I preferred to save myself some memory with a dirty hack/patch.

[JadeOfMaar]

35 minutes ago, eddiew said:

Obviously, this is quite cheaty, so everyone thank @JadeOfMaar for helping with the cheaty config for it /fingerpoint   

I gave you that idea to help with your RP, and only your RP... If I saw this coming I would've kept quiet, lol.

Edited December 17, 2017 by JadeOfMaar

[Booots]

There is an included MM patch that adds Karborundum mining to the stock drills. I don't even play with Karbonite*/K+ myself. The resource definition is in CRP and with the stock drill mining Karborundum you can do anything you want. The trickiness is that surface Karborundum is in hard-to-reach places to keep in line with not making superluminal travel easy.

[eddiew]

34 minutes ago, JadeOfMaar said:

I gave you that idea to help with your RP, and only your RP... If I saw this coming I would've kept quiet, lol.

To be fair, there was an open discussion here about the inability to reconfigure the fuel requirements of beacons   I'll edit the above if @Booots has a problem with it though, was just trying to give everyone the benefit of your wisdom  

[Booots]

3 minutes ago, eddiew said:

To be fair, there was an open discussion here about the inability to reconfigure the fuel requirements of beacons   I'll edit the above if @Booots has a problem with it though, was just trying to give everyone the benefit of your wisdom  

It's fine, I was just pointing out that for the average user, one does not need Karbonite.