toadicus

This mod is itself a proof of concept for the long form answer to your question. If you want to write your own, you're welcome to peruse my source code in search of the specific portions of the answer you're missing.

@Jenteb07, note my edits above.

@Whitecold I don't have selectors implemented yet, so at this point EDIT_EVA_MODULE[ModuleScienceExperiment] will just edit the first such Module. Sorry. @Jenyaza This patch, for example, will add ElectricCharge to the EVA Kerbals: EVA_RESOURCE { name = ElectricCharge amount = 0 maxAmount = 100 } It must be saved in a file ending in .cfg within the GameData folder in your KSP install.

I'm getting a segfault on startup in Archlinux; only log output is: Native stacktrace: /opt/games/KSP_testing/KSP_Data/Mono/x86_64/libmono.so(+0x915ee) [0x7fcc91f9a5ee] /opt/games/KSP_testing/KSP_Data/Mono/x86_64/libmono.so(+0x347fc) [0x7fcc91f3d7fc] /usr/lib/libpthread.so.0(+0x10d60) [0x7fcc97667d60] /usr/lib/libc.so.6(cfree+0x14) [0x7fcc95b8baa4] /usr/lib/libGL.so.1(+0x55e63) [0x7fcc97378e63] Debug info from gdb: ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Relevant packages are probably: nvidia-libgl 358.16-1 nvidia 358.16-2.1 Any ideas? TIA!

@Jenteb07, @Kerbas_ad_astra, remember that shorter-range antennas on a craft will almost always be ignored during rangefinding. The only exception is for the active vessel itself, if a shorter-range antenna has a cheaper connection than a longer-range antenna. For all inactive vessels, only the longest range antenna matters. It doesn't make any sense that the lander would be connecting through a probe at Kerbin. Please clarify if that's really the case, because that would be a bug. If it's actually connecting directly to Kerbin, then the situation we're in is comparing a DTS->88-88 connection versus the DTS->KSC3 connection (assuming you've got the tracking station fully upgraded or are in sandbox/science mode). DTS->88-88 max link range is 4.83e9m; DTS->KSC3 is 3.55e10m. In general this means you need to be (about) 10 times closer to the 88-88 to use it over Kerbin. So, using Kerbas' numbers above, if your satellites are in a very high orbit and Duna and Kerbin are very close together, this may be correct behavior. Unfortunately KSP is segfaulting on my dev machine at the moment; I'll try to simulate this myself when I can. EDIT: I had a few numbers wrong per the actual implementation, and also found and fixed a bug in determining the ranges of inactive relays when using additive ranges (in general, they were counting as much too long). That said, there's still a condition in which two relays that could phone home to Kerbin will not always line themselves up into the shortest network because of the "lazy" optimization the network resolution uses. When a relay looks for a new target every frame, it discards any relays that were targeting itself last frame, and checks relays against their transmit status from the last frame. So, suppose on frame 1 we have a DTS lander with no target and an 88-88 comsat with no target. The DTS lander checks first: the 88-88 has no connection (because it hasn't resolved yet), so the DTS checks Kerbin: it's in range, so it targets Kerbin. Then the 88-88 comsat checks: the DTS lander has a much better connection available than does Kerbin, so it targets the DTS lander. In frame 2, the DTS lander checks first again: targetting the 88-88 comsat would result in a circular connection, so it skips it and targets Kerbin again. The 88-88 comsat does the same check as before, with the same result. All else being equal, this network in this order will never result in the more-optimal lander->satellite->Kerbin resolution. I'm mulling over options for improving this. @Fl0oo, I do not have any custom configs to support any antenna parts added by Venstock Revamp. If you want to try writing one yourself, a great place to start would be the README.

Hyomoto, while we disagree about the quality of RoverDude's output (I've quite enjoyed his additions to stock and his mods, in general), I'm glad you like AntennaRange and agree with you about the way it "fits" with the game at this point. Considering the striking similarities between AntennaRange and what we know about Squad's upcoming system, it sounds like they may feel similarly. I'm excited to see what Squad does, and to see what scope there is for AntennaRange to add or improve functionality from there. gamerscircle, I think someone in this thread made patches for FASA long ago; try searching around and see what you can find. If you make a FASA patch yourself, I'd encourage you to add it here: https://github.com/toadicus/AntennaRange/wiki/Compatibility-Patches

LostOblivion, that's strictly a feature of TweakableDockingNodes at this point. Is there something else you want to have Control from Here in the action menu? Sure, I'll open up enable/disable in flight in the next update.

Thanks Aivoh; I'll pull the .cfg out of there. It shouldn't cause any trouble in the meantime.

To all appearances, RoverDude's relay system is going to substantially replace AntennaRange's basic functionality. I don't yet have any information than you do, so I can really only speculate from there. As soon as I get more information, I'll start exploring the best future for AntennaRange.

In general I think I disagree with your suggestion that "it's about the number of packets/sec". "Packets" are an arbitrary construct that the game uses to know how often it should do a thing, and are most analogous (I think) to the units of whatever data transmission protocol is being used (e.g. TCP/IP, etc.). The actual data throughput in MiT/sec is a better representation of the overall use of physical bandwidth over time, and it's that number that is positively related to signal strength and signal bandwidth. The packets/sec and amps/packet concept is more a reflection of the overall efficiency and behavior of the transmission protocol itself, and not the connection at all. So, I remain fairly sure that your Comm 32 and Omni Radar are functionally identical in all of the physically-significant ways that this mod cares about. That said, I do understand your basic concept. More throughput + less power = Less Range, and conversely. Currently we are technically overconstraining the system by defining all of the above simultaneously. I could procedurally determine antenna gains or nominalRange numbers using throughput and power assignments, but it remains something I'm wary of mostly for part maker's sakes. I'm not through thinking about it; I'll give this some serious thought and run it past a few people. Thanks very much for your input; feel free to keep it up!

RoverDude, thanks for pointing that out. That's a detail I'd missed in my original read-throughs. JJE64, what I'm really missing in your assessment here is how the Comm 16 transmits data twice as fast as the Omni. If they're both moving 6.6 MiT/sec, they have the same throughput. As far as I can see the only mechanical difference the Omni has is that it will use less power more often to achieve exactly the same result, except that in an "out of power" situation the Omni might wind up 1 MiT ahead of the Comm 16. It would be neat to programmatically determine the range of an antenna given the power use and the specified throughput, but to do that "right" I need to add a bunch of other inputs, like frequency and singal bandwidth (which is not what you're calling bandwidth), or else I just need to do it abstractly. In either case, I have intentionally chosen not to do things that way for now because in general I think it is less intuitive both for part designers and for part users if they can't just look and see what their antenna can do. I'm already borderline failing to adequately communicate the ranges to players, so that's a hurdle that needs to be overcome before something like this is tackled. One last thing: the "stock" antenna ranges (my configs) are not hard-coded, they're all configurable in my .cfg. If you want to change them in your patch, just use an :AFTER[AntennaRange] pass declaration and go right ahead.

ghmib2000, I was made aware in another thread that the problem was a lack of KerbalStuff update for my EVAManager dependency. I'll put in a bandaid fix for now so things will show up; a proper recompiled archive for EVAManager will follow Soon™.

Skalou, thanks very much! That's very fun, and very much appreciated. Also, kudos to Mr. Beamish for his fine modeling. linuxgurugamer, I wandered over to KerbalStuff and mashed the "works with 1.0.5" button. I'll try to get a proper recompiled archive up to KerbalStuff soon.

Is there some magic dance or fel incantation required to get the "prefix" drop-down to appear? I've tried a few different things with adding tags to my existing posts and I can't get it to show up for me at all (using Chrome in Windows, currently).

The "Location" profile item, as communicated on post nameplates, does not have any space between the word "Location" and the users' "location", thus:

Why did I post my forum bug report here? Because I got lost in my tabs, that's why. Move along. Move along.

I'd like to chime in and reiterate the request for a non-WYSIWYG editor, or at least an "edit source" button. Disabling the WYSIWYG in my forum preferences or something would be even better. Thanks for all your work, forum team!

This is impacting all of my release threads as well; would love to get vertical scrollbars back on code blocks.

Sounds like we're pretty unanimous on using Pilot crew to run RC probes. I hope to work on it this weekend. scribbleheli, there is no way to pick a different destination for your science than Kerbin. That would be a really cool feature, especially in situations like you're talking about, but currently the answer is "no". I could do that without... well, I could do that. It'd need quite a bit of work and I'd need to add a bunch of UI which is not my forte. It's on the wishlist; who knows, maybe that sort of improvement will be where we go after 1.1 puts in our basic functionality.

I think I could do that, [B]Waxing_Kibbous[/B]. I'll look into it when I go to implement things.

Thanks for the perspective [B]Kerbas[/B]! I don't get a lot of chance to actually play the game, and don't use any of those mods, so it's much appreciated.

Follow-up on the remote control point concept: I feel like it would be cool to require an engineer in order for a crewed ship to act as a remote control point. That would help give engineers a little more purpose, and might encourage diversifying crews a bit. Further thoughts invited!

[B]Skalou[/B], I coded the change today and now instead of just checking if a part has crew > min crew, I count the crew and exclude the tourists. That doesn't change unmanned behavior at all such as in the case you depict. I have not added remote control stations like your rover control ship because its computationally expensive in the general case. I can't just search back for a path back to Kerbin, I'd need to keep looking through the network until I found a control point, until the whole connected network was exhausted. On the other hand... I could pretty easily enable remote control points within a single link. Put differently, I could easily allow control if there is a crewed vessel with a direct connection to the probe in question. What do people think about that option? [B]Fubarbrickdust[/B], there's no realistic way to nerf the Comm 16 more without making it useless in T1, which is the primary time its currently useful. When you upgrade your listening device (tracking station) you necesarrily expand all of the link ranges back to it. Remember that the DSN could hear my kids' walkie talkie more "loudly" on the moon than it can hear Voyager right now. :-)

[B]Mr Betelgeuse[/B], I'm not aware of anything that would stop it from working in an existing save. All the modules should get added retroactively by ModuleManager. Can you get me a log after a run of the game that exhibits the problem? Thanks for the report, [B]Skalou[/B]! I don't think I ever updated the "do we have crew?" code to check to make sure the crew isn't 100% tourist. ;) I'll get it sorted!

[B]Mr Betelgeuse[/B], a follow-up question to [B]linuxgurugamer[/B]'s would be: "if so, do the antennas have long enough range?" The small Comm 16 antenna only reaches to 120 km when paired with an un-upgraded tracking station.