toadicus

VOID has been updated to 0.9.12! This is an incremental change, but something bigger is coming. v.0.9.12 [2013-11-17] * FEATURE: Added a configurable precision for some values in the Orbital pane as a trial run. * FEATURE: Added support for real-time rate limiting to keep overhead down (see "Update Rate" in config). Currently only supported by Orbital. I put a trial version of this into the Orbital pane only for now. The "P" buttons next to several values will loop through various precision levels from 0 to 12 digits. To you and everyone else: how do you like the presentation? Would you rather have per-pane precision toggles? Do you want something a little different? This brought another item I'm trying to improve to the fore, which is that the numbers currently look really "jumpy" in many cases. My first round against that was to introduce rate limiting (currently only supported by the Orbital pane) to prevent VOID from change values too often and making a blurry mess of things. The default value is about 15 updates per second, which to my quick testing had a good mix of "not too fast" and "not too slow". Closer to 12 might be better for readability on some of the finer points. What do you think? What rates look best to you? My next step will probably be to put some numbers through a moving average to slow them down. The numerical noise on things like SMA while not warping, or vertical/horizontal surface speeds while landed, is really messy and can probably only be settled down through some damping like that. But, I'm working on redoing the way I handle display values in general, so this will probably come as a part of that. Thanks! I'm glad you're enjoying the mod.

Same reply as for VOID. Glad you like the mod!

Response in your PMs. Short answer: yes.

Another quick update because apparently I need to stop coding and actually play a bit. v.0.9.11 [2013-11-12] * Moved the editor HUD to the top left corner to avoid conflicts with the staging selector. It should move with the parts list, as relevant, as well. * BUGFIX: Added a GUI reset to fix the case where modules would not draw after a "revert to launch" in flight mode or "load craft" in editor mode.

VOID has been updated to version 0.9.10! This version introduces the first editor module: a HUD with some rudimentary data about the craft you're building. My current roadmap includes a lot of cleanup in terms of code documenting and organization, and a mini "scripting language" to customize the contents of the HUD modules. But first I need to learn how to do that. What else would you like to see? Changes: v.0.9.10 [2013-11-12] * FEATURE: The VOID framework now supports Editor modules! A very rudimentary HUD has been added to the editor by default. Please recommend additional information and features to include! * BUGFIX: The VOID icon can be relocated again. Uncheck "Lock VOID Icon" in the Configuration menu and drag it where you want it. Note: in the editor, the button-dragging doesn't work, so the icon is docked to the main VOID window. * BUGFIX: Changes to the skin are now correctly saved and reloaded. * VOID windows now "clamp" to the edge of the screen so they cannot inadvertently be lost.

Because I broke it. I already have a fix internally; it's forthcoming.

VOID has been updated to 0.9.9! This version represents a complete rewrite of the underpinnings of the VOID. VOID is now completely modular and extensible, and uses the new save file format. All of the existing functionality has been ported into the new module format, with a handful of exceptions. What's Different? Lots and lots. What Should You See Different? Almost nothing. The primary exceptions are: VOID Icon cannot currently be relocated. Skin choice is somewhat different. Localization is currently entirely absent (instead of meaninglessly "English only"). Why the change? This gave me a good opportunity to really dig into the VOID code base and familiarize myself with the various modules. It also provides me with a new, accessible way of adding new modules. Now, instead of needing to find the right places to stick in a new window, its internal properties, and its configurable properties, I can do everything by adding a new class with as few as two unique methods. It also makes things more maintainable: by compartmentalizing the modules, I can hunt down specific issues or add specific items in a code file that's less than 2000 lines long. What can you do? Install the new version, use it, and report bugs! I believe this version to be largely free of problems, but users are typically much better at breaking things than designers. I'd also like to hear from you folks: are there any modules that you just never use? In particular, I'm looking at the data logging module. It has a few problems, and in my estimation it's missing some information and some functionality that it would need in order to be a genuinely useful tool. Is that worth working on? Coming soon Editor modules?

Yeah, that's out of my hands. All of the code about that, from queuing to transmitting to delivering science, is locked up. I'd need to entirely re-implement the data transmitter to fix that, and that has potentially dire implications about science production if I get it wrong. You should file a bug about that specific behavior; data that's been flagged for transmitting should transmit automatically when it's reached in the queue.

Unfortunately no; at least not directly. Squad's transmission code handles that, and it's all in a few private methods and subclasses. I can't override them, and I can't readily duplicate their functionality with confidence because a lot of the logic is obscured in the assembly. With a bit of futzing around, I could probably make the antenna re-extend after the transmit logic retracts it, if it was extended in the beginning. Would that be close enough for your purposes?

In the stock game, a clean ascent is about 4500 m/s. If you use Ferram Aerospace Research, it's more like 3600 m/s.

Currently, KSP rates the "best" transmitter to use when clicking "Transmit Data" on a science part with a GetTransmitterScore method in a couple of the Science classes. However, the metric doesn't make a lot of sense from a unit examination perspective, and weighs data capacity twice. The stock implementation of GetTransmitterScore is: Score = (1 + DataResourceCost) / DataRate Lowest score wins. The stock DataRate and DataResourceCost are: DataRate = packetSize / packetInterval DataResourceCost = packetResourceCost / packetSize So: Score = ((1 + packetCost)*packetInterval)/packetSize^2 The resulting score is essentially in terms of joules per byte per baud. Rearranging that a bit, it could also look like joule-seconds per byte per byte, or newton-meter-seconds per byte per byte. Either way, that metric doesn't seem like a very reasonable one. Two metrics that might make more sense are joules per byte or watts per baud. Because KSP tightly couples power and bandwidth, they actually come out exactly the same at this point: WattsPerBaud = (packetResourceCost / packetInterval) / (packetSize / packetInterval) JoulesPerByte = packetResourceCost / packetSize

This mod does not address the spammability of science points from transmitters or the science values delivered in any event; it only limits the range of the antennas in order to require the use of the bigger ones, and rewards the use of smaller antennas on more-local craft. In Wednesday's dev notes, HarvesteR laid out some changes to science transmission that should address the spamming problem. I don't know if that's slated for 0.23 or 0.22.1, but either way I'm writing off that particular problem as "Squad is already fixing it."

Now available on SpacePort; OP updated. Enjoy!

The short answer is "yes", but the long answer is "I'd need to learn more about GUI functionality to do something like that." A feature like that is probably also going to take a back seat to cleaning up the functionality we already have. That said, I do like the idea. I've stuck it in the TODO, and I'll get to it eventually.

In 0.22, Squad has the science parts posting variously-colored ScreenMessages via ScreenMessages.PostScreenMessage. However, I can't find a clean example of how to color them or alter the fonts. Does anyone here know how to do so? TIA

In that this mod is generally designed to limit range, and in that RemoteTech changes a great deal about the communications infrastructure, my guess is "no". I don't use RemoteTech and I haven't tested this with it in any way.

Ever wanted to use one of those cool looking dish antennas, but the engineer in you just wouldn't let you spend the extra power and weight? Well, now you can force yourself to use them! Designed as a drop-in replacement for ModuleDataTransmitter, AntennaRange handles range-finding, power scaling, and data scaling for antennas during science transmission. Its functionality varies with three tunables: nominalRange, maxPowerFactor, and maxDataFactor, set in .cfg files. In general, the antennae are tuned as follows: Communotron 16 - Suitable up to Kerbalsynchronous Orbit Comms DTS-M1 - Suitable throughout the Kerbin subsystem Communotron 88-88 - Suitable throughout the Kerbol system. What It Does AntennaRange specifies a nominal range at which the antennas work exactly as prescribed in Squad's .cfg files. Below that range, the data packet size increases up to a maximum, effectively increasing bandwidth and decreasing power cost. Above that range, packet size stays floored at Squad's value, and packet power costs increase. When power cost gets too high, the antenna no longer functions. Both values scale with the square of the distance. Finally, transmitter scoring has been adjusted so that the science subsystems will prefer the cheapest antenna in terms of charge/data. AntennaRange also provides simple relaying support. That is, if your ship has a short range antenna, but is in range of a longer range antenna that can communicate back to Kerbin, it will do so. At this time, no attempt is being made to model electric use on the relay vessels; this mechanic is intended to feel rewarding for those interested in putting together a relay system (say, a flat dish antenna in orbit of Minmus so your probes can just use whips, or a big dish in high Jool orbit with a few flat dishes in low orbits, so once again your probes can use whips). Because of the limited number of antenna parts and because this mechanic is intended to be optional, range is not additive: if you want to use a whip from far away, you need a bigger antenna within whip range. AntennaRange has a small handful of optional features to enhance gameplay: a line of sight requirement, a probe connection requirement, and a "fixed power cost" requirement. As its name implies, the line of sight requirement requires that antennas must have an unobstructed line of effect from their origin to their target, whether that's Kerbin or another relay. Only a planet or a moon can block line of sight at this time. The probe connection requirement will disable control of unmanned craft whenever no connection can be made from the active craft to Kerbin. Finally, the fixed power cost makes the "long range" penalty mirror the "short range" benefit -- slowing down data transmission instead of increasing power cost. This makes it simpler to design probes that will remain controllable while transmitting, at the cost of using up more of your time to do it. What It Does Not Do AntennaRange does not pretend to be any sort of "realistic" communication system. If you're looking for that sort of thing, look in to RemoteTech or kOS or something similar. Don't Forget If you have craft outside of Kerbalsynchronous orbit with nothing but the whip antenna, they will be unable to transmit data until they get closer. Beware when installing this mod with an active career! Documentation There is a wiki at GitHub that describes the various options and offers some technical documentation for patch authors. [wiki] Compatibility Patches Users are welcome and encouraged to submit patches for use with other antenna mods! The official place to keep track of ModuleManager patches is at the wiki: [compatibility patches] DOWNLOADS SpaceDock: [zip] Not SpaceDock: [zip] [tar.gz] [tar.xz] CHARITY: Do you like what you see here so much that you can't imagine downloading it without first parting with your hard-earned money? If so, this specially-crafted PayPal donation button will help you to take the currency of your choice and make it my money instead of your money. More seriously though: donations are 100% optional and entirely at your own discretion. If you do choose to donate, I'll appreciate it! INSTALL: 1. Unpack archive into /path/to/KSP_folder/. 2. ??? 3. Profit! USAGE: * Add Squad's antennae to your ships as normal. Just make sure you use the right one(s) for the job! CHANGELOG: LICENSE: OP screenshots provided by ObsessedWithKSP; used by permission.

Updated to version 0.9.1, incorporating the fixes and recommendations from VOID user 11Bravo49417. Thanks!

This isn't VOID, that's KSP. All the CelestialBody viewer does is pull the list of bodies from FlightGlobals.Bodies and spit out the information available through the API. VOID reports a 14 km atmosphere altitude because that's what Moho says it has.

VOID does not currently have aerobrake / landing prediction. I don't think I do have an itemized list of everything it does display... maybe I should work on that.

That is fun! Great to see where we've come from, and interesting to see when new information was introduced.

Updated to version 0.9.0, now featuring delta-V calculations via VesselSimulator from Engineer Redux. Thanks to cybutek for making his software open and available and for his kind permission.

Yes, the new biome features will break compatibility with older versions. Here is a legacy version as of June, version 0.8. It should work in 0.18 and newer, but no promises. I do not intend to maintain a legacy version at this time.

VOID does not currently display delta-V directly. I'll try and take a look to see how involved it would be to figure it with multiple stages and dissimilar fuels and such.

I am no longer looking to do so; in fact I already have. Now available in VOID: http://forum.kerbalspaceprogram.com/threads/54533-0-22-VOID-Vessel-Orbital-Informational-Display