Jump to content

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


Booots

Recommended Posts

Credit to @TMarkos for the original mod. Until such time as he returns, I'll be maintaining and continuing this mod. Original forum thread.

jiTnfSh.png

The Extra-Kerbin Space Technology Research Agency's Superluminal Logicstics Division (EKSTRA SLD) (ESLD) is proud to present their first-ever public release of technology. As colony-building becomes a more common project, Kerbals are spending too much idle time between the stars. This will not do! The ESLD Beacon network will get your Kerbals from point A to points B through Z in no time at all, presuming you've positioned and fueled them, read the warning manual and installed all necessary safeguards. The ESLD is not liable for any deaths or insurance claims that result from the use of our beacons.

Wiki

Javascript is disabled. View full album

These are not cheaty, easy jump beacons. They incorporate:

  • Line of sight checking.
  • Gravity restrictions (also checked under LoS).
  • Incredibly costly fuel. More on that in a second.
  • Scaling fuel costs with tonnage/distance.
  • Tech advancements that allow increased capability.
  • Proximity requirements for activation.
  • Unique beacon models optimized for different transport scenarios.
  • The general process to use this network is to place at least two beacons, then approach one with a hailer (currently just MM'd into the stock antennas). The hailer allows you to open a dialog window with the active beacon, where it will tell you what other active beacons it can see and if it has enough fuel to send you there. Assuming it does on both counts, press the button and off you go.

Fuel is an important consideration, because it's what keeps the beacon system balanced in career mode. True to the maxim that you can choose two from the list of fast, cheap and high-quality, the jump fuel that makes the system tick is incredibly costly, to the extent that most transfers the beacon system performs are more expensive than or comparable to traditional rocketry-based solutions. Time is the ONLY thing you save with beacons, and some players may even plow more into logistics than they would otherwise have cause to do if they feel like maintaining an accessible and fueled beacon network at all times. The mod includes a cfg to allow players to use stock extraction parts to obtain Karborundum.

I'll put this here for my own sanity: if you're playing career, at the start your beacons won't be able to safely transport Kerbals, Karborundum or a variety of other high-energy resources. There will be warnings in the pre-jump window if something bad is about to happen. READ THE WARNINGS.

MufyFKo.gif

Link to post outlining optimal beacon types to use:

Link to post on the lens beacons:

Part.cfg changes powered by sarbian & ialdabaoth's ModuleManager plugin - this is a dependency.

Released under the GPL2 license.

Download Link: Github SpaceDock

Also available on CKAN

Changelog:

Spoiler

0.8:

  • Added action group capability to beacons and tech boxes.
  • Added editor information for beacons and tech boxes.
  • All beacons now use generic coefficients for cost instead of hard-coded formulas (IB-1 excepted).
  • Fixed model orientation of tech boxes.
  • Background performance improvements.
  • Updated bundled CRP.

0.7B:

  • Fix DDS textures.
  • Fix animations and emissives
  • Remove the extraneous ModuleAnimateGeneric that used to be required.

0.7a:

  • Fix GUI to work with KSP's change to Unity v5.
  • Fix collider meshes on beacons.
    • Textures changed to .tga because that's the only way I could get Unity to build the .mu files. Switch back to .dds at your own risk.
  • Simplify collider mesh and visual mesh of the tanks to improve performance.
  • Partially implement the ability to define new beacons via .cfg's.

 

Edited by Booots
Link to comment
Share on other sites

Yes, maintenance thread. The good stuff. In other news, I'll be working on a model/cfg for an extra-solar beacon, for those who use mods that enable multiple star systems and don't want to spend obscene amounts of fuel and electricity just to get to your base in the next system over. If you have any ideas for the design/costs, post away.

Link to comment
Share on other sites

Yay, new thread!

As I posted in the other thread, thank you a ton for doing this.:)

By the way, I downloaded it this morning and the MM bundled was .24, whereas the latest is .25.

Cheers.

EDIT:

A few things:

  • Apparently also the download includes both the TGA and the DDS textures.
  • The Hailer patch could probably use a :FOR, and maybe a :NEEDS (not sure if :AFTER implies :NEEDS)
  • There is apparently a quasi-duplicate "Shortcut" Beacon (labeled LB12.cfg).
  • Should also probably mention explicitly that these are fueled by Karborundum and thus Karbonite/Karb+ is somewhat of a dependency. A Kethane conversion patch wouldn't be amiss. Or a patch that uses something like XenonGas Ore or something "stock."

EDIT2:

Do you even need the animations? Because looking at the NREs, my interpretation is the name has changed along the way, and is no longer what is in the animationName field. Commenting out the animation module entirely removes the NREs, which might not be the "solution" you were looking for.

Edited by Deimos Rast
Link to comment
Share on other sites

1 hour ago, Deimos Rast said:

By the way, I downloaded it this morning and the MM bundled was .24, whereas the latest is .25.

A few things:

  • Apparently also the download includes both the TGA and the DDS textures.
  • The Hailer patch could probably use a :FOR, and maybe a :NEEDS (not sure if :AFTER implies :NEEDS)
  • There is apparently a quasi-duplicate "Shortcut" Beacon (labeled LB12.cfg).
  • Should also probably mention explicitly that these are fueled by Karborundum and thus Karbonite/Karb+ is somewhat of a dependency. A Kethane conversion patch wouldn't be amiss. Or a patch that uses something like XenonGas Ore or something "stock."
  • Ah, my bad. My own MM was out of date. Fixed!
  • The TGA and DDS are both there because my .mu exports would only cooperate with using TGA. If your textures work without the UV maps getting messed up using the DDS, go for it! Mine break, but I'm going to work on fixing it so we can use the DDS textures.
  • Good call on the hailer patch. Fixed!
  • LB12! Oh shoot! That's my testing one. Nobody use it because it will be removed. In fact, it's already gone. Fixed!
  • Mhmm... Karbonite... It actually only depends on the CRP, which is bundled. Personally, I've MM'd the stock drills into mining Karborundum for me because I don't use Karbonite. What would you suggest for a Kethane conversion? Like, just let them run on raw Kethane? Using something stock would be nice, but would make things suddenly unbalanced because the jump fuel could be obtained almost anywhere. Further complicating things is that the Karborundum requirement is presently hardcoded in until I can figure out how to load that from the .cfgs. Will continue working on this...

The previous download link has been fixed to reflect these fixes.

Thanks for the feedback!

Edited by Booots
Link to comment
Share on other sites

Here is a patch as I suggested above. I suggest making the Beacons have no Karb, and have patches add in the respective resource (I'd have to rewrite this, but whatever). I don't really know the proper ratio for Karborundum:Kethane:Ore, and I suspect I am way off (I don't have much experience with ISRU), but as it stands if Karbonite/KPlus aren't installed it replaces Karborundum with 2x the Ore amount (probably way low); if Kethane is installed, it replaces it with 1.5x the Kethane amount.

Special Note: this amount is not Tweakable (since Karbonundum is not Tweakable) and starts at 0, meaning it cannot be adjusted or added to in the editor and as such will not show up in the editor (but will still show up in the part listing). This can be changed in the config (isTweakable = false).

Also note: I don't have Kethane or Karbonite installed at the moment, so please let me know if it doesn't work properly.

Cheers.

--EDIT--

REMOVED PATCH PENDING FURTHER TESTING

Well my patch just sort of crudely deletes your Karb resource at the moment...are you saying it's hard coded into the plugin?

 

 

Edited by Deimos Rast
Link to comment
Share on other sites

17 minutes ago, Deimos Rast said:

...are you saying it's hard coded into the plugin?

Yeah... It's been that way since the beginning, as far as I can tell. It's next on my to-do list to fix because hard coding anything is shameful.

Link to comment
Share on other sites

22 minutes ago, Booots said:

Yeah... It's been that way since the beginning, as far as I can tell. It's next on my to-do list to fix because hard coding anything is shameful.

Well that killed that patch in a hurry.:P

And it goes without saying: thanks again and take your time. There's no real rush.:)

For future reference: do you use github issue tracker or are forum posts better?

Link to comment
Share on other sites

Hello and congratulations on the release!

I've been following this with some interest for some time, and though I am by no means an old-timer, there are a couple of things I can throw at you from the annals of history and elsewhere to continue to discuss some of the questions that have come up here.

First, the hard-coded dependency on Karborundum, as I understood it, was created because this mod invented Karborundum.   When he released Karbonite, RoverDude left an open invitation for people to expand it, and TMarkos took him up on that invitation with this.  Karborundum's reason for existence was to be a fantastically expensive, more fantastically difficult-to-harvest unobtainium to balance what otherwise amounted to an in-universe Hyperedit, and ESLD was built around it with that mentality.  It tied the acquisition of Karborundum into RoverDude's Karbonite/ORSx, then Karbonite/Regolith resource framework (which is now essentially the stock resource framework) as a way of outsourcing the drilling/mining part, leaving TMarkos to focus on the beacons and their operation instead.  RoverDude, in turn, liked the idea of a super-powerful, super-difficult-to-obtain, essentially-endgame resource, so he incorporated Karborundum into his mod constellation as K+ and expanded it with other stuff.  Using it as some kind of equivalent to (warning--nerd moment) Stargate's naquadah and naquadria for engine fuel, for example, was RoverDude's idea.  That's why this mod ships its own Karborundum tanks instead of using the ones that are now available in K+; you originally needed Karbonite (so TMarkos could use Karbonite's drills and ISRU converter) but there was no way to store Karborundum because there was no other mod that supplied it.

My point is that the hard-coded dependency is not so much an error to be fixed as it is a feature of the mod, in much the same way that beacons are a feature to use instead of Hyperedit.  Given what it's supposed to do, calling it shameful to be hard-coded is equivalent to saying that it sucks that Kethane is hard-coded into the Kethane mod, or that Oxygen is hard-coded into TAC Life Support.  That being said, so long as you can maintain some balance in terms of Karborundum's availability and value versus what the beacons do, there's nothing keeping you from setting up ESLD to use something else and having it work just as well.

As far as availability, there are still configuration files for putting Karborundum in other places (I recall that Tylo, Dres, and Ike were the locations used) as well as a file for letting you purchase it in the VAB, if you want to use what already exists.  The next-most-expensive resource, I think, is Xenon, and Xenon is currently available in stock only in the VAB.  There may be opportunities there.

The only remaining issue, then, would be those players who simply do not wish to contend with another resource when they already have resource-adding mods such as Kethane.  The way it used to work was that if you had RoverDude's full suite of mods, those (warning--nerd moment) Stargate-esque engines would be completely overpowered if Karborundum was easy to get, so you had to harvest Karborundum from Eve, Eeloo, or just above the surface of the Sun.  However, if you only had Karbonite, then the only thing that used Karborundum was ESLD and so you could turn Karbonite into Karborundum with ISRU at some awful efficiency.  (@Deimos Rast) I think the conversion was less than one Karborundum for every thousand Karbonite--I never bothered with it and went sundiving instead.

Obviously, the easy thing would be to simply declare the dependency, but all of the functionality that Karbonite provided exists in stock parts now (essentially unchanged, even), so changing things to use the stock drills and ISRU instead of the Karbonite drills and distiller is certainly a valid course.

The short version is this:  Karborundum is a dependency for reasons of balance, and eliminating that dependency requires the mod to use something similarly expensive to maintain that balance.  No such resource exists, so doing this may create more problems than it solves.

Second, on the subject of interstellar beacons, without knowing the scale of distance between stars for the various packs that use multiple stars, you might have the best luck by saying that the energy cost of beacon transfer over arbitrarily large distances approaches some asymptotic value rather than trying to calculate distances that, themselves, are likely completely arbitrary, or worse, having to write some detection code to identify stars, catalogue stars, determine whether two stars are a binary system, rewrite it all and scream in frustration when someone puts up a rogue planet pack for Kopernicus, &c.  If need be, you could even technobabble your way out of it by saying that the beacon works by taking advantage of an inverted relationship in physics:  in orthospace, the speed of light is finite-but-large, and it takes infinite energy to accelerate a mass to that speed.  In whatever hyperspace the beacons use, the speed is infinite and it takes finite-but-still-large energy to accelerate things to that speed (more likely, it enters at that speed as some sort of superneutrino, because in a universe with an infinite speed of light, space, time, and matter cannot exist).  Once this is done, well, speed is infinite, so the cost to go to the next star is the same as the cost to go to the next galaxy--or to the other side of the observable universe (because when there's no time and space, getting anywhere is a snap).  The caveat and balancing cost in these ultra-long-distance cases would be more that the receiving equipment (and the fuel for it) has to be sent there the slow way first.

In short:  just set some high, fixed, base price for interstellar transfer (defined as anything beyond a minimum distance) and leave it at that.  Correcting for the disparate stellar velocities will keep the costs random enough to avoid being too predictable.

Additionally, there is a market for some sort of long-range in-system beacon.  Anyone who plays with OPM or RSS-scaled systems will have much larger distances to cover, though it should not be too difficult to work out those distances and, on detecting the mods, use MM patches to scale the costs and capabilities accordingly.  The cost modifiers in the configuration files are esoteric but understandable.

Edited by Zhetaan
Link to comment
Share on other sites

Short answer, because this is over breakfast at the moment and I haven't had coffee yet (and posting without coffee in the system leads to embarrassment): but I think he means shameful from a coding perspective (I think you already get that; it's a strong word, but he can clarify). I'm the classic case (e.g. notepad jockey), where if it doesn't happen in a config that I can open with a text editor, then it might as well not exist. Plugins scare me, and if I can't write a MM patch to fix it, then... well...I don't know what to do.

As I mentioned, I don't have much experience with ISRU, so for me, one "ore thingy" is like another, except one is not tweakable (Karborundum) and then it's a matter of ratios. Admittedly, that's not the best CV for someone to be writing a patch on something like this, but it seemed like a fine idea at the time. The reason I think Kethane might be feasible, in large quantities, as I understand it, is it's resources are finite, but I haven't played with that mod in a while.

The point is to not make this content already more restrictive than it already is. I mean that tech wise, cost wise, time wise, and mod dependency wise. For balance, you need to make it somewhat restrictive (time/cost/tech) - I just mildly object to the mod dependency issue, more as a matter of principle than anything else. I pretty much agree with everything you said, and my answer is still "do it anyway." Making it an optional patch would be the ideal answer. Of course, all of this is irrelevant, if Karborundum is hardcoded into the beacons.:P

(I've since redownloaded and installed RoverDude's entire suite of mods just to test this mod. Unnecessary, but they go so well together.)

Edited by Deimos Rast
Link to comment
Share on other sites

Part the first

3 hours ago, Zhetaan said:

Hello and congratulations on the release!

First, the hard-coded dependency on Karborundum, as I understood it, was created because this mod invented Karborundum.   When he released Karbonite, RoverDude left an open invitation for people to expand it, and TMarkos took him up on that invitation with this.  Karborundum's reason for existence was to be a fantastically expensive, more fantastically difficult-to-harvest unobtainium to balance what otherwise amounted to an in-universe Hyperedit, and ESLD was built around it with that mentality. [SNIP]

My point is that the hard-coded dependency is not so much an error to be fixed as it is a feature of the mod, in much the same way that beacons are a feature to use instead of Hyperedit.  Given what it's supposed to do, calling it shameful to be hard-coded is equivalent to saying that it sucks that Kethane is hard-coded into the Kethane mod, or that Oxygen is hard-coded into TAC Life Support.  That being said, so long as you can maintain some balance in terms of Karborundum's availability and value versus what the beacons do, there's nothing keeping you from setting up ESLD to use something else and having it work just as well.

[SNIP] The next-most-expensive resource, I think, is Xenon, and Xenon is currently available in stock only in the VAB.  There may be opportunities there.

The only remaining issue, then, would be those players who simply do not wish to contend with another resource when they already have resource-adding mods such as Kethane.  [SNIP]

Obviously, the easy thing would be to simply declare the dependency, but all of the functionality that Karbonite provided exists in stock parts now (essentially unchanged, even), so changing things to use the stock drills and ISRU instead of the Karbonite drills and distiller is certainly a valid course.

The short version is this:  Karborundum is a dependency for reasons of balance, and eliminating that dependency requires the mod to use something similarly expensive to maintain that balance.  No such resource exists, so doing this may create more problems than it solves.

Thanks! It's always super heartening to see that people besides myself have an interest in this. There's only so many hours of Hohmann transfers that can be done before one just wants to do the hard part of launch, EDL, and colonization and wants a fast way of moving around the solar system.

2 hours ago, Deimos Rast said:

...I think he means shameful from a coding perspective (I think you already get that; it's a strong word, but he can clarify).

I did. I spent four months last summer removing arbitrary hard-coded limitations to a program I need for my masters. My new belief system is that everything should be user-configurable, even if it does have default values.

I'm 100% in agreement with the rationale for Karborundum as a resource. If it's not nearly impossible to obtain, this mod easily becomes overpowered. If a player can just launch a beacon already fueled, they may as well just have HyperEdit. This is why I'm somewhat reticent to make patches changing it to any existing resources because they can't be hard to obtain because regular players need them around. That being said, your suggestion of using XenonGas is a good one, because it is hard to produce, costly to buy, and, if required in ludicrously huge quantities (which I would want) difficult to store/transport. Despite my misgivings about changing the resource consumed in jumping, I went ahead and provided the ability to change the resource required (and the amount) in a subnode (or several, for multiple resources) of the part module. The download has been updated to reflect these changes, so feel free to test them. This change is backward compatible in that if no resource is specified for one of the existing beacons, it adds Karborundum by default. For new beacons, however, if no resource is specified in the config node, it should (haven't tested this) jump for free *cringe* (for configurability's sake).

From this point, ModuleManager should be able to edit the node for those who want to use something else instead. I will be open to providing patches in the 'Extras' folder for Stock-only (either ISRU creation of Karborundum or a XenonGas replacement), or a Kethane patch (again, either creation or replacement).

 

Part the second

3 hours ago, Zhetaan said:

[SNIP] The caveat and balancing cost in these ultra-long-distance cases would be more that the receiving equipment (and the fuel for it) has to be sent there the slow way first.

In short:  just set some high, fixed, base price for interstellar transfer (defined as anything beyond a minimum distance) and leave it at that.  Correcting for the disparate stellar velocities will keep the costs random enough to avoid being too predictable.

Additionally, there is a market for some sort of long-range in-system beacon.  Anyone who plays with OPM or RSS-scaled systems will have much larger distances to cover, though it should not be too difficult to work out those distances and, on detecting the mods, use MM patches to scale the costs and capabilities accordingly.  The cost modifiers in the configuration files are esoteric but understandable.

True! Good call! This also simplifies things in that I don't need to determine if something is a different star. The new beacon can just have a higher base jump cost than any normal in-system jump but that doesn't increase with distance. I really should distribute an OPM/RSS patch. I'll add that to the to-do list.

"esoteric but understandable" :D Those cost modifiers were one of the first things I added to this mod. The source code has the actual formula for using those. I made a Matlab script to plot the tonnage/distance surface of jump cost because otherwise it can be kind of hard to visualize. If I strayed a little from the original formula I could probably make a function that is easier to define/visualize.

 

Part the third

On 2016-06-04 at 8:32 PM, Deimos Rast said:

Well that killed that patch in a hurry.:P

And it goes without saying: thanks again and take your time. There's no real rush.:)

For future reference: do you use github issue tracker or are forum posts better?

I'm new to Github, but issue trackers are fantastic. I'm liable to lose bug reports in how busy this forum thread is. :P Thanks for trying to make patches. Like I said, I am open to them and will add them to the distribution under 'Extras' if I think they maintain the balance a mod like this needs.

Edited by Booots
Formatting
Link to comment
Share on other sites

Regarding patches: you could go the extra step and having them disabled by default (just change the extension from .cfg to .disabled). Also: is it even possible to produce XenonGas in stock? I know some mods add it in (my problem is I've strayed from the stock game for so long I forget what is what).

Also, I should add, I'm one voice here and so far the only one in the "more choice" camp, mainly out of principle. I think it provides proper flexibility, but really I could be way wrong. Either way, I will probably end up using Karborundum anyway at the end of the day.:rolleyes:

---

Also, I tried using the dds textures supplied: they didn't work out so hot, as you suggested. Next step is to see if I have better luck converting the tga textures myself. I know tga's can have loading issues - png's or something might be better if it's an option (but not my area of expertise).

Are the animations actually used for anything? Because the NRE's seem to indicate the animationName fields are incorrect, and thus the module is useless anyway. No surprise, but removing the animation module removes the NREs, but that might not be ideal.

Link to comment
Share on other sites

The animations just make the beacons light up when they're activated (as seen in the album in the first post). There's really no problem in disabling them temporarily. I really liked them because there was some visual reaction to activating a beacon so it's more apparent when it's on. I have the animation playing in the Unity editor now, even though it doesn't translate into the model file for some reason, so it shouldn't be too much more work to get it fixed. The real problem is that I've had to rebuild the .mu model file from scratch to fix the collider mesh and so I can't say exactly what changed because, well, everything has by virtue of recreating it.

I suspect the problem with the dds's comes from UV mapping coordinate system differences. I have a few ideas of things to try that may fix it. I just far prefer coding modules to dealing with models and artwork.

Edited by Booots
clarity
Link to comment
Share on other sites

Grab bag o' stuff:

  • Your current mu's are better than the old, since the old ones gave me "this model has too many polygons, needs to have less than 256" or something, and wouldn't launch. The current ones do not.
  • It seems the TGA's are absent from the download (maybe because someone complained about duplicates?:sticktongue:), but now we have DDS textures that do the below (which is, I believe the problem you first warned about). I'm poking at this.
    • Update: I converted the TGA's with the program DDS4KSP and the DDS texture problem seems to be fixed now. The picture on the left (Impetus Drive + Beacon) is with the DDS from the download, the one on the right (Drive + Beacons) is with my converted version. Oddly enough, the colors seem to have been switched. Personally, I don't care, but you might. I PM'd you the converted textures.
  • I was looking at the Karbonite/Karb+ Patch NEEDS and...I don't think those NEEDS will even work anymore, since I can't find any plugin by that name (unless it can trigger on subfolders?). In fact, I can't find any plugin in any of RoverDude's work, except USITools.dll, where I suspect it now resides (there is stuff in the K+ changelog about moving the dll back in Nov '14)...at least I know the Orion Pulse engine plugin now lives there, so others might as well.
  • Would you, not now but at some point, explain the ESLDBeacon module parameters (what all they do)? I'm a habitual config tweaker and I'd rather not end up inside a planet because of a decimal:D

Old vs New:

zHLIWvv.png?1TYCoVcB.png?1

Edited by Deimos Rast
Link to comment
Share on other sites

1 hour ago, Deimos Rast said:

Regarding patches: you could go the extra step and having them disabled by default (just change the extension from .cfg to .disabled). Also: is it even possible to produce XenonGas in stock? I know some mods add it in (my problem is I've strayed from the stock game for so long I forget what is what).

Also, I should add, I'm one voice here and so far the only one in the "more choice" camp, mainly out of principle. I think it provides proper flexibility, but really I could be way wrong. Either way, I will probably end up using Karborundum anyway at the end of the day.:rolleyes:

XenonGas cannot be produced in stock.  You can send tankers to your heart's content, but there is no harvestable form anywhere.  Since you downloaded the entire suite of RoverDude mods, you should note that you can find a little Xenon in asteroids (courtesy of Asteroid Mining Technologies, I think) and I believe that both the USI nuclear reactors and the Near Future reactors produce Xenon as a byproduct (as nuclear reactors do in real life).  The costs are a little different:  in the current iteration, XenonGas is valued at 4 Funds/unit, whereas Karborundum is valued at 400 Funds/unit.  There used to be a 'Karborundum Sample Tank' in the K+ tableau which gave 25 non-transferable Karborundum, but it cost 100,000 Funds in the VAB.  That was just the tank.  The Karborundum price was added to that.

Also, please don't misunderstand me:  I am not averse to more choice.  I am averse to more choice that leads to cost incompatibilities, especially if, as the rumours say, XenonGas is getting a balance pass in KSP 1.2.  The real risk with stock integration, or any integration, is that you lose control over the resource costs and so forth.  It's like the bimetallic standard for money:  when the market unbalances the price of silver versus gold, everyone trades the expensive one for lots of the cheap one and you end up with a de facto monometallic standard.  Add in the fact that Kethane's finiteness (you are correct on that) may well make a good cost comparison impossible because of the number of variables--well, I'm interested in simplicity.

Link to comment
Share on other sites

11 minutes ago, Zhetaan said:

XenonGas cannot be produced in stock.  You can send tankers to your heart's content, but there is no harvestable form anywhere.  Since you downloaded the entire suite of RoverDude mods, you should note that you can find a little Xenon in asteroids (courtesy of Asteroid Mining Technologies, I think) and I believe that both the USI nuclear reactors and the Near Future reactors produce Xenon as a byproduct (as nuclear reactors do in real life).  The costs are a little different:  in the current iteration, XenonGas is valued at 4 Funds/unit, whereas Karborundum is valued at 400 Funds/unit.  There used to be a 'Karborundum Sample Tank' in the K+ tableau which gave 25 non-transferable Karborundum, but it cost 100,000 Funds in the VAB.  That was just the tank.  The Karborundum price was added to that.

Also, please don't misunderstand me:  I am not averse to more choice.  I am averse to more choice that leads to cost incompatibilities, especially if, as the rumours say, XenonGas is getting a balance pass in KSP 1.2.  The real risk with stock integration, or any integration, is that you lose control over the resource costs and so forth.  It's like the bimetallic standard for money:  when the market unbalances the price of silver versus gold, everyone trades the expensive one for lots of the cheap one and you end up with a de facto monometallic standard.  Add in the fact that Kethane's finiteness (you are correct on that) may well make a good cost comparison impossible because of the number of variables--well, I'm interested in simplicity.

I forgot about ART (Asteroid Recycling Technologies, formerly AMT); I knew about the reactors producing some XenonGas. I suppose if you've already dedicated the resources to building a beacon hub, slapping on a reactor to it isn't that big of a deal. Which leads into the issue you were talking about: the potential for on site production of the resource required to fuel the beacons for decades (as it's a by product of an active nuclear reactor). Granted, it's produced at a low level, so a really active beacon would probably need to have XenonGas shipped out to it as well. Of course a patch could remove XenonGas as a by product, which could be an option.

The more we discuss this, the more I am inclined to agree that Karborundum is the best option.  I'm just content that we now have the option to choose though, which was my request all along.

(Also, major kudos for making an economic argument/analogy - first I've seen on the forums.:))

Link to comment
Share on other sites

@Booots  I was gonna post that the issue with the .dds files seems to be that they werent flipped vertically before they were converted to .dds, but I see @Deimos Rast already got that figured out... I just ran the LB10 thru Blender then Unity, and the activation lighting/animation does indeed work...At least in the VAB/SPH... I didnt try in flight... I'm not sure what triggers the animation in the .cfg, as you dont seem to have a method defined for it... ??

Edited by Stone Blue
Link to comment
Share on other sites

1 hour ago, Stone Blue said:

@Booots  I was gonna post that the issue with the .dds files seems to be that they werent flipped vertically before they were converted to .dds, but I see @Deimos Rast already got that figured out... I just ran the LB10 thru Blender then Unity, and the activation lighting/animation does indeed work...At least in the VAB/SPH... I didnt try in flight... I'm not sure what triggers the animation in the .cfg, as you dont seem to have a method defined for it... ??

Here are the textures (and just the textures) I sent to @Booots to save you from redoing everything. License is GPL2 same as original.

---

Also, @Booots -- I went to post an issue on the repo (since I think I've posted enough in this thread for one day), but the main ESLDBeacons repo doesn't seem to have Issue Tracking; however, the ESLDBeacons-Continued Repo does. I suspect it's because the former is a Fork, and the latter is an original Repo (no idea really, pretty new to GitHub myself).

Link to comment
Share on other sites

54 minutes ago, Deimos Rast said:

I forgot about ART (Asteroid Recycling Technologies, formerly AMT); I knew about the reactors producing some XenonGas. I suppose if you've already dedicated the resources to building a beacon hub, slapping on a reactor to it isn't that big of a deal. Which leads into the issue you were talking about: the potential for on site production of the resource required to fuel the beacons for decades (as it's a by product of an active nuclear reactor). Granted, it's produced at a low level, so a really active beacon would probably need to have XenonGas shipped out to it as well. Of course a patch could remove XenonGas as a by product, which could be an option.

AMT is actually a different mod:  it is all about finding random (sometimes rare) resources in asteroids.  ART is about turning hollowed-out asteroids into giant storage tanks.  Also, it gives a cool 'Mass Driver' engine that runs on Electric Charge and a Rock resource--I got it originally because I wanted to fly a rocket that ran on real rocks in it.  I think a lot of AMT was stockified along with Regolith--which may be why asteroids produce Ore, too--so if they don't also produce XenonGas, it probably isn't hard to trick them into doing so.

But that's beside the point.  I'm unconvinced that there is any stock option that can, in any configuration, provide the kind of challenge necessary to balance the mod.  The trouble with Xenon is that a reactor with sufficient Xenon storage plus time warp equals essentially free travel.  But time isn't a good balancer:  forcing you to wait is boring.  Also, to quote the original original post, 'Time is the ONLY thing you save with the beacons,' so any mechanic that makes you play a game of hurry-up-and-wait defeats the purpose.  Honestly, I never fully appreciated how totally overpowered click-and-you're-there beacons are until I looked into how much effort went into making this mod work.  @Booots can give a better answer here, I'm sure, but if I'm not mistaken, the actual 'move-ship-from-here-to-there' code is probably a fairly small part of the overall mod.  The bulk of it is the calculation of costs, line-of-sight, minimum altitude, drift, velocity mismatch, and everything else that goes into limiting how well the beacons work--or whether they work at all--in a given situation.

This all implies that to abandon Karborundum is likely to unbalance the mod.

Well, okay, we can do that, right?  Unbalance is not a dirty word; if you're doing the coding, you can do whatever you want.  But to what end?

All of that goes to say that if the mod allows other options for a fuel resource, then there are several ways it could go:

  1. Keep Karborundum:
    1. Either as a K+ dependency,
    2. As a CRP resource (with K+, if present, as an expansion),
    3. Or as a CRP resource without K+ integration (using stock parts and ignoring K+), but without any other link to the USI constellation.
  2. Unhook it from USI completely, but keep the current balance by using a new, different resource that is functionally equivalent to Karborundum (such as Exotic Matter, Antimatter, Scrith, Tachyons, Gleipnir, General Products Hull Material) in terms of cost and difficulty.
  3. Scrap balance somewhat and use a stock resource that has either been modified to be more difficult to obtain or else has been expanded into situations beyond its original scope.  XenonGas was discussed, but you could require SolidFuel and achieve similar difficulty (though importantly, not cost) because the only way in stock to haul SolidFuel around is to haul it in a solid rocket booster.
  4. Really scrap balance and use standard stock resources, or a new resource that is not functionally equivalent to Karborundum in terms of cost and difficulty.
  5. Use no resources.

5 already exists; it's called HyperEdit.

4 makes these the 'cheaty, easy jump beacons' that we're trying to avoid--even if only partly.

3 is interesting as a gameplay option; it's a sort of easy mode that works like unto the 'buy Karborundum in the VAB' configuration file but with stock resources.  Maybe it is best compared as the AntennaRange to the standard version's RemoteTech:  it's easier, but a little different and directed to a different target demographic.  I have no problem with this as an idea; there are likely plenty of people who would love to try this mod without the hassle of yet more resources.  However, given that the standard package does include the easy-mode configuration file, this may be redundant for all purposes except the 'no extra resources' crowd.

2 makes a lot of sense as a configuration for those who want the full ESLD experience in a completely stand-alone mod.  Honestly, if not for the fact that Karbonite provided an open mining and refining mechanic that he didn't have to write, I think TMarkos would have seriously considered this.  With stock ISRU, you have options he didn't have, and you can bring it to life.

1-3 is my way of saying that you keep the current CRP stats for Karborundum, but you do your own thing with it and ignore what RoverDude does with K+.  Those of us with the USI constellation will run into no difficulty unless the two of you have uses that conflict--i.e. you build an engine that uses Karborundum or RoverDude makes some kind of jump drive that costs a tenth what the beacons do.

1-2 is more or less already present; in the presence of FTT, the acquisition mechanic changes slightly.  FTT provides the fancy K+ torch drives, so getting back from the Sun or Eve after a Karborundum run is suddenly a lot easier.  In this case, the mod won't let you distil Karborundum from Karbonite; you must harvest it.

1-1 is also more or less already present, but it's also the obvious status quo.

I prefer a combination of options:  I'd like to see the mod expanded with options for both the easy-mode mechanic of 3 and the stand-alone mechanic of 2, but I won't use those, personally:  I very much like the K+ detection and dynamic self-modification that this mod currently has.

Link to comment
Share on other sites

@Deimos Rast actually, I just went ahead and used the .tga's instead of the .dds... I've just started modelling, and i had problems first starting using .dds in Blender & Unity, so i've just been doing everything with the .tga/.png's, THEN once everything is done, converting them to .dds... I happened to notice on the thumbnails in Explorer that the .dds were the same orientation as the .tga's... lol

Link to comment
Share on other sites

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.

Changes for today! Emissives and animations are fixed (for both the beacons and the techboxes). It took me a long time to get it figured out, but I also was able to remove the extraneous ModuleAnimateGeneric and just have the animation name given in the ESLDBeacon module. I'll go update the OP with the new download link.

Um, let me know if the techboxes flip 180 degrees on any craft you have. I may have changed an orientation node accidentally. Let me know if that's the case and I'll try to change it back.

I also fixed the DDS textures. Thanks to @Stone Blue and @Deimos Rast for pointing out I had to flip them. It was actually my UV-mapping that showed up correctly in the Unity editor but had to be flipped for in-game. They should be good to go now. The new download should have only DDS textures in it.

Edit: Oh! I also turned on issue tracking on github.

Edited by Booots
Link to comment
Share on other sites

@Booots

I launched my first set of beacons and went through and it worked wonderfully! A couple of NRE's popped up, however - the first is not gamebreaking (and can probably even be ignored), the second kind of is. See below.

First set is caused by launching the first beacon and is triggered on activation and shutdown respectively. I believe it's attempting to connect to another beacon but finds none so throws an error. Activating/shutting down a second beacon does not throw an error, only the very first.

After jumping through my beacon (I was told ahead of time I would be able to go back through), I was unable to do so, and clicking the beacon menu threw an error (see third error). The only way I found around this error is to use HyperEdit to teleport back to the same beacon I'm trying to access, which seems to "reset the scene" if you will, but also kind of defeats the purpose of the endeavor. At which point I could teleport back through just fine.

Cheers.
 

Spoiler



NullReferenceException: Object reference not set to an instance of an object
  at ESLDCore.ESLDBeacon.BeaconInitialize () [0x00000] in <filename unknown>:0 
  at BaseEvent.Invoke () [0x00000] in <filename unknown>:0 
  at RemoteTech.Modules.ModuleSPU.<HookPartMenus>m__0 (.BaseEvent e, Boolean ignoreDelay) [0x00000] in <filename unknown>:0 
  at RemoteTech.FlightComputer.UIPartActionMenuPatcher+Wrapper.Invoke () [0x00000] in <filename unknown>:0 
  at BaseEvent.Invoke () [0x00000] in <filename unknown>:0 
  at UIPartActionButton.OnClick () [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.InvokableCall.Invoke (System.Object[] args) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.InvokableCallList.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.UnityEventBase.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.UnityEvent.Invoke () [0x00000] in <filename unknown>:0 
  at UnityEngine.UI.Button.Press () [0x00000] in <filename unknown>:0 
  at UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <filename unknown>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute (IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00000] in <filename unknown>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute[IPointerClickHandler] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction`1 functor) [0x00000] in <filename unknown>:0 
UnityEngine.Debug:Internal_LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMousePress(MouseButtonEventData)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent(Int32)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent()
UnityEngine.EventSystems.StandaloneInputModule:Process()
UnityEngine.EventSystems.EventSystem:Update()



NullReferenceException: Object reference not set to an instance of an object
  at ESLDCore.ESLDBeacon.BeaconShutdown () [0x00000] in <filename unknown>:0 
  at BaseEvent.Invoke () [0x00000] in <filename unknown>:0 
  at RemoteTech.Modules.ModuleSPU.<HookPartMenus>m__0 (.BaseEvent e, Boolean ignoreDelay) [0x00000] in <filename unknown>:0 
  at RemoteTech.FlightComputer.UIPartActionMenuPatcher+Wrapper.Invoke () [0x00000] in <filename unknown>:0 
  at BaseEvent.Invoke () [0x00000] in <filename unknown>:0 
  at UIPartActionButton.OnClick () [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.InvokableCall.Invoke (System.Object[] args) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.InvokableCallList.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.UnityEventBase.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.UnityEvent.Invoke () [0x00000] in <filename unknown>:0 
  at UnityEngine.UI.Button.Press () [0x00000] in <filename unknown>:0 
  at UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <filename unknown>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute (IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00000] in <filename unknown>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute[IPointerClickHandler] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction`1 functor) [0x00000] in <filename unknown>:0 
UnityEngine.Debug:Internal_LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMousePress(MouseButtonEventData)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent(Int32)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent()
UnityEngine.EventSystems.StandaloneInputModule:Process()
UnityEngine.EventSystems.EventSystem:Update()


-----------------------

160607T154011.385 [ERROR] [UnityEngine.GUI.INTERNAL_CALL_DoWindow] GUI Error: You called GUI.Window inside a another window's function. Ensure to call it in a OnGUI code path.
160607T154136.160 [EXCEPTION] ArgumentException: An element with the same key already exists in the dictionary.
System.Collections.Generic.Dictionary`2[ESLDCore.ESLDBeacon,Vessel].Add (ESLDCore.ESLDBeacon key, .Vessel value)
ESLDCore.ESLDHailer.listFarBeacons ()
ESLDCore.ESLDHailer.drawGUI ()
ESLDCore.ESLDHailer.OnGUI ()


 

 

Link to comment
Share on other sites

Uh oh. This is why I should test the entire mod, not just the aspects I think I've changed since the last test. Thanks for finding edge cases (like the single beacon exceptions). I'll tackle these exceptions tomorrow. I already have suspicions as to what's causing them. Is the base functionality working though? Was your jump successful? You may also be able to 'reset the scene' by going to the tracking station and back as a temporary workaround.

Also, thoughts on the activation animation? It used to just go from unlit to lit, but now I made it go through funky colours and brightnesses for a more Kerbal feel (because warp beacons should be sketchy in this universe).

Link to comment
Share on other sites

Is the IB-1 drive functional at this point?

 

edit: Oh I see, the IB-1 contains an integreted source beacon, but you still need a destination beacon!

 

Edit 2: I'd love to see a version of the drive that can function as a source and destination beacon, balanced by being super massive and super fuel costly, such that you would use it to construct jumpship type ships.

Edit 3: 9.8k karborundum for a jump from kerbin->Jool - holy buckets.

 

Edit 4: I think leveraging karb as the end game resource for this is fine.

Edited by sentania
Link to comment
Share on other sites

17 hours ago, sentania said:

Is the IB-1 drive functional at this point?

Oh I see, the IB-1 contains an integreted source beacon, but you still need a destination beacon!

I'd love to see a version of the drive that can function as a source and destination beacon, balanced by being super massive and super fuel costly, such that you would use it to construct jumpship type ships.

Yes, I think it works. I never use it personally so it doesn't get too much testing. Let me know if there's any problems with it.

The problem with a jump drive that doesn't need a far beacon is defining where you want to jump to. The UI would need you to enter the orbital parameters manually which is a whole different set of functionality than what this mod has right now. Plus, my lack of experience with UI coding would make that hard to implement. Not that I'm opposed to the idea, if it were balanced right.

17 hours ago, sentania said:

9.8k karborundum for a jump from kerbin->Jool - holy buckets.

Hahaha, yeah... Different beacons have different use cases. The small one is good at low mass, short distance transfers; the middle one, medium mass transfers of any distance; and the big one is good at high mass, long-distance transfers. The IB-1 on the other hand, sucks at everything because it can jump itself. Try to find a more efficient beacon type and you can probably get that number under 1k easily. One of these days, I'll publish approximate mass/distance windows for each beacon.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...