toadicus

Good idea. Really, I should probably get most of VOID's settings per-save. What do you think?

Curses, you've detected my sekrit copy/paste plans! Fixed it.

Hey folks! Long time no see. I'm trying to get back into the saddle here, but for now I do know that I have some updated code and a big ToadicusTools refactor to get out, and it's (well past) time to do something about that. So! Here's a development build with some minor fixes and big under-the-hood changes for ToadicusTools. I consider this build to be a "beta" release. [zip] [tar.gz] [tar.xz] I have gone to great lengths to make the refactor of ToadicusTools binary-compatible with the old version, and in general that appears to be the case in all but two spots in VOID. Nevertheless, if you use my other mods and want to use this development build, I strongly recommend you download the dev builds I'm uploading for the others, as well. CHANGELOG (from 1.12) * TweakableFuelPumps should no longer name its pumps "True Pump", and should instead use the action resource name. * Generally refactored calls to ToadicusTools methods to support the new refactor. tjm2000, I don't know anything about that mod. Can you be a little more specific as to the sort of tweaks you'd like to see me add for it? Are these just reapplications of existing tweaks, or new ones?

Hey folks! Long time no see. I'm trying to get back into the saddle here, but for now I do know that I have some updated code and a big ToadicusTools refactor to get out, and it's (well past) time to do something about that. So! Here's a development build with some minor fixes and big under-the-hood changes for ToadicusTools. I consider this build to be a "beta" release. [zip] [tar.gz] [tar.xz] I have gone to great lengths to make the refactor of ToadicusTools binary-compatible with the old version, and in general that appears to be the case in all but two spots in VOID. Nevertheless, if you use my other mods and want to use this development build, I strongly recommend you download the dev builds I'm uploading for the others, as well. CHANGELOG (from 0.18.3) * DataLogger: Now uses numeric latitude and longitude for easier parsing. * Generally refactored calls to ToadicusTools methods to support the new refactor. * Bugfix: Modules will now more-consistently retain their settings around Flight reversions, particularly to the Editor. * Workaround: Implemented our own horizontal surface speed to avoid Squad's broken one.

Hey folks! Long time no see. I'm not entirely sure what I'm doing with this mod right now, but I do know that I have some updated code and a big ToadicusTools refactor to get out, and it's (well past) time to do something about that. So! Here's a development build with some minor fixes and big under-the-hood changes for ToadicusTools. I consider this build to be a "beta" release. [zip] [tar.gz] [tar.xz] I have gone to great lengths to make the refactor of ToadicusTools binary-compatible with the old version, and in general that appears to be the case in all but two spots in VOID. Nevertheless, if you use my other mods and want to use this development build, I strongly recommend you download the dev builds I'm uploading for the others, as well. CHANGELOG (from 1.10.1) * Now includes patch for the High Gain Antenna from the AsteroidDay "mod". * Generally refactored calls to ToadicusTools methods to support the new refactor. * Bugfix: FlightController no longer tries to use relays on an active vessel that has none. * Bugfix: Custom part tooltip now manually fetches GUI styles to avoid relying on the editor. * Bugfix: When used with EVAManager (default), EVA Kerbals now spawn with 0 ElectricCharge to avoid infinite ElectricCharge exploits. * Bugfix: Outdated patch references to RemoteTech2 changed to RemoteTech.

Glad you like it, eLDude! I've had a quick look over Crzyrndm's module, and my reaction wheel throttle won't work quite right with his module, because we both clobber the same parts of ModuleReactionWheel. The best way to get throttling functionality in his mod would be to ask him for it. It'd be a pretty easy addition; he just needs a tweakable field for it and then needs to multiply that into his assignments in updateTorque.

As Kerbas_ad_astra said, AntennaRange and RemoteTech are specifically incompatible. A few players have had luck converting RT saves to AR saves by using special patches to convert RT parts to AR parts and removing the RT patches and DLLs, but I don't have any experience with that myself. This mod used to turn itself off when it noticed RemoteTech... but I keep forgetting to change RemoteTech's name. So! I finally remembered to change the name. Next update will properly disable itself when RemoteTech is around.

"Moving" on the antenna parts means that they are trying to animate to open or close. This mod should not be causing them to do that at all; if they're doing that during a transmission something else is probably going on. Can you duplicate the problem without any other mods (feel free to use something like HyperEdit; you don't have to fly a whole mission to reproduce circumstances)? Edit: None of the antennas need to be turned or aimed in any way for this mod.

Sorry for my absence! I'm trying to get back into the swing of things here as my kids get back to school. New versions of everything -- with basically no changes in front of the scenes at all -- should be coming soon. So I sat down to test based on your report, and after a few tries of being completely baffled why my debug code was saying the poodle didn't have a part underneath it anymore, I actually looked at what was happening in the game screen instead of in my log and... there's no part under the poodle anymore. Following your instructions exactly, assuming that "launched" implies you staged once to activate the mainsail and then staged again to decouple the launch clamps, the next time you press stage is when you drop the decoupler under the poodle. Is that somehow not when the fairing is supposed to go away?

That's actually a patch error in AntennaRange. I've fixed it but haven't released the fix yet, because apparently summer is hard. I'm going to get back into the swing of things soon, honest. In the meantime, the fix is really simple if you want to do it yourself; there's a "100" that needs to be a "0", as indicated in this commit log: https://github.com/toadicus/AntennaRange/commit/a888901c

That's probably actually correct functionality, Fizbanger. By default, VOID uses vacuum Isp in the editor (you can change that in the flyout at the bottom of the Stage Information window). In flight mode, it uses the current atmosphere to determine Isp. Especially for ships with a lot of dV coming from an engine with a very different sea level Isp (like the LV-909), you can see a big difference between those numbers.

This mod already is "CKAN compatible" and listed in CKAN's directory. You may be thinking of the part mod that uses it, where I note you've also posted.

So it's been long enough that I don't remember exactly which release of what contained that, but only TweakableEverything (and particularly TweakableStaging) should be using that method, and it should (at least) be in the version of TT that came with the latest version of TE. When I get home this evening I'll push up a newer version of TT, or maybe I'll finally release the big refactor I've been working towards.

DennoD, all antennas in AntennaRange are omni-directional, and there's no requirement for multiple antennas to support multiple connections. I.E. a single vessel with one antenna can act as a relay for infinite other vessels.

marrioman13, I have no idea if RSS scales antenna ranges or not. I'm pretty sure they at least provide configs to embiggen the range numbers, but I'm not even 100% sure of that. When you say you want something to have "a range of 40 Mm", you need to be a bit more specific. Are you talking about a legacy "simple" range? If so, that's easy: set simpleRange to 40000000 / sqrt(maxPowerFactor). Are you talking about a current symmetric range? If so, be more specific: 40Mm relative to what receiver? What is the gameplay effect you're trying to create? The symmetric range system is more complicated from a design perspective and really requires you to think about the way you want players to use the antenna, and why they would pick that antenna over another antenna in that circumstance. You can't just say "40 Mm seems like a nice number" and go from there. 3MMM, AntennaRange does not provide any facility to move data between vessels. Depending what 1.1 brings, creature comforts like that may come in the future. ModZero, I'm doing as much communication with RoverDude as I can (which is tough, because I lack the NDA status to be truly useful), and as soon as I get a 1.1 build I'll start providing as much Real Feedback and collaboration as I can. When I know what AntennaRange will look like after 1.1, I'll certainly tell you all.

tg626, that's not a known thing. It also doesn't happen to me, so I'll need logs, at least, in order to help you.

duodex, I'm tossing around an idea for a deep gameplay mod that would introduce AI "opponents" including time-based income and competition for technology grabs (first to a tech gets better contracts sooner, but later arrivals get the tech for cheaper just like in real life) and contracts (the AI opponents could literally snatch contracts you might want, and contract recipes would devalue over time so e.g. "put a sat in an equatorial orbit around Kerbin" will not always be profitable). Still in the design/exploration phase. makkz, my OPM patch should have results like this: [TABLE][TR][TD][TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]1.80E+04[/TD][TD]6.30E+09[/TD][TD]9.00E+10[/TD][/TR][TR][TD]Comm. 16[/TD][TD]1.80E+04[/TD][TD]1.80E+04[/TD][TD]1.06E+07[/TD][TD]4.02E+07[/TD][/TR][TR][TD]Comms DTS[/TD][TD]6.30E+09[/TD][TD]1.06E+07[/TD][TD]6.30E+09[/TD][TD]2.38E+10[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]9.00E+10[/TD][TD]4.02E+07[/TD][TD]2.38E+10[/TD][TD]9.00E+10[/TD][/TR][TR][TD]KSC1[/TD][TD]8.00E+05[/TD][TD]1.20E+05[/TD][TD]7.10E+07[/TD][TD]2.68E+08[/TD][/TR][TR][TD]KSC2[/TD][TD]2.00E+11[/TD][TD]6.00E+07[/TD][TD]3.55E+10[/TD][TD]1.34E+11[/TD][/TR][TR][TD]KSC3[/TD][TD]6.00E+12[/TD][TD]3.29E+08[/TD][TD]1.94E+11[/TD][TD]7.35E+11[/TD][/TR][/TABLE][/TD][TD][TABLE][TR][TD]|[/TD][TD][/TD][TD][/TD][TD][/TD][TD][/TD][/TR][TR][TD]|[/TD][TD]To↓ From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]|[/TD][TD]Comm. 16[/TD][TD]<Kerbin Orbit[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Kerbin->Mun[/TD][/TR][TR][TD]|[/TD][TD]Comms DTS[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Jool's Moons[/TD][TD]Kerbin->Duna @ Transfer[/TD][/TR][TR][TD]|[/TD][TD]Comm. 88-88[/TD][TD]Kerbin->Mun[/TD][TD]Kerbin->Duna @ Transfer[/TD][TD]Kerbin->Jool[/TD][/TR][TR][TD]|[/TD][TD]KSC1[/TD][TD]Low Kerbin Orbit[/TD][TD]Kerbin->Minmus[/TD][TD]Jool's Moons[/TD][/TR][TR][TD]|[/TD][TD]KSC2[/TD][TD]Kerbin->Minmus[/TD][TD]Kerbin->Duna[/TD][TD]Kerbin->Eeloo[/TD][/TR][TR][TD]|[/TD][TD]KSC3[/TD][TD]Jool's Moons[/TD][TD]Kerbin->Eeloo[/TD][TD]Kerbin->Plock[/TD][/TR][/TABLE][/TD][/TR][/TABLE] Note that I'm referring to stock Eeloo in every case. The Comms DTS comes very early in the progression, so the general concept is that a player will need at least KSC3 or Comm 88-88 before exploring the outer planets is particularly feasible. autumnalequinox and Kerbas_ad_astra, thanks for your support now and over the last long while. I'm guessing there will be a few holes for AntennaRange to patch, especially if RoverDude doesn't do symmetric ranges. It'll probably still exist, but it'll definitely feel a lot more optional. I should know more about that once I get a 1.1 build.

Thanks Kolago, I'll try to look in to that soon. Realistically it won't be sooner than two weeks, on account of some summer vacations. TheCardinal, struts can't be lengthened while active, but if you deactivate the strut, change your geometry, and reactivate it, the strut will then be longer or shorter as necessary. If you're talking about maximum length, I confess I'm not familiar with that part of the code base. That said, I do know there's no user-side tweak for it.

AccidentalDisassembly, thanks for the report. Better integration with TweakScale is on my "to do" list. I'm hoping to get to it in the next month or so. Svm420, EVAManager does all of its changes to EVAs in the Main Menu scene. If you skip that it won't work at all. There are a lot of mods that depend on doing specific actions at the main menu or spacecenter; skipping those scenes -- while expedient and I completely understand the desire to do so -- is rarely safe in modded installs.

It's been a while since I looked, but as I recall it's because all SAS is best SAS in non-career modes. You're welcome! I'm glad you're enjoying it. If you've corrected installed the mod and all its dependencies, and don't have any faulty mod interactions present, there will be tweakable sliders in the action (right-click) menu for all EVA Kerbals. If you're confident everything's installed right, I'll need a log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log) if I'm going to be any help to you.

Honestly, I do feel pretty cool about it. When they say "...using inspiration from some of the plugins..." and then go on to describe all the bits of the other plugin that they're not using (and neither do we), I feel like it's obvious enough what they mean. Since they're not using me to do the work it's pretty natural that they wouldn't say "Hey, we're making AntennaRange stock", and frankly if they'd asked me to do it I'd almost certainly have had to turn them down anyway: my career is not one from which I can easily take a spontaneous two month break, even if the money is good, and my spare time is almost certainly insufficient for their needs. I would have been really chuffed to have been asked or explicitly acknowledged. But I'm a grown-up and I get there's all kinds of reasons they might not want to do that, not the least of which being that I'm probably not actually that great a coder. I'm really happy to see this essential functionality become a part of the game with or without my direct involvement. As soon as I get my hands on a copy, I'll give them all the feedback I can. Thanks so much to all of you for your support, today and over the last two years! You guys have really been a great community. I have no idea what the future will hold for AntennaRange. There may be gaps to patch in Squad's new system. There may be "wishlist" items to add. There may be nothing more reasonable for me to do than to gracefully step away. I'll be looking for that answer, and will be listening to your feedback when 1.1 comes out.

While on the one hand I would have liked to be included in Squad's current effort, on the other hand I'm just glad it's happening. As has been mentioned, most of the functionality in AntennaRange (and apparently in the new Stock behavior) is emergent from basic physics, so I can't claim that they're abusing me in any way -- and wouldn't anyway; technically the way my license is written they could be 100% copy/pasting my code and as long as there's attribution given in the distribution they'd be complying. I kept things open for a reason and this was part of it.

Symmetric ranges are "new" in version 1.10. It's a realism change. Here's some info: http://forum.kerbalspaceprogram.com/threads/56440?p=2015869#post2015869 The system adds more variability than previously: there are two axes of change now instead of just one. It does have the impact of making the Comm 16 useful in a new situation, but it also does the inverse, in that there are now some situations wherein the Comm 16 would have been perfectly useful before and now is not. As with most features in AntennaRange: if you don't like it, you can turn it off.

Sorry I've been remiss in updating; 'tis the season for my day job to be busy, and also for me to have out-of-town guests staying in my house, and also for me to be taking vacations of my own. I've have minor updates ready for all three mods and hope to have time to upload them this weekend.

ManuxKerb; I don't handle the actual transmission, that's all stock logic. I agree that basically everything about antennas should be handled in the background, but that's actually really hard. There are a handful of facilities for doing background processing and I've looked in to them a bit before. But it's a lot of effort and the gain is fairly marginal, so it's something that needs to get put off behind a few other code improvements that will help make it (and basically all other future features on the list) easier and more robust. TL;DR: Background transmission (and power use, etc.) are "wish list" items at this point.