toadicus

Here's some fun (psuedo)-science. Let's suppose for the sake of argument that our hyperluminal relay operates by essentially re-creating the data in the new location. So, the energy cost is going to be somewhere on the order of E=mc², since we're spontaneously coverting our input energy into matter. We'll handwave the part where we're creating it a few lightyears away. Per this cool post I found on StackExchange about the actual mass of stored data on a hard drive, the material holding data on a hard drive in 2012 massed about 0.6 µg per gigabyte. It's a little unclear how Kerbal data unit ("T", as in "MiT", presumably mebi-T) relate to earth units, but for fun let's say the "T" is related to "ternary" in the same way that "B" is sort of related to "binary". This means that one Kerbal MiT (mebi-tryte?) can hold about the same amount of info as 3.25 GiB (gibi-byte). So, let's figure the mass of a mebitryte to be the mass of a gibibyte divided bytimes 3.25, or about 0.19 µg2 µg. This gives us a conversion energy on the order of 17 MJ180 MJ. A common interpretation for energy consumption in KSP is 1 EC/sec = 1 kW. Converting this back to energy units means that 1 EC = 1 kJ, so the energy cost to transmit one mebitryte of data through our hyperluminal data cannon is going to be 0.19 µg/MiT * c^2 * 1 EC / 1 kJ = 17088 EC/MiT2 µg/MiT * c² * 1 EC/kJ = 180200 EC. For even more fun: if you manipulate the relay into sending 71 MiT/sec6.7 MiT/sec, its consumption will be one point twenty-one (thirty-three) jiggawatts.

@GarrisonChisholm, as has been indicated by others here, yes, you'd be well out of the longest antenna's range at Valentine. I know some mods that add some moderately-longer range planets (like Outer Planets) package ModuleManager patches to increase the range of the AntennaRange antennas, but in your case I think a whole new part would be in order. I'm not a part author and can't really make it for you, but if you have a part that you think fits the role, as rasta013 said, writing an AR config for it is easy. I'd recommend making a "hyperluminal relay" part with a range of many lightyears, with a very large packet size (since you wouldn't want to operate such a device for very long) and a very large packet cost (since sending data via The Twisting Nether is surely very expensive). Something that you'd probably want one of the big nuclear reactors or several sets of giga panels to operate. Of course, if you're operating it primarily as a relay, it's on you to make sure you actually build the relay vessel that way, since I can't enforce charge use during flight. Depending on the nature of your interstellar mod, it might even be fun to make the hyperluminal part operate on a resource other than ElectricCharge, like CapacitorFlux or whatever the stuff of hyperspace is in your world.

@Z-Key Aerospace, I've identified an issue with correctly loading the cost and size of data packets for EVA Kerbals. Hard to send data when your maximum capacity is zero. I'll have a fix ready soon. Thanks for the straightforward repro steps! EDIT: Fix committed; I'll upload tonight or tomorrow!

@AdmiralTigerclaw, because of the specific class that's originating that exception, your interpretation of "trickle-down...from the vessel not appearing" fits just fine. That's not a problem with one of my modules being loaded and doing something funny, thereby hosing up the rest of the load cycle or something. That's one of my control behaviors (specifically, the one that takes control away from you if you don't have signal on a probe) checking to see if it needs to take control away from you, and being surprised to find no vessel where the vessel should be. Just in case, though, here's a quick dev build that should trap that error and stop it from happening: [zip] [tar.gz] [tar.xz] Hope that helps, if only to speed up narrowing things down.

@AdmiralTigerclaw, certainly it shouldn't be doing that, but since it never does that for me I need at least a bit more context if you want my help.

VOID 1.0 beta is available for testing! As hoped, I've got back to working on Scripted panels support, and the 1.0 feature list is complete. Now it's time for the brave among you to break things so I can fix them! This new feature adds the ability to define simple panels in CFG files, referring to data elements provided from VOID (or VOID extensions, if/when any exist to add data elements) and uses a simple scripting mini-language to provide dynamic data and user interaction analogous to what we currently have. The stock "Orbital Information", "Surface & Atmospheric Info", and "Vessel Information" panels are now scripted panels. In the future, I hope to add support for table-based panels, which would allows the duplication of the Celestial Body Browser and the Stage Information panels in the configurable format, and skinning/locking support, which would allow for the duplication of HUD panels. Download Links: [zip] [tar.gz] [tar.xz] VOIDScript Specification: https://goo.gl/iqGFvW Basic Usage: Script panels behave identically to normal panels, so turn them on and off as usual! Panels are read from VOID_PANEL{} nodes in .cfg files in GameData. Panel definitions can be reloaded through the "Scripted Panel Manager" panel, which will reload any existing panel definitions and load any new panel definitions in existing files. To get panel definitions from new files at this point, you have to restart the game. If you make a syntax or other mistake, the panel should otherwise work normally but will make an error report available on mouseover and in a "flyout" panel extension on the -> button that will appear near the usual panel close button. Hope you enjoy! Please report any problems here with supporting logs or screenshots, as appropriate.

@juvilado, I'm pretty sure you're confusing this mod with TweakScale.

@rasta013, this is an MM feature, so it would apply to anyone who uses the feature in this way. Most uses of the :NEEDS feature is a positive check; e.g. an antenna patch that uses :NEEDS[AntennaRange], so it only applies when AR is installed. I use something similar between EVAManager and TACLS; a patch with :NEEDS[TacLifeSupport] changes the ElectricCharge use of the EVA antenna so it fits better with the way TaranisElsu did ElectricCharge for EVAs. In general it's fine for patches to be pretty free with the positive check. If you get a false positive and add a module that isn't actually installed, KSP just skips the definition and moves on. If you get a false positive and unbalance some parts you might be sad, or you might not even notice. But, if you're using patches that intentionally rebalance parts in response to the presence of other mods, it's probably intentional and the risk and impact of a false positive is relatively minor. I'm using the check in a negative sense: :NEEDS[!RemoteTech]. The intention is to disable AntennaRange functionality when RemoteTech is installed, which I'm doing by preventing the addition of the modules on the parts I manage. But, the scope of the NEEDS check has expanded back then, and so have the number of parts intended for use with either AntennaRange OR RemoteTech. The lack of a standard among all of the patch and part authors, and the broad scope of the positive NEEDS check means that false positives are easy to have, and they wind up shutting the whole thing down, which is a pretty major consequence.

@rasta013, the short answer is "no, it wouldn't detect RT based on MM patches". I'd actually look through the list of loaded assemblies (which is the .NET word for libraries full o' code) that KSP has pulled in, and check if any of them call themselves "RemoteTech", and if so, shut the whole thing down. That is the original way that ModuleManager did :NEEDS (checking by folder and :FOR declarations was added to the :NEEDS feature later on), and it's how the potential future check that @DStaal mentioned would also work. In this case, AntennaRange (and presumably future-ModuleManager) would only be fooled if someone else compiled an assembly and intentionally named it RemoteTech, but actually did something else with it. That'd be a problem in need of some other form of management, though, and there are even ways to get a bit deeper than that.

@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.

@varsass, I think you may be mistaking TweakableEverything with TweakScale. They're two different mods, and I don't write TweakScale. You might be looking for their thread:

They should be in "Advanced Science Tech".

OK, I'll look in to that. Can you give me a part model (and the names of all its transforms) that I can use as a test case?

Oh, so you want it to use multiple transforms to make multiple struts? That'd be a bit more involved, but probably still doable.

@nli2work, I'm pretty sure that would be very straightforward. You're just talking about assigning the transform name for the actual QuantumStrut "emitter" itself, right?

@Zubster, I have no reason to believe it won't work, but my copies are always recompiled before I start up the latest versions of KSP so I can't tell if there are binary-level changes that might need to happen. Can you (or anyone else) confirm the current upload is still working in 1.1.2?

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.

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.

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?

VOID 0.19.1a is now available, repackaged with the latest VesselSimulator.

Thanks for letting me know @Padishar; I'll get that updated this afternoon.

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.

VOID has been updated to version 0.19.1! This update brings proper F2 support and has been recompiled for KSP 1.1.2. CHANGELOG: v.0.19.1 [2016-04-30] * Recompiled for KSP 1.1.2 * Optimized certain data values that required looping through the entire ship to share the same loop. * Added compatibility for the new onShow/onHide UI events to properly hide VOID when F2 is pressed.

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.

I've got a fix working, and took the opportunity to brighten up the module info stats while I was at it: Release will come sometime this weekend.