toadicus

If you think so, I'll do that insteadI do think it makes more sense; carrying 1 type of fuel instead of 3 is almost certainly an engineering boon for an ultra-short range vehicle. IMO a focusing during its engineering design would be on saving weight, and eliminating extra fuel pumps, mixers, and tanks when you don't need the motor efficiency makes good sense to me. Just my 2¢, but I think that's inappropriate for a part like this... mostly because it should more or less be a "fire and forget" part. If it's (physically) balanced properly it'll orient itself during descent, so if it's (game-mechanically) balanced properly you'll have the EC you need to deploy the chutes and recover when the time comes.

I don't know your general stance on supporting other mods, but here are a few ideas I thought up, some of which fall in to that category: Packing with a DRE shielding patch would help it be useful for DRE users. Including an antenna (doesn't need to be big or animated; just something) or patch for antenna would help it be useful for RT and AntennaRange users. You don't say it explicitly above so just to be sure, it's also going to have a probe core (ModuleCommand) on board? Is this pack emulating the whole Haybusa spacecraft, or just the reentry pod? If just the pod, are the engines, SAS, probe core, etc. really valid considerations? Ignoring the question above, if the intent is merely to deorbit from LKO, would a solid fuel or monoprop deorbit motor make more sense from an engineering standpoint? In the general concept above, where would reaction control and deorbit thruster nozzles go? That seems like a hard shape to balance for reaction control given you probably don't want nozzles on the heatshield end of things. Thrust nozzle going in the middle of the docking port? I'll try to come up with more thoughts / questions.

So, there aren't any clues in there, except that FAR is trying to find something and isn't finding it where it thinks it should be; but that's not always wrong. In any case, I'm pretty sure the log got cut off before flight even loaded up, and it also missed all of the loading stuff so I can't tell if things are broken on that end of things. If you can, copy it to something like pastebin, or upload it to something like Google Drive or dropbox. Once I see your video I'll see if I can reproduce.

Mothrandir, it doesn't currently show burn time in the VAB, but I could change that. I'm in the middle of some other changes, but once that settles down I'll have a look. Technically, KSC, the Launchpad, the Runway, etc. are not biomes. They are handled by a more esoteric system that I only accidentally stumbled upon a couple weeks ago after a year and a half of supporting this. I'll see if I can reliably make it display those special locations.

Atsu, the latter is a known bug, if it is what I think it is. Have a look at the sticky launch pad fix here. The former sounds like Exceptional Behavior. If you can get me 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), I'll see what I can see.

Kerbas_ad_astra, you're talking about deploying parachutes via the staging list after a repack? I wonder if I can help with that... helaeon, intercepting control is typically very hard; I don't have the freedom to change the way Squad's code runs, so if they haven't exposed something in the API it is very difficult for me to do it; often on the order of completely re-implementing the module (which I don't really want to do). I'll take a look and see if this is within the scope of things I can do here, though.

So, your log shows every indication that the mod is being correctly loaded and the parts are being correctly compiled. If you're playing a Career game, only the Quantum Strut part will appear in the list, and it should be towards the back of Utility. Note that you'll have to unlock it first; it's quite deep in the tree. In Sandbox mode you should get three parts (two are deprecated), also towards the back of Utility. I checked on my development install to be sure they're there, and I do see them. If you still can't find them after further investigation let me know and I'll... try to thing of something to test.

The source folder does not need to be unpacked at all unless you intend to compile it yourself, in which case you should be unpacking it someplace other than GameData. It doesn't need to be in GameData or anywhere else related to your KSP installation.

First: yes, -3.40282347E+38 is a very negative number. It has a large absolute value so I'm not sure I would call it small, but as far as 32-bit floating point values are concerned, every other expressible number is greater than that number. Since the test is something like: if (rollDot > minRollDot) { // allow docking here } Using the most negative single-precision floating point number available ensures that the result will always be true and always allow docking. I'll take another look at roll requirements as soon as I can; hopefully this weekend.

rosenkranz, I'm not 100% sure of all the details, but if it's something relatively straight forward like "all the distances are 6.4 times bigger", then you could use an MM patch like this: @PART[*]:HAS[@MODULE[ModuleLimitedDataTransmitter]]:AFTER[AntennaRange] { @nominalRange *= 6.4 }

Kerbas_ad_astra, sorry for this much-belated response! If you want to add a staging toggle to parachutes, you can add a patch like this one to TweakableParachutes.cfg, or any other .cfg file in GameData: @PART[*]:HAS[@MODULE[ModuleTweakableParachute]]:AFTER[TweakableEverything]:NEEDS[TweakableStaging] { MODULE { name = ModuleStagingToggle defaultDisabled = false activeInFlight = true activeInEditor = true } } This will default to normal "parachutes in staging" behavior, and will allow you to toggle their presence in the staging list in both the editor and in flight. I'll think about adding it to the default config.

eddiew, another thing to note is that requiring a connection for probe control is also optional. The only thing that you must have a connection for is transmitting science data. I've written a couple of posts on the topic in the past, but the two-bit summary is that I feel the player is more like a local CPU executing a program on behalf of the probe core, not a ground-based observer driving it in real-time. It's also off by default, and I don't use it personally. There are many who do, though, and that's why it's here!

djnattyd, that depends on the effect you're trying to create. The range change only applies when talking back to Kerbin -- ranges to other relays are calculated exactly the same. Also, Kerbin's radius is really quite small in relation to my stock antenna ranges; only the monopole gets an even quasi-meaningful boost, it's 2% of the medium dish and 0.00075% of the long-range dish. I'm not planning to rebalance my antennas. But, if you have antennas that are intended to have a really short range and are intended primarily for use on Kerbin -- maybe for aircraft or something? -- then it might be worth reducing their range by 600,000 m.

Wheefle, thanks, and you're welcome! Glad you're enjoying the mod. djnattyd, currently there is not. I could potentially add one, or I could look at adding an "urgent" status to the Blizzy icon, which I believe would force the toolbar to show and ensure the icon is visible.

eddiew, yes they would! By default, AntennaRange will not require line of sight, so a single communications satellite in low Munar orbit with an antenna big enough to talk back to Kerbin will provide a consistent connection for your rovers. At the Space Center, though, you can open up the AntennaRange config options (the icon is a little green satellite) and enable line of sight requirements, along with a handful of other options. I strongly recommend the line of sight option; it makes things much more realistic and at least a bit more fun.

That's a feature that was requested by rkman quite a while ago, which lowers the data rate as you go outside nominal range, instead of increasing the power cost. It is technically a more realistic response to a long range connection, but over time it has the same effect.

Wheffle, thanks for the report! I found the problem; somehow in a recent commit I managed to delete a line of code that should not have been deleted. I'm gonna say my two year old did it... but who knows, maybe I slipped or something. The omission was actually in ToadicusTools; you can go get the new DLL over here; just overwrite the one that came with AntennaRange. I've also updated the AntennaRange archives on my mirror; I'll get the KerbalStuff archive in a bit.

One observation about the model itself: I don't know what the little square and round things at the "top" and "bottom" of each node are, but if they're supposed to match square-to-square and round-to-round, I'm pretty sure they can't. But, I'm probably missing something.

That ToadicusTools method only has two references: the Part that is passed to it, and the Part's ".Modules" PartModuleList. The former is protected, but the latter is not. I'm guessing one of the previous exceptions stopped something from starting up correctly, but that's just a guess. If you'd like, you can use this dev version of ToadicusTools, which should avoid throwing exceptions in such cases. But, if something else has started up wrong, that's not going to help you much.

MGCJerry, can you get me 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)? I'll take a look.

OK, for realz this time. It was a problem with my deployment scripts after some recent changes, pulling things from now-wrong places. Sorry for the noise!

Fixed. Thanks!

AntennaRange has been updated to version 1.7! This version brings a handful of bugfixes and feature improvements, along with a balance pass for the EVA transmitter. CHANGELOG: v.1.7 [2015-01-03] * Balance pass for the EVA transmitter. * ToadicusTools: Fixed command detection for KerbalSeats. * Changed the way distance to CelestialBodies is calculated; now reports distance to the idealized surface. * Added patch support for FilterExtensions.

Currently the terminal transmission target is the center of Kerbin. Kerbin's radius is 600,000 m, so any minimally-functional antenna will need that range. If you're looking to create a specific effect involving short range antennas on the surface, a current solution might be to place one of Squad's antennas at KSC. Your short-range antennas will then relay through that one -- as long as they're withing 30km and line of sight. I need to change the terminal relay logic to go to Kerbin's surface, not its core, which would make some issues like this more straightforward to think about. If you'd like, feel free to share the effect you're trying to create; I'm happy to help you find a way to do it with the tools available now, or give you some new ones. EDIT: I've changed the logic so the distance to a CelestialBody will report the distance to the idealized surface.

OK, that makes sense. I don't currently have a way to tell CKAN that ToadicusTools has been updated and needs to be redownloaded. I should have some time today to work up a new upload script for it. For now, if you're using CKAN and are having Exceptional Problems, manually reinstall ToadicusTools from one of my packages or via CKAN. EDIT: I've revised my deployment script for ToadicusTools and it's now syndicating automatically via KerbalStuff. CKAN should properly require updates.