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

[Esquire42]

57 minutes ago, Booots said:

Can you confirm for me that you're using the most recent version? I saw this a lot during early testing with 1.2 but I thought I had it fixed. If you're up-to-date, I'll try to replicate it and get back to you if I need a log or savefile or something.

Is there a patch for 1.2.1? That might be it. I'm using the latest version but did update to 1.2.1 last night.

[Stoney3K]

On 6/7/2016 at 10:44 PM, Booots said:

Just to be clear: the official version of this mod will use Karborundum as the jump resource. Any patches that change that will only be for those few users who either don't want to add another resource or who want to use an alternate (ExoticMatter for example). As was pointed out above, the balance, economic, and playability reasons mean that a difficult-to-obtain resource like Karborundum is the way to go. But the ability to change the resource in configs instead of dealing with the source is good nonetheless.

It is possible to make the jump beacons "independent" of the resource used if you run the module off an imaginary "ExoticMatter", "QuantumFoam", "TachyonSoup" or whatever resource you want and have a set of parts which generate that resource according to balancing rules. Pretty much a variant on the stock ISRU which can take Karborundum (efficient), Ore (stupendously expensive) or XenonGas (same as Ore) along with a penalty of ElectricCharge consumption dependent on the resource you feed it, and turn that into your beacon-jump-fairy-dust resource.

Once your beacon jump fuel is full, it will allow the beacon to jump.

This allows you to set a resource system based on balancing and economics you want, and even nerf or buff it by slapping on additional parts, or enable users to re-balance the system or use different resources altogether using a ModuleManager patch. It does make the mod integrate with any resource set out there without it being dependent on a single one, or require players to re-configure resources if they have little knowledge of code. In other words, players that want to play "out of the box" with the rest of the game being totally stock, that would be possible (but horrendously inefficient), but once more mods are installed which open up resources, it allows for more versatile gameplay.

It also enables you to use the heat system using the stock ModuleResourceConverter which puts out heat when it's running. As long as the beacon is charging, it puts out a lot of heat, requiring cooling. More efficient resources (Karborundum) would charge the beacons rapidly without requiring a lot of EC per resource consumed and without putting out a crapton of heat, but abundant resources (Ore) would eat up a massive amount of EC to charge per unit resource and dump out heat at an enormous rate, requiring more radiators (which in turn eat up more EC to run).

So that means running a beacon off a stock resource like Ore is a possibility, but it would be a very big undertaking to build and keep running. You could even consider adding crew requirements to charge the beacons off anything else than Karborundum, requiring something like a dozen scientists to keep a close eye on the very unstable process of generating exotic matter which can tear a hole in space-time.

Edited November 3, 2016 by Stoney3K

[Booots]

On 11/3/2016 at 4:47 PM, Esquire42 said:

Is there a patch for 1.2.1? That might be it. I'm using the latest version but did update to 1.2.1 last night.

No, no 1.2.1 patch, but I'm on that version too, and it's working for me.

On 11/3/2016 at 5:20 PM, Stoney3K said:

It is possible to make the jump beacons "independent" of the resource used if you run the module off an imaginary "ExoticMatter", "QuantumFoam", "TachyonSoup" or whatever resource you want and have a set of parts which generate that resource according to balancing rules. Pretty much a variant on the stock ISRU which can take Karborundum (efficient), Ore (stupendously expensive) or XenonGas (same as Ore) along with a penalty of ElectricCharge consumption dependent on the resource you feed it, and turn that into your beacon-jump-fairy-dust resource.

This allows you to set a resource system based on balancing and economics you want, and even nerf or buff it by slapping on additional parts, or enable users to re-balance the system or use different resources altogether using a ModuleManager patch. It does make the mod integrate with any resource set out there without it being dependent on a single one, or require players to re-configure resources if they have little knowledge of code. In other words, players that want to play "out of the box" with the rest of the game being totally stock, that would be possible (but horrendously inefficient), but once more mods are installed which open up resources, it allows for more versatile gameplay.

So that means running a beacon off a stock resource like Ore is a possibility, but it would be a very big undertaking to build and keep running. You could even consider adding crew requirements to charge the beacons off anything else than Karborundum, requiring something like a dozen scientists to keep a close eye on the very unstable process of generating exotic matter which can tear a hole in space-time.

Yeah, one of the first things I added was the ability to configure the resource each beacon uses in its config. However, the OnLoad implementation vexes me and what should be working isn't quite. But once I find a fix to that, everything you mention could be done with MM patches or by new parts if someone wants to make them. Except crew requirements, that is. That would take some work on my end. Right now, there's just some performance bonus to the beacon in having certain qualifications onboard. Nothing yet as far as adding explodies with insufficient crews.

[Esquire42]

3 hours ago, Booots said:

No, no 1.2.1 patch, but I'm on that version too, and it's working for me.

I can try again sometime today just to make sure it's still not working, but otherwise I'm on the latest.

[g_BonE]

Nice mod, thanks a lot! Digging through the part configs i'd really like to get some more information on what the ESLDBeacon module settings do: coef, massfctr, massexp, distpow and basemult. Anyone cares to enlighten me?

[Zhetaan]

@g_BonE:

Not a problem!  I think I mentioned earlier in this thread that the settings are 'esoteric but understandable', so I suppose it was really only a matter of time before someone came along to test that.  Without further ado:

 

Cost = tonnage * baseMult + tonnage^{(1 + massFctr * (tonnage^massExp) + distPenaltyCost)} * tripDist^{(1 / 2^(distPow))} / yardStick * coef + baseCost

 

There are three terms.  I'll describe them as well as what the default values do to them for each beacon type (I won't include the IB-1 because its cost is calculated somewhat differently).

 

The baseCost term is about as straightforward as a modifier can get:

baseCost:  this is a flat toll just for using the beacon, configurable per beacon type.  The default beacons leave this value blank, so it is zero.

 

The tonnage term is also very straightforward:

tonnage:  this is the mass of the vehicle you want to jump.

baseMult:  this is a modifier on the tonnage, configurable per beacon type.  The LB-10 uses a value of 1, the LB-15 uses .35, and the LB-100 uses .25.  This means that the default beacons get better at sending mass as you go from LB-10 to LB-15 to LB-100.  They also send for longer distances, but there's no reason why this has to be so:  one could, for example, apply modifiers to make a custom beacon very mass-expensive but very distance-cheap, thereby encouraging featherweight probes for far-flung explorations a long way away.  Actually needing to do this is a pretty extreme edge case, but it can be done.

 

Now we get to the monster in the middle.  This is the distance-mass term, and it probably bears further explanation.  The important thing to remember is that distance and mass both play very strong roles here, but the modifiers are independent from the modifiers of the other terms.  This is what gives the beacons their flexibility.  The tonnage-based portion can be described as three different tonnage factors:

tonnage¹ says that the rest of the term gets multiplied by the straight tonnage, since anything to the power of one is itself.

tonnage^{distPenaltyCost} is really more about the value of distPenaltyCost, so I'll define that separately.

distPenaltyCost:  this is essentially the penalty clause for trying to go farther than you're meant to go with a low-power beacon.  It's actually based on the distance to travel, but it is added to the tonnage part of the equation.  It modifies the tonnage portion of the cost because modifying by the tonnage makes jumps prohibitive, but still possible.  The value of distPenaltyCost is either 0 or 2 depending on whether tripDist (trip distance) is longer than distPenalty (per beacon, but only the LB-10 has that value; it's set at one gigametre).  If tripDist is longer, then distPenaltyCost is 2 and the term is thus multiplied by the vehicle tonnage squared.  If tripDist is less, then distPenaltyCost is 0 and this part of the term does nothing.  Don't try to use an LB-10 to go interplanetary, kids.

tonnage^{massFctr * (tonnage^massExp)} is a highly complicated piece of mathematical wizardry that essentially modifies the tonnage twice.  The idea is that the two configurable variables play off one another to fine-tune the beacon's cost calculation.

massFctr:  first modifier for vehicle tonnage.  This modifier is usually very small:  the LB-10 is set at .001, the LB-15 at .0002, and the LB-100 at .00025.  The effect of such small numbers as exponents is that the graphs of these equations increase very slowly.  The LB-10 rises the quickest, which means that, all else being equal, it is more affected by mass than the other beacons, and the LB-15 is affected the least--but not all else is equal.

massExp:  second modifier for vehicle tonnage.  This modifier is usually an integer:  the LB-10 and LB-100 are set at 1; the LB-15 is set at 2.  Setting the LB-15 at 2 is the reason why the LB-15 suffers with high vehicle mass; the first modifier is not merely multiplied by tonnage squared, but is actually raised to the power of tonnage squared.  Wow!

But even that's not the whole story.  If you rearrange this part of the equation, it is algebraically equivalent to (tonnage^massFctr)^{(tonnage^massExp)}, which means that you can solve for the tonnage massFctr multiplier first.  That's important because massFctr's tiny exponents mostly result in values near one, which tempers somewhat the effects of other modifiers.  For example, the LB-15 has the smallest value for massFctr.  That reduces the effect of massExp for all low values of tonnage, but allows massExp (which is actually tonnage raised to massExp) to overcome this for high values.  If the LB-15 had a massFctr closer to the LB-10's, then it would suffer penalties all the time and would never be a good choice.  As it is, massExp cripples it anyway; you generally don't want to put more than 30 and never want to put more than 50 tonnes through it.

The distance based portion is mathematically simpler, but more subtle:

tripDist^{(1 / (2^distPow))}:  this is the main distance modifier.

tripDist:  distance to travel on a jump.

distPow:  main modifier for distance portion of the cost.  This value is 1 for the LB-10 and LB-15 and 3 for the LB-100.  This, more than anything else, is why the LB-100 is such a great long-distance beacon.  The form of the modifier makes it so that tripDist is taken to some root; if using the LB-10 or LB-15, then it works out to the square root of tripDist, but if using the LB-100, it works out to the eighth root of tripDist.

(1 / yardStick):  this modifier reduces tripDist by a Kerbal equivalent to astronomical units, modified by the beacon type.

yardStick:  this is equal to 13599840256^{(1 / 2^(distPow + 1))}.  13,599,840,256 is the distance, in metres, of Kerbin's semi-major axis with respect to the sun.  The effect is that when tripDist is taken to a root, yardStick is taken to double that root.  In other words, when using the LB-10, the distPow value is 1 so tripDist is taken to the 2¹ or square root.  That means that the value of YardStick is taken to the 2^{(1 + 1)}, which is the 2² or fourth root.  With the LB-100, tripDist is taken to the 2³ or eighth root, so yardStick is taken to the 2⁴ or sixteenth root.  The overall effect is that the LB-100 does a much better job with great distances, but isn't very good with short hops.  Using the figures here, the straight distance comparison gives the advantage to the LB-100 at about 115,000 metres--but of course that neglects the beacon-specific differences inherent in the other parts of the equation that push the advantage back quite a bit.

coef:  total cost modifier on the mass-distance term of the calculation.  The LB-10 is roughly .011, the LB-15 is roughly .0011, and the LB-100 is approximately .89.  The LB-100 is so high because it otherwise would be disproportionately cheap to operate if the value were comparable to those of the other beacons.  The LB-15 is so low because even with the restrictions on its disadvantages, it is disproportionately expensive to use without giving it a boost of some kind.  Thus, because it multiplies in somewhat separately, coef provides a way to tweak the balance of the cost for those cases where the tonnage and distance modifiers are good but the total cost still isn't right.  In fact, because it is taken as a constant from the configuration file, it is only effective over a range of distance and tonnage values. Over extreme distances, distPow overpowers coef and makes using the LB-100 for interstellar planet packs feasible--expensive, but feasible--and over extreme tonnages, massExp overpowers coef and makes using the LB-15 for heavy ships a waste of resources.

 

Sorry if I got a little mathsy there.  Make no mistake:  it is a complicated equation, but the values do make some sense if you're willing to play with a calculator a bit.

Edited December 6, 2016 by Zhetaan

[g_BonE]

Wow, that is what i call an indepth explanation. Thanks a lot mate! Sure it's a little on the mathematics side but nothing a good go with the calculator cant solve. Thanks a gain! *get's tinkering*

[Booots]

23 hours ago, Zhetaan said:

@g_BonE:

Not a problem!  I think I mentioned earlier in this thread that the settings are 'esoteric but understandable', so I suppose it was really only a matter of time before someone came along to test that.  Without further ado:

[ALL OF THE MATHS]

Wow! +1 to you for writing this out. This is exactly it.

If you're curious to visualize what effect any changes in those variables will have on a given trip cost, I have a MATLAB script that does exactly that in the spoiler below.

Spoiler

MATLAB Script for ESLD Beacons

My apologies for the lack of comments and that the variables are one letter instead of being written out like they are in the post above.

% Eeloo:    10^10.95 m
% Jool:     10^10.83 m
% Kerbin:   10^10.13 m
% Minmus:   10^7.67 m

% Pluto:    10^12.77 m
% Earth:    10^11.17 m

% GN: Algok-A:  10^13.95 m
% GN: M-Kel:    10^13.98 m
% GN: KPel:     10^14.00 m

yardstick = sqrt(sqrt(13599840256));
tonnage = linspace(5,200);%5:5:100;
tripdist = linspace(10000000,100000000000);
tripdist = linspace(10000000,1000000000*2);

tripdist = logspace(log10(tripdist(1)),log10(tripdist(end)),100);
tripdist = logspace(6,15);%12
tripdist = repmat(tripdist,length(tonnage),1);
tonnage = repmat(tonnage,size(tripdist,2),1)';
clearvars('COST');

B=[0,700,500,0,1000]/2000;
f=[0.001,0.0002,0.00025,0.0001666667,0.001];
e=[1,2,1,1,1];
b=[1,1,0.5,0.9];
h=[1,1,3,2,6];
i=[1,1,0.5,1,1/2^5];
m=[2.114743E-2,2.114743E-3,1.77301539];
m=[5E6^(-1/4),5E10^(-1/4),25000^(1/8)]/2;
m = m.*b(1:3);
BC = [0,0,0,0,200];
m(5) = 1;
COST = nan([size(tripdist),5]);
for CASE = [1,2,3]
switch(CASE)
    case{1}
        distpenalty = zeros(size(tripdist));
        distpenalty(tripdist > 1000000000) = 2;
        %distpenalty = (atan((log10(tripdist*0.8)-9)*10)/(pi/2)+1);
        %if (tripdist > 1000000000); distpenalty = 2;    end;
        cost = 000 + (power(tonnage, 1 + (0.001 * tonnage) + distpenalty) / 10) .* (sqrt(tripdist * sqrt(1/5E6)) / yardstick) ./ tonnage * 10000;
        cost = cost .* tonnage / 2000;
        cost = tonnage*B(CASE) + power(tonnage, 1 + f(CASE)*tonnage.^e(CASE) + distpenalty).*power(tripdist,1/2^h(CASE))*m(CASE)/yardstick^(i(CASE));
        
        %cost=((Math.Pow(tonnage, 1 + (.001 * tonnage) + distpenalty) / 10) .* ((Math.Sqrt(Math.Sqrt(tripdist .* (tripdist / 5E6)))) / yardstick) ./ tonnage * 10000) .* tonnage / 2000;
%         figure(2)
%         plot(tripdist(1,:),distpenalty(1,:));
        clearvars('distpenalty');
    case{2}
        cost = 700 + (power(tonnage, 1 + (0.0002 * power(tonnage, 2))) / 10) .* (sqrt(tripdist * sqrt(1/5E10)) / yardstick) ./ tonnage * 10000;
        cost = cost .* tonnage / 2000;
        cost = tonnage*B(CASE) + power(tonnage, 1 + f(CASE)*tonnage.^e(CASE)).*power(tripdist,1/2^h(CASE))*m(CASE)/yardstick^(i(CASE));
        
        %cost = (700 + (Math.Pow(tonnage, 1 + (.0002 * Math.Pow(tonnage, 2))) / 10) .* ((Math.Sqrt(Math.Sqrt(tripdist .* (tripdist / 5E10)))) / yardstick) ./ tonnage * 10000) .* tonnage / 2000;
    case{3}
        cost = 500 + ((power(tonnage, 1 + (0.00025 * tonnage)) * 0.5) / 10) .* ((sqrt(sqrt(sqrt(tripdist * 25000)))) / sqrt(yardstick)) ./ tonnage * 10000;
        cost = cost .* tonnage / 2000;
        cost = tonnage*B(CASE) + power(tonnage, 1 + f(CASE)*tonnage.^e(CASE)).*power(tripdist,1/2^h(CASE))*m(CASE)/yardstick^(i(CASE));
        
        %cost = (500 + (Math.Pow(tonnage, 1 + (.00025 * tonnage)) / 20) .* ((Math.Sqrt(Math.Sqrt(Math.Sqrt(tripdist * 25000)))) / Math.Sqrt(yardstick)) ./ tonnage * 10000) .* tonnage / 2000;
    case{4}
        cost = 000 + ((power(tonnage, 1 + (0.00016667 * tonnage)) * 0.9) / 10) .* ((sqrt(sqrt(tripdist + 2E11))) / yardstick) ./ tonnage * 10000;
        cost = cost .* tonnage / 2000;
    case{5}
        cost = tonnage*B(CASE) + power(tonnage, 1 + f(CASE)*tonnage.^e(CASE)) .* power(tripdist,1/2^h(CASE))*m(CASE)/yardstick^(i(CASE))+BC(CASE);
        figure(2)
        surf(tripdist,tonnage,cost)
        set(gca,'xscale','log');
end;

COST(:,:,CASE) = cost;
figure(1)
subplot(2,3,CASE);
han = surf(tripdist,tonnage,cost);
xlabel('Distance, m');
ylabel('Tonnage, tonne');
zlabel('Cost, units');
z = zlim();
zlim([0,min(750,z(2))]);
caxis(zlim());
shading interp
set(gca,'xscale','log');
set(han,'edgecolor','k');
clearvars('z','han');
end;

optModel = zeros(size(COST(:,:,1)));
best = nan(size(COST(:,:,1)));
for i = 1:size(COST,1)
    for j = 1:size(COST,2)
        optModel(i,j) = find(min(COST(i,j,:))==COST(i,j,:));
        best(i,j) = COST(i,j,optModel(i,j));
    end;
end;
clearvars('i','j');
%figure(2)
subplot(2,2,3)
surf(tripdist,tonnage,optModel)
xlabel('Distance, m');
ylabel('Tonnage, tonne');
set(gca,'xscale','log');
view([0,90]);
subplot(2,2,4)
han = surf(tripdist,tonnage,best,optModel);
xlabel('Distance, m');
ylabel('Tonnage, tonne');
zlabel('Cost, units');
z = zlim();
zlim([0,min(2000,z(2))]);
caxis(zlim());
caxis([1,4]);
shading interp
set(gca,'xscale','log');
set(han,'edgecolor','k');
clearvars('z','han');

% figure(2)
% surf(tripdist,tonnage,COST(:,:,4))
% set(gca,'xscale','log');

 

 

[Jim Starluck]

On 11/3/2016 at 3:08 AM, Esquire42 said:

I think i saw this issue in the other thread a long time ago but I'm not digging through it at midnight, so my apologies if this is asked and answered.

 

I'm getting an error where when trying to activate a beacon the in-game text says something along the lines of "Activation Failed! - No Electric Charge" but there is f***loads of electric charge on the beacon vessel and another s***load being generated by a NFE reactor. Is there a stupid solution that I'm missing or?

Apologies for posing in a dormant thread, but I've started testing out the beacons from this mod myself and I'm running into the same issue.

I have a pair of test beacons that I'm using to get a feel for how the mechanics work. Both of them were activated previously in Kerbin orbit, but I moved one out to Minmus. It's now in a circular Minmus orbit at an altitude of 2,000 km, and the beacon is refusing to activate. It has plenty of electric charge and karborundum aboard, but when I hit the "Initialize" button this is what I get:

 

I'm guessing there's something screwy going on with the part about the EC cost to initialize the beacon. Maybe because I had it already initialized when it entered the Minmus SOI or something?

[Booots]

13 hours ago, Jim Starluck said:

Apologies for posing in a dormant thread, but I've started testing out the beacons from this mod myself and I'm running into the same issue.

I have a pair of test beacons that I'm using to get a feel for how the mechanics work. Both of them were activated previously in Kerbin orbit, but I moved one out to Minmus. It's now in a circular Minmus orbit at an altitude of 2,000 km, and the beacon is refusing to activate. It has plenty of electric charge and karborundum aboard, but when I hit the "Initialize" button this is what I get:

I'm guessing there's something screwy going on with the part about the EC cost to initialize the beacon. Maybe because I had it already initialized when it entered the Minmus SOI or something?

Hey! No worries, this is the thread for these. It's just grown a bit quiet of late.

Um, yeah... I've experienced the same issue from time to time. I thought I had it fixed, though, in the most recent version. Maybe it just needs an overhaul and complete rewrite. Can you confirm that you have v0.9 installed? Can I also get a link to the log file when this happens?

[Jim Starluck]

11 hours ago, Booots said:

Hey! No worries, this is the thread for these. It's just grown a bit quiet of late.

Um, yeah... I've experienced the same issue from time to time. I thought I had it fixed, though, in the most recent version. Maybe it just needs an overhaul and complete rewrite. Can you confirm that you have v0.9 installed? Can I also get a link to the log file when this happens?

Definitely using v0.9. Will try to get the log file, but fair warning; I have a bazillion other mods installed.

[Jim Starluck]

On 4/18/2017 at 0:11 PM, Booots said:

Hey! No worries, this is the thread for these. It's just grown a bit quiet of late.

Um, yeah... I've experienced the same issue from time to time. I thought I had it fixed, though, in the most recent version. Maybe it just needs an overhaul and complete rewrite. Can you confirm that you have v0.9 installed? Can I also get a link to the log file when this happens?

Double-posting to make sure you see this.

Here's the KSP.log file: https://www.mediafire.com/?09ppcqiyfq5a5mz

During the session this should cover I flew a few different ships, but made sure to visit the misbehaving beacon and hit its "Initialize" button a few times in a row.

 

I don't know if KSP is still actually using output_log.txt; if it is, I couldn't find one that's been updated anytime recently.

[Drew Kerman]

1 hour ago, Jim Starluck said:

if it is, I couldn't find one that's been updated anytime recently.

Then you should re-install KSP because this log should definitely be getting updated. It will either update in the KSP_Data folder if you run the 32-bit executable or the KSP_x64_Data folder if you run the 64-bit executable

[Booots]

On 2017-04-20 at 1:26 AM, Drew Kerman said:

Then you should re-install KSP because this log should definitely be getting updated. It will either update in the KSP_Data folder if you run the 32-bit executable or the KSP_x64_Data folder if you run the 64-bit executable

The one you want should be KSP.log

[Drew Kerman]

3 minutes ago, Booots said:

The one you want should be KSP.log

most mod developers ask for output_log.txt as that contains more detailed data than KSP.log. Anyways, even if you prefer KSP.log the fact remains that his game should be creating an output_log.txt and if it is in fact not doing so than there may be more issues at play here than just related to this mod

[Jim Starluck]

...okay. Well.

Turns out that when you uninstall something via Steam it does not, in fact, leave files that weren't part of the original install behind. Did not know that.

 

So much for that save.

[Drew Kerman]

On 4/24/2017 at 1:45 AM, Jim Starluck said:

So much for that save.

I use CrashPlan for local secondary and online tertiary backups. $6/mo - small price to pay.

But yea... I too would not have thought that would be the behavior of Steam when uninstalling games. There may have been a "Remove Game Data" option that you could have missed, I do see that for some uninstall procedures. It could also be due to KSP not saving its games withing the My Documents folder - I do indeed have save data from old Steam games still in there

[Jim Starluck]

18 hours ago, Drew Kerman said:

But yea... I too would not have thought that would be the behavior of Steam when uninstalling games. There may have been a "Remove Game Data" option that you could have missed, I do see that for some uninstall procedures. It could also be due to KSP not saving its games withing the My Documents folder - I do indeed have save data from old Steam games still in there

If I'd expected it to do that I'd have just backed everything up. I even tried using a Windows Restore Point to revert back to last Friday, but it failed.

I'll see if I can replicate the circumstances of the glitch in sandbox mode at some point.

Oh, and as far as I can tell, KSP still isn't generating an output_log.txt after the reinstall.

[Drew Kerman]

2 minutes ago, Jim Starluck said:

I even tried using a Windows Restore Point

Yea that wouldn't work Windows Restore only affects system files (Windows updates, driver updates, etc), it doesn't touch anything else

54 minutes ago, Jim Starluck said:

Oh, and as far as I can tell, KSP still isn't generating an output_log.txt after the reinstall.

I... yea I don't know. You're not like, running Windows on a Mac or something are you? You checked both data folders I specified earlier? If you look and see the file but see that it's 0bytes that's cause it's being written to while the game is running, if you open it you'll see what's been added so far. AFAIK this file is not an optional inclusion in the debugging process - at least I've never seen anyone instruct someone to enable it

[Rodger]

On 18/04/2017 at 0:11 PM, Jim Starluck said:

Apologies for posing in a dormant thread, but I've started testing out the beacons from this mod myself and I'm running into the same issue.

I have a pair of test beacons that I'm using to get a feel for how the mechanics work. Both of them were activated previously in Kerbin orbit, but I moved one out to Minmus. It's now in a circular Minmus orbit at an altitude of 2,000 km, and the beacon is refusing to activate. It has plenty of electric charge and karborundum aboard, but when I hit the "Initialize" button this is what I get:

 

I'm guessing there's something screwy going on with the part about the EC cost to initialize the beacon. Maybe because I had it already initialized when it entered the Minmus SOI or something?

I just had this too, and if you just dump some fuel or something to update the ship's mass it should work itself out

[cyberKerb]

On 4/18/2017 at 0:11 PM, Jim Starluck said:

Apologies for posing in a dormant thread, but I've started testing out the beacons from this mod myself and I'm running into the same issue.

I have a pair of test beacons that I'm using to get a feel for how the mechanics work. Both of them were activated previously in Kerbin orbit, but I moved one out to Minmus. It's now in a circular Minmus orbit at an altitude of 2,000 km, and the beacon is refusing to activate. It has plenty of electric charge and karborundum aboard, but when I hit the "Initialize" button this is what I get:

I'm guessing there's something screwy going on with the part about the EC cost to initialize the beacon. Maybe because I had it already initialized when it entered the Minmus SOI or something?

I suspect you're too far from Minmus for the LB10 beacon to operate.

Worked fine for me. However, I checked around the orbits to see what did and didn't work and found it does have a maximum range as well. This isn't surprising seeing as it's built for in system transfers

If you continue to use the LB10 - can you try a Minmus Orbit between 15K - 534k and activate there? The max distance is probably a function of the mass of the ship the beacon is attached to, so that 534K is probably a very subjective figure.

Side Note: If you add (and activate) a Gravitational Mitigator part to your ship, the max orbit goes out to about 1,819k which would still be under the 2000k orbit you've been testing at.

Having said that, I also checked the LB15 device for the same orbits around Minmus. The LB15 operating orbit range around Minmus goes from 15K - 955k with NO Gravitational Mitigator. With the GM, it's range is past the Minmus SOI - so it would cover anything around Minmus so long as you were above 15km.

 

Here might be a good place to suggest @Booots add a few extra error messages to the Beacon initialise process. It seems the "Activation Failed! - No Electric Charge" message is catching a few exceptions rather than just no electric charge.

Here's my suggestions for a few extra error messages to help people troubleshoot their issues:

Orbit too high:
There is already a error message for when a ship is too close to a body, could we get a separate specific message "outside of operating radius" or something when the beacon is too far? Above example of being in a 2,000K orbit around Minmus with a LB10 when it wont activate unless the beacon is below ~534k depending on ship size.

No Karborundum:
It seems that Karborundum needs to be on-board for the beacon to startup, could a specific error message be added to indicate that was the reason the beacon didn't activate?

I did find an admittedly old update (for KSP 1.1.3) where it mentioned that Karborundum was no longer required on board to initialise a beacon. I'm using ESLD version 0.81 and I can only start the beacon when it has Karborundum in a tank somewhere. I chked the rest of this thread and missed / couldn't find any mention that it was a requirement again. Also, I can't see anything in the Beacons cfg file that allows for configuring this requirement. Is it in a different file I'm not looking at? Or did this requirement never get removed/re-added in a later update?

 

Edited April 28, 2017 by wile1411
forgot max distance is probably subjective to ship mass

[Drew Kerman]

On 4/25/2017 at 11:44 PM, Jim Starluck said:

Oh, and as far as I can tell, KSP still isn't generating an output_log.txt after the reinstall.

I just saw in another thread that someone found it in their AppData/LocalLow folder. First I've heard of this but you may wanna check that out in your Windows "User" folder

[cyberKerb]

Hope this gets updated to support 1.3

I love using this in my career and trying to get the beacons as close as possible to the distant bodies. I can't live without it
(I use MKS & LS so it helps for late game rescue missions)

[Commander Valhallion]

Hello,

 

I'm currently running 1.2.2 and I don't know if I'm just suffering from a kerbal level of idiotcy or if it is the mod itself.

I placed two ships in orbit, one around minimus at 17k and another around kerbin at 400K. I attached all the necessary parts and more than enough various fuels to power the beacons, but no matter what the beacons cannot be located in the drop down menu. Am I missing something or does it not work for 1.2.2?

[cyberKerb]

I think it should work based on what you've mentioned- If you can make the 2 craft files available I'll troubleshoot it for you.