[1.1.3] AntennaRange 1.11.4 - Enforce and Encourage Antenna Diversity

[jwenting]

Looks like Antennarange broke with KSP 1.1.2, worked fine in 1.1.1. Just a headsup. Thanks for a good mod. Like the need for antennas, but remotetech is too cumbersome for me.

[toadicus]

AntennaRange has been updated to version 1.11.1!  This update brings new and properly-updating antenna tooltips in the editor and R&D screens, and has been recompiled for KSP 1.1.2.

CHANGELOG:

v.1.11.1 [2016-04-30]
* Recompiled for KSP 1.1.2
* Overhauled the antenna info shown in the editor and research screen to communicate more facts about antenna functionality.
* Fixed an issue where antenna info for the editor would not update in response to tracking station ugprades or settings changes.

 

[crapstar]

@toadicus Thanks for the update. CKAN still says Max KSP version for this mod as 0.25.99...not sure if this a CKAN issue or if you might have missed it.

[toadicus]

That's not something I set on my end; that's a CKAN metadata issue.  Later today, hopefully, I'll take a look at my mods over there and file issues where necessary.

[lodestar]

On 4/29/2016 at 0:19 PM, toadicus said:

Here, since we don't have computers to execute programs for it, I figure we're basically roleplaying the robots executing commands when we're playing probes.

You'd be surprised with all the stuff I did to get "realistic" descent and landing on Duna with RemoteTech. I used SmartParts to trigger AGs at altitudes and have the whole sequence automated. Lots of fun.

[rasta013]

@toadicus Just noticed this in the editor screen after salivating over the new detailed info you've added in (awesome job by the way).

Isn't EC usage @ nominal supposed to be equal to the part cfg file as defined by packetResourceCost?  Every antenna whether stock or from a mod is showing the packet cost @ nominal as 1 EC.  Also, the packet size @ nominal for every antenna is showing as 10MiT which I thought also was supposed to behave as above.  Once mounted, the middle click info in the editor shows the cfg defined values normally so I thought this was a bit weird and figured I'd bring it up.

Thanks for all you do for this mod and again, great job on the new update!

UPDATE: Could this have anything to do with it?  This happened during startup.  I had a string of errors on every single antenna in the game.

Spoiler

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[ModuleLimitedDataTransmitter] Vessel and/or part reference are null, returning null vessel.
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[ARConfiguration] Found prefab IAntennaRelay Communotron 16
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[ARConfiguration] Recompiling part and module info for longAntenna

NullReferenceException: Object reference not set to an instance of an object
  at KSPUtil.PrintModuleName (System.String moduleName) [0x00000] in <filename unknown>:0
  at PartLoader.CompilePartInfo (.AvailablePart newPartInfo, .Part part) [0x00000] in <filename unknown>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0
  at AntennaRange.ARConfiguration.updateModuleInfos (System.Collections.Generic.List`1 partsList) [0x00000] in <filename unknown>:0
  at AntennaRange.ARConfiguration.updateModuleInfos () [0x00000] in <filename unknown>:0
  at AntennaRange.ARConfiguration.Update () [0x00000] in <filename unknown>:0 

That bit before the NRE appears in the output_log for every single antenna in the game. 

Edited May 1, 2016 by rasta013
Helps to insert the image...doh!

[toadicus]

Thanks for the report @rasta013; that is in fact a bug.  I originally thought it was just a display bug (because data set in Awake doesn't work right for prefab parts like those seen in the editor, but works fine for parts in flight), but it's actually also a gameplay bug because I reversed some arguments in a function call (so you've been transmitting with packet sizes and costs flipped since 1.11!).  I've fixed it internally and will get the new build up ASAP.

That NRE shouldn't be happening at all on the loading screen (and indeed, I don't see it), because ARConfiguration doesn't even exist until you get to the space center.  Was that happening during a reload from the F12 menu, maybe?

[rasta013]

1 hour ago, toadicus said:

Thanks for the report @rasta013; that is in fact a bug.  I originally thought it was just a display bug (because data set in Awake doesn't work right for prefab parts like those seen in the editor, but works fine for parts in flight), but it's actually also a gameplay bug because I reversed some arguments in a function call (so you've been transmitting with packet sizes and costs flipped since 1.11!).  I've fixed it internally and will get the new build up ASAP.

That NRE shouldn't be happening at all on the loading screen (and indeed, I don't see it), because ARConfiguration doesn't even exist until you get to the space center.  Was that happening during a reload from the F12 menu, maybe?

I'm sorry, I wasn't very clear with what I said.  I don't actually see the NRE during startup on the loading screen.  Exception Detector showed that error immediately upon entering the space center after loading my save game.  When I went in to take a look and see what was happening I noticed that string of parts re-compiling and it immediately preceded the NRE.  I'll get an output_log and KSP.log generated and posted so you can take a look.  Will update this post shortly with links to the logs...

[rasta013]

@toadicus Ok.  Here's links to the both log files.  The errors are definitely still there but the weirdest thing may be that all the antennas, stock and mod, all seem to be working other than the bug you already mentioned and are working on correcting. As always, let me know if there's anything else I can do to help. 

Link to output_log.txt

Link to KSP.LOG

[toadicus]

AntennaRange has been updated to version 1.11.2!  This update fixes the critical bug discussed above: antennas will now properly load with their packetSize and packetResourceCost fields used as intended.

CHANGELOG:

v.1.11.2 [2016-05-02]
* Fixed a critical bug in transmitter setup that caused the packetSize and packetResourceCost fields to be assigned backwards.

EDIT:

@rasta013, I think that error has to be interaction with another mod.  I can't duplicate the problem on my end, and the log suggests that a part -- surely an antenna, somehow -- has a malformed definition resulting in the part className, a module (any module on the part) moduleName or GUIName, or resource (any resource on the part) resourceName being null.  Looking through your mods it looks like you've got a lot of other mods that do things to antennas: AGExt, AmpYear, USI Kolonization, Bluedog_DB, and PhantomAerospace, at least.  If you want to look in to this further, the place to start is removing those mods to see if the problem goes away (if not, keep removing mods until it does).  Assuming removing all those removes the error, add them back one at a time until the error happens again, and let me know which it is.  I'll take a look to see if it's a problem I can work around easily, or if it's a bug with the other mod that should be fixed, or both.

Edited May 3, 2016 by toadicus

[rasta013]

FOUND IT!  Not a whole mod but a single solitary part...

MKV_CommPak.cfg in the UmbraSpaceIndustries/UKS/Parts folder was causing the entire problem.  The NRE and the weird recompile issues for all the antennas in every mod went away as soon as I disabled that part.  Here's the config:

Spoiler

PART
{
    name = MKV_CommPak
    module = Part
    author = RoverDude

    MODEL
    {
        model = UmbraSpaceIndustries/UKS/Assets/MKV_CommPak
    }    

    scale = 1
    rescaleFactor = 1

    node_stack_pod = 0.0, 0.0, 0.0, 0, 0, 1

    TechRequired = advConstruction
    entryCost = 5200

    cost = 7500
    category = Science
    subcategory = 0
    title = MK-V Comm-Lab
    manufacturer = USI - Kolonization Division
    description = A small lab with integrated communication capabilities, suitable for initial planetary exploration and ongoing research.  While the capabilities are inferior to the MPL, its compact size and lower mass make this an attractive option.
    attachRules = 1,0,0,0,0
    mass = 0.75
    dragModelType = default
    maximum_drag = 0.3
    minimum_drag = 0.2
    angularDrag = 1
    crashTolerance = 15
    maxTemp = 2000 
    bulkheadProfiles = srf, size1

    crashTolerance = 15
    breakingForce = 250
    breakingTorque = 250

    CrewCapacity = 1
    INTERNAL
    {
        name = landerCabinSmallInternal
    }    

    MODULE
    {
        name = ModuleScienceContainer
        reviewActionName = Review Data
        storeActionName = Store Experiments
        collectActionName = Take Data
        evaOnlyStorage = True
        storageRange = 2
        allowRepeatedSubjects = True
    }
    
    MODULE
    {
        name = ModuleAnimateGeneric
        animationName = Deploy
        isOneShot = false
        startEventGUIName = Extend Antenna
        endEventGUIName = Retract Antenna
        actionGUIName = Toggle Antenna
        allowAnimationWhileShielded = False
    }    
    
    MODULE
    {
        name = ModuleScienceLab
        containerModuleIndex = 0
        dataStorage = 150
        crewsRequired = 1
        canResetConnectedModules = True
        canResetNearbyModules = True
        interactionRange = 5
        SurfaceBonus = 0.1
        ContextBonus = 0.25
        homeworldMultiplier = 0.1
        RESOURCE_PROCESS
        {
            name = ElectricCharge
            amount = 10
        }
    }

    MODULE
    {
        name = ModuleScienceConverter
        scientistBonus = 0.25    //Bonus per scientist star - need at least one! So 0.25x - 2.5x 
        researchTime = 7        //Larger = slower.  Exponential!
        scienceMultiplier = 5    //How much science does data turn into?
        scienceCap = 250        //How much science can we store before having to transmit?        
        powerRequirement = 1    //EC/Sec to research
        ConverterName = Research
        StartActionName = Start Research
        StopActionName = Stop Research
    }    

    MODULE
    {
        name = ModuleKISItem
        shortcutKeyAction = drop
        useName = use
        usableFromEva = true
        usableFromContainer = true
        usableFromPod = true
        usableFromEditor = true
        stackable = false
        volumeOverride = 1000
        editorItemsCategory = false
        moveSndPath = KIS/Sounds/itemMove
        equipable = false
        equipMode = part
        equipSlot = Back Pocket
        equipSkill = 
        equipRemoveHelmet = false
        equipMeshName = helmet
        equipBoneName = helmet01
        equipPos = (0, 0, 0)
        equipDir = (0, 0, 0)
        carriable = true
        allowAttachOnStatic = false
    }

    MODULE
    {
        name = ModuleDataTransmitter
        packetInterval = 0.35
        packetSize = 2
        packetResourceCost = 12.0
        requiredResource = ElectricCharge
        DeployFxModules = 1
    }    

    RESOURCE
    {
        name = ElectricCharge
        amount = 500
        maxAmount = 500
        isTweakable = True
    }
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        passableWhenSurfaceAttached = true
    }
}
 

I honestly don't see what could be causing this issue.  I'll also cross-post this in the MKS thread for RoverDude since this piece of the MK5 package is definitely on the important side being the initial ground lab to use for early colony prep or temporary mobile research outpost. @toadicus Do you see anything in that cfg which could make AR go berserk?

[toadicus]

Nothing immediately jumps out @rasta013, but it's possible that something's changed with the way Squad handled non-present modules or something like that.  A few of those modules look like they probably depend on other mods; if you don't have ConnectedLivingSpace or KIS installed, you could try excising those MODULE {} blocks and see if that changes anything.

[rasta013]

7 minutes ago, toadicus said:

Nothing immediately jumps out @rasta013, but it's possible that something's changed with the way Squad handled non-present modules or something like that.  A few of those modules look like they probably depend on other mods; if you don't have ConnectedLivingSpace or KIS installed, you could try excising those MODULE {} blocks and see if that changes anything.

Yeah me either.  I had CLS/KIS installed when this problem started and have since put KIS back on because it updated but CLS hasn't yet.  Will give it a try with the new version whenever it comes out.  I've also got this reported to RoverDude so I'm patiently waiting to see what insights he might have.

[DuoDex]

Ah yes, I have this problem too, and also have AmpYear installed. I will try and remove AmpYear and see if that fixes it. Unsure if it's an MM patch causing trouble or an actual hard conflict.

@toadicus - can you give a big fat list of every mod that might conflict with AR? I'd like to try and test and get this one out of the way. I assume it's something like this bug, where the module doesn't even show up.

Spoiler

Seems that the PhantomAerospace antennas work just fine though, I'll try removing them.

[DuoDex]

UPDATE: Seems that PhantomAerospace Antennas break AntennaRange for stock antennas. I'll ping @DTPhantom and alert @BigFatStupidHead to this. Unsure about @rasta013's patches as I haven't played with them.

[BigFatStupidHead]

10 minutes ago, DuoDex said:

UPDATE: Seems that PhantomAerospace Antennas break AntennaRange for stock antennas. I'll ping @DTPhantom and alert @BigFatStupidHead to this. Unsure about @rasta013's patches as I haven't played with them.

Hey! I'll take a look to see if my MM config is still up to snuff, but that has to wait till tomorrow. 

[nismobg]

Same goes for the Origami antennas, break AR .

[rasta013]

5 hours ago, DuoDex said:

UPDATE: Seems that PhantomAerospace Antennas break AntennaRange for stock antennas. I'll ping @DTPhantom and alert @BigFatStupidHead to this. Unsure about @rasta013's patches as I haven't played with them.

@DuoDex For my patch for the Phantom Aerospace antennas, I created a secondary patch that adjusts the stock antennas and the stats that @toadicus originally set for them in order to get them inline for use together under stock or OPM so that may have had an effect.  I can say that with my stock patch and the PA patch I have all of them working correctly with a 160+ mod install that has the full USI suite and AmpYear installed.  This is also including two other patches I'm running for AIES and Bluedog DB antennas as well and all are working smoothly. (I do need to adjust some of the part names for BDB after the update yesterday though).  As a side note, I've got the latest community edition version of Ven's running as well and haven't patched those antennas, but I have not seen any issues with either the stock or mod antennas either. Seems a bit weird that just installing the PA antennas would seem to break the AR stock patch though...

If you do try out my patches I'd love to hear some feedback on the balance of the antennas as I'm working off my own knowledge and a bit of balancing guess work for all of the patches.

[DStaal]

The problem is that the PhantomAerospace standard config uses ':FOR[RemoteTech]'.  That creates the RemoteTech mod in MM's mind, meaning the AntennaRange's ':NEEDS[!RemoteTech]' triggers, disabling that patch.  The Origami Antennas have the same issue: A misuse of ':FOR' where they mean ':NEEDS'.

I'm a bit conflicted in the fix.  On one hand, the actual misuse occurs in PhantomAerospace and Origami Antennas.  On the other, I'm not sure why AntennaRange's config makes sure it disables itself if RemoteTech is also installed - I would expect there to be other issues if you tried installing both, so trying to make it compatible there seems to be causing more headaches than needed.  (And it's a bit random - If things break because someone's got both RemoteTech and AntennaRange installed, you tell them not to do that.  If they break because someone misconfigured their third-party mod, it becomes hard to track down.)

Edited May 9, 2016 by DStaal
minor clarification.

[rasta013]

1 hour ago, DStaal said:

The problem is that the PhantomAerospace standard config uses ':FOR[RemoteTech]'.  That creates the RemoteTech mod in MM's mind, meaning the AntennaRange's ':NEEDS[!RemoteTech]' triggers, disabling that patch.  The Origami Antennas have the same issue: A misuse of ':FOR' where they mean ':NEEDS'.

I'm a bit conflicted in the fix.  On one hand, the actual misuse occurs in PhantomAerospace and Origami Antennas.  On the other, I'm not sure why AntennaRange's config makes sure it disables itself if RemoteTech is also installed - I would expect there to be other issues if you tried installing both, so trying to make it compatible there seems to be causing more headaches than needed.  (And it's a bit random - If things break because someone's got both RemoteTech and AntennaRange installed, you tell them not to do that.  If they break because someone misconfigured their third-party mod, it becomes hard to track down.)

OH YEAH!   I remember running into that when I first started writing my PA patches.  It does cause an issue that will blow up pretty much everything because of exactly what you said - the FOR gets in the way.  I remember now that I had to kill the RT patch completely in order to overcome that issue.  It should be written as a NEEDS instead of a FOR statement in the RT patch as well.  Similar to what I do in ever AR patch I write.  

Spoiler

For example, the two statements I use in my PA patch for the helix antenna

@PART[helixAntenna]:NEEDS[AntennaRange&PhantomAerospace&!RemoteTech,!OPM] (for no RT or OPM) 

@PART[helixAntenna]:NEEDS[AntennaRange&OPM&!RemoteTech] (for no RT but having OPM)

These can be combined together with no issue in the same patch with the new capabilities that were included in the recent MM updates.  Still, if you keep any RT patch that has a FOR statement in it, expect it to bork up everything as it always seems to.  I had forgotten this bit so thanks for the reminder...

EDIT: LOL...I just realized that tiredness apparently is going to lead to deja vu as I just repeated pretty much exactly what you said... 

Edited May 9, 2016 by rasta013
Err....

[BigFatStupidHead]

I see. So, despite no RemoteTech being installed, ModuleManager sees a reference to RemoteTech and therefore disables the AntennaRange default antennas. This might also be considered a bug in ModuleManager.

 

@sarbian Is this an issue with MM at all?

Edited May 9, 2016 by BigFatStupidHead

[DStaal]

No, because it's one of the documented ways to create a mod in ModuleManager.  Basically, these mods are telling MM that RemoteTech is installed.  They are installing it, right there - it's not just a reference, by ModuleManager syntax that is RemoteTech.  Those patches get treated differently than ':NEEDS' patches - they get run first, among other things.  I'd argue that 'for' is the wrong word to use there as the keyword, but it's intentional, documented, and expected behavior.  The bug is having patches that create RemoteTech when they don't mean to.

[BigFatStupidHead]

Ok,  so it is intentional behaviour; just unusual word choice. Gotcha.

[toadicus]

@DuoDex, @nismobg, @rasta013, @BigFatStupidHead, have you more or less sorted out what's going on?  Have you spoken at all to the authors of the other mods that are incorrectly adding RemoteTech to the MM mod list to see if they want to change things?

Since this is a recurring problem, I'm considering doing a more positive check for RemoteTech within the plugin, instead of relying on MM's data, and removing the MM patch NEEDS[!RemoteTech] criterion.  But, that'll require a bit of development so it won't be an instantaneous change.

[rasta013]

1 minute ago, toadicus said:

@DuoDex, @nismobg, @rasta013, @BigFatStupidHead, have you more or less sorted out what's going on?  Have you spoken at all to the authors of the other mods that are incorrectly adding RemoteTech to the MM mod list to see if they want to change things?

Since this is a recurring problem, I'm considering doing a more positive check for RemoteTech within the plugin, instead of relying on MM's data, and removing the MM patch NEEDS[!RemoteTech] criterion.  But, that'll require a bit of development so it won't be an instantaneous change.

Generally speaking, everyone I've mentioned it too, authors and patch writers, have all been receptive to making the change to the NEEDS instead of the FOR.  Most of the time it simply falls back to the person writing the RT patch not realizing that FOR actually instantiates RT through MM.  That said, I think no matter how often it is brought up it will continue to rear its head since anyone new to writing MM patches tends to run into this right out of the gate.  

The question I'd have though, if you do a more positive check within the plug-in would you be able to differentiate between a MM instantiated RT and an actual install?  Not being a coder I don't know exactly what can be done within the guts of a plug-in...