[1.3, 1.4, 1.5, 1.6, 1.7, 1.8+] Contract Pack: CommNet Relays 2.1.0 (2019 Jan 13)

[nightingale]

1 hour ago, Kerbas_ad_astra said:

Grumble, kids these days an' their see-cans...bah, humbug!  Back in my day, we had ta' download and install our mods in 1.44 MB chunks at 300 baud, uphill both ways, and we liked it!

I don't use it myself (I tinker too much with deleting parts I don't use, and I use a bunch of addons which predate it), so I'm not wild about "supporting" it.  On the other hand, the last time (the only time) someone else made a config for one of my mods, they goofed up the dependencies and recommendations.

In any case, there's not enough time on my plate to deal with it just yet.  Big push coming up in the real solar system.  I'm glad you enjoy it in its current CKAN-less state for the time being...

Since you are doing things the right way (using KSP-AVC and releasing via GitHub), you can practically just copy one of my .netkan files (like this one), and change the appropriate links and such (you'll need to send it as a pull request to the NetKAN repository, but they accept those pretty quickly). Once you have it set up that way CKAN will read the .version files from your GitHub releases automatically (ie. you will never have to worry about it again).  Oh and I'd also suggest updating the KSP-AVC file to have a max KSP version of 1.99.99 - giving you even less to worry about with CKAN (Contract Configurator will insulate you from 99% of the KSP version-centric issues).

Edited January 21, 2016 by nightingale

[Kerbas_ad_astra]

Since I'm pretty sure the upcoming antenna relay system will fall within the 1% that I'll have to take on the chin and adapt to, I will leave the max version where it is.  Thanks for the heads-up on Netkan.

Edited January 22, 2016 by Kerbas_ad_astra

[Buster Charlie]

Any chance of a spacedock/Ckan release?

[theonegalen]

Hi, I'm playing with CC, AntennaRange Relays, and a quite a few other mods, and CC is throwing some errors. Here's the log:

https://drive.google.com/open?id=0B6ZYgATQfNhBa2FGdWRmdHR6UVk

[Kerbas_ad_astra]

The problem is that the contract includes the Mk-V Comm-Lab (part name: MKV_CommPak) as an acceptable antenna for the relay, but your system doesn't have the part installed, so the exception is thrown.  From your log, it seems you have MKS Lite installed, which comes with the KolonyTools DLL which fools my contract patch into adding the Mk-V Comm-Lab when the part doesn't exist (MKS Lite comes with an identical-looking and identical-behaving part whose internal name is different).

Since both MKS and MKS Lite come with the KolonyTools DLL and live in the UmbraSpaceIndustries folder in GameData, Module Manager can't tell which one is included, so I'll remove the CommPak antenna from the list.  (Arguably, it wasn't really appropriate to include it in the first place, since it's not meant for satellites.)

[Kerbas_ad_astra]

Version 1.3 is out!

• Moved High Gain Antenna from its own patch, now that the Asteroid Day probe parts are folded into stock.
  • Because this will cause errors on pre-1.1 installs without Asteroid Day, this and later versions are no longer compatible with KSP 1.0.x.
• Removed the USI patch, since it was causing exceptions for MKS Lite users.
• Compatible through KSP 1.1.2.

[ioresult]

Hello,

this contract pack seems to be causing interference with Kopernicus.

Here's a link to the forum post I... posted a few minutes ago about that:

 

[nightingale]

2 hours ago, ioresult said:

Hello,

this contract pack seems to be causing interference with Kopernicus.

Here's a link to the forum post I... posted a few minutes ago about that:

 

Is it okay without Kopernicus?  You mention it causes interference, but didn't say anything about trying it without Kopernicus.

[Kerbas_ad_astra]

I'm not seeing anything in the logs that suggests anything is wrong, and I haven't noticed any stuttering on my own install (which includes Kopernicus, AntennaRange Relays, and lots more besides).  If this hasn't been sorted out by this weekend, I can try it out on my test install to see if there's any performance degradation.

The expressions for figuring out which planets to offer contracts for are gnarly-looking (they certainly took me some time to work out), and I could believe that they're computationally expensive, but they shouldn't be getting called very frequently, and they should be at their fastest at the beginning of a save, as they all require achieving orbit before they'll be offered.  Nightingale, would you recommend that I simplify them?  I could cut out a couple of checks for the contract if necessary (just count ships in the SOI of each body, as opposed to also checking if they're in orbit at the right altitude).

 

[ioresult]

4 hours ago, nightingale said:

Is it okay without Kopernicus?  You mention it causes interference, but didn't say anything about trying it without Kopernicus.

I made a few other tests, and Antenna Range Relays by itself seems ok. But it seems to get more and more computing intensive the more mods are installed.

The mods I list is the minimal install on my computer that start producing stuttering. And I agree, the logs don't say much.

I was assuming interference, but it may be just that the Antenna Relays pack runs a lot of checks as Kerbas_ad_astra says.

Maybe I should install that mod that examines system resources while running?

[nightingale]

@Kerbas_ad_astra - Oh yeah, took a peek and some of those expressions are pretty nasty.  When Contract Configurator is generating a contract, the minimum "step" it can do is to run a single expression in a frame.  So those expressions can make it perform pretty poorly (and I'm guessing the additional planet packs are making it that much worse in this case).

In general, you can break the expressions up into multiple expressions to allow it to work over several frames (look at Field Research for an example of that).  There's some specific things you can do in some of your expressions too.  Let's take a look at an example:

		targetBody1 = HomeWorld().Children().Where(b => (AllVessels().Where(v => (v.CelestialBody() == b) && (v.IsOrbiting()) && (v.Altitude() < @/maxApoapsis)).Count() < 5)   ).Random()

So far all moons of the homeworld, this expression will look at all vessels (which for Kerbin already means you need to look at each vessel twice).  So I'd be inclined to switch this around a bit:

DATA
{
    type = List<CelestialBody>
    validBodies = HomeWorld().Children()
    
}
DATA
{
    type = List<Vessel>
    bodyVessels = AllVessels().Where(v => @validBodies.Contains(v.CelestialBody()))
    orbitingVessels = @bodyVessels.Where(v => v.IsOrbiting())
    validVessels = @bodyVessels.Where(v => v.Altitude() < @/maxApoapsis)
}
DATA
{
    type = CelestialBody
    targetBody1 = @validBodies.Where(b => (@validVessels.Where(v => (v.CelestialBody() == b)).Count() < 5)).Random()
}

Something like that is more expensive overall, but would hopefully be less of a generation impact on the player.  If there's some new expression methods/functions that you'd like for performance improvements, just let me know.  Depending on how you end up doing it, something like CelestialBody.Vessels() (get all the vessels for a body) could improve what you're doing a fair bit, as reducing the number of things to look at in a Where() expression can also be a significant performance boost.  I also have the ability to make methods specific to the List<Vessel>, so I could do something that allows AllVessels().WhereOrbiting(@CelestialBody).  But I'm not entirely convinced that's a direction I want to go or not.

[Kerbas_ad_astra]

Dividing up the planet- and vessel-picking logic certainly helped me find a couple of goofs in my contract logic, so thanks for the suggestion!

@ioresult, I've made the changes per @nightingale's suggestion.  I'm going to hold off on release until I've tested them properly in a career save, but they load correctly, and you've seen a performance impact before they should be offered anyway.  You can grab the master copy from the repo (via the "Download ZIP" button) and see if the performance issue is resolved.

[ioresult]

11 hours ago, Kerbas_ad_astra said:

Dividing up the planet- and vessel-picking logic certainly helped me find a couple of goofs in my contract logic, so thanks for the suggestion!

@ioresult, I've made the changes per @nightingale's suggestion.  I'm going to hold off on release until I've tested them properly in a career save, but they load correctly, and you've seen a performance impact before they should be offered anyway.  You can grab the master copy from the repo (via the "Download ZIP" button) and see if the performance issue is resolved.

Wow @Kerbas_ad_astra, I've added your master copy to my full list of mods and there is no discernible change in performance. Thanks. I'm looking forward to putting up relay satellites around these outer planets now!

[Kerbas_ad_astra]

Version 1.3.1 "Expression Expansion" is here!

• Refactored targetbody expressions to reduce calculations-per-frame when contracts are generated.
• Compatible through KSP 1.1.3.

[Kerbas_ad_astra]

Version 1.4 "Mission Control" is here!

• Changes to support Contract Configurator's 1.15.3 update.
  • Because this depends on variables introduced in CC 1.15.3, this and later versions are no longer compatible with KSP 1.0.0-2.
• Contracts are broken out into individual cfg files (I got tired of scrolling all over the place when editing...)
• The license is changed to the GPL v3 (or later).

[Kerbas_ad_astra]

AntennaRange itself is largely superseded by the stock CommNet system coming in 1.2, but there doesn't seem to be a set of contracts specifically funding relay deployment, so this contract pack will continue once 1.2 is fully released and the final balance is set.  Orbit requirements may shift, and obviously the required antenna types will change to specify the new relays, and there will eventually be patches for mod antennas which identify themselves as relays.

[Kaa253]

On 17/09/2016 at 1:09 PM, Kerbas_ad_astra said:

AntennaRange itself is largely superseded by the stock CommNet system coming in 1.2, but there doesn't seem to be a set of contracts specifically funding relay deployment, so this contract pack will continue once 1.2 is fully released and the final balance is set.  Orbit requirements may shift, and obviously the required antenna types will change to specify the new relays, and there will eventually be patches for mod antennas which identify themselves as relays.

I would dearly love to see this and including the antennas from @akron's Coatl Aerospace Probes Plus would be awesome and a scalable distance factor or similar to accommodate mods such as OPM. I am not asking for much am I... .

[Kerbas_ad_astra]

Now that AntennaRange's capabilities are essentially stock, it will be much easier to add patches for mod parts.  (I mean, they were easy to add back then, but now, as mods update I can know for certain which antennas will be suitable for every player, as opposed to limiting patches to mods that shipped native AntennaRange patches as I did in the past.)

Also, OPM and RSS don't yet ship with antenna range patches, but when they do, I will include patches here to adapt these contracts.

[Kerbas_ad_astra]

Thinking further, it doesn't really matter what kinds of antennas are used -- the only thing that matters in the end is that there are enough relay antennas with the combined power to reach the homeworld from whatever body.  KSP already does the antenna-combining calculations itself, and helpfully reports the results in its API.  I'm working on implementing some methods for Contract Configurator to read those APIs, so I can dispense with the part-centered approach and become compatible with all antennas from every mod without any extra patches.

That's a pretty serious change, one that I don't feel comfortable calling "AntennaRange Relays 1.4" -- it would be version 2.0, since I don't think I can promise perfect save compatibility.  There's also the matter that calling these contracts "AntennaRangeAnything" doesn't really make sense in the absence of AntennaRange, but if I'm not trying to remain save-compatible, I might as well change the names of everything to be more sensible going forward.

AntennaRange Relays will give way to CommNet Relays.  This change is requiring extra time and testing before release, but it will be more robust going forward.

Edited November 6, 2016 by Kerbas_ad_astra

[Kerbas_ad_astra]

Contract Configurator 1.22 has some new antenna parameters from yours truly, so CommNet Relays 2.0 for KSP 1.2.x is coming Soon^TM after some final testing. Order of magnitude: week(s).

[Kerbas_ad_astra]

Testing and cost-balancing is complete!  I am proud to announce CommNet Relays v2.0.0!

• Renamed to "CommNet Relays". Because it uses the new CommNet system, it is not backwards-compatible with pre-1.2 versions of KSP or 1.x versions of AntennaRange Relays.
• Backend logic overhauled to use new CC antenna parameter. Specific parts are no longer required to complete contracts.
• Adjusted some of the contract parameters to reduce duplication and increase available choices.
• Max/min apoapses adjusted to CommNet balance.
  • Adjusted RSS patch.
  • Added OPM patch.
• Added new "Super DSN" contract to build enormous DSN relays. Why? Because we can!

Edited February 25, 2017 by Kerbas_ad_astra
Image insert didn't take the first time...

[Kuansenhama]

The "Place a relay satellite with lots of dishes in orbit around Kerbin" contract fails as soon as I load a vessel on the launchpad or in orbit.

[Kerbas_ad_astra]

I've never encountered that issue; there's nothing special about that contract vs the others (save that it requires a stationary orbit, and has an especially high requirement for the antenna power).  Can you get me a log with the failure?

[garwel]

Just discovered this mod. Too bad it's not listed on CKAN, more people (including myself) would know about it.

[Nathangun]

On 4/13/2017 at 8:27 PM, Kuansenhama said:

The "Place a relay satellite with lots of dishes in orbit around Kerbin" contract fails as soon as I load a vessel on the launchpad or in orbit.

I just came across this mod and the exact same thing happened, using Galileo's planet pack, contract configurator, and other contract packs.

One of the conditions of the new satellite is it has to have 9000000000000 of power.