Jump to content

[1.3.0] [MM] Radio Free Kerbin v1.2.1 (07 Aug 2017) Data Transmission for Crewable Command Parts


Ben Garner

Recommended Posts

Radio Free Kerbin

Most Recent Version: v1.2.1 (released 07 Aug 2017)

7WyuRZQ.png

 

Introduction

Are you tired of trying to mount a clunky, old antenna onto your sleek, new spacecraft? Have you been wondering how your intrepid team of kerbonauts is able radio Kouston without one? Are you afraid that the transmitter will be torn off of your plane's fuselage by atmospheric drag? Kerbin's prestigious Avalon Research Instutute has teamed up with Ionic Symphonic Protonic Electronics to bring your space program a solution! Thanks to recent advances in the science of cramming-big-things-into-tiny-spaces-that-are-way-too-small-for-them, ARI and ISPE have developed a revolutionary method to add data transmission to any crewable command module. Now, your spacecraft can enjoy crystal-clear communication with ground control--without the added bulk. The manufacturers deny allegations that this innovation was developed to clear inventory of a shipment of Communotron 16 antennas that was crushed by a delivery truck. Small chunks of rubber lodged in the product are a normal result of the manufacturing process.

For%20KSP-1.2.0-CB1D14.png CKAN-Indexed-brightgreen.png License-MIT-blue.png Source-Github-4B0082.png

 

Description

Radio Free Kerbin adds data transmission capability to all command pods and cockpits. It uses a ModuleManager config to modify the data transmission module to allow transmitting science data for all command parts with a non-zero crew capacity (i.e. not probe cores).

Note that the Radio Free Kerbin version numbers are unrelated to the KSP version numbers.

 

Features

Feature Status
 Data transmission for all crewable command parts Complete
 Remote Tech support Complete
 AntennaRange support Complete
 Kerbalism support Complete
 Antenna specs upgrade with unlocked tech nodes In Progress
 Antenna specs vary between different pods Cancelled

 

CKAN

CKAN is the officially recommended installation method for RadioFreeKerbin! Just search for it, check the box, apply the changes, and voilà.

 

Manual Installation
To install RadioFreeKerbin manually, copy the contents of the GameData folder in the download to KSP's GameData folder. If ModuleManager is already installed, you only need to copy over the RadioFreeKerbin folder.


Required

RadioFreeKerbin requires ModuleManager and will not function without it. The most recent version of ModuleManager at release time is included in the download, but it is recommended that you download the most recent version of ModuleManager at install time.

 

Supported

 

Issues

RadioFreeKerbin undergoes careful testing and review before each release. That said, it is possible that you will encounter bugs or compatibility issues with RadioFreeKerbin. Please open a new issue on GitHub with as much detail as possible and I will attempt to resolve the problem.

 

Suggestions

Suggestions for new features or changes to current ones are welcome! Please post any suggestions, comments, or feedback in this thread.

 

License

RadioFreeKerbin is released under the terms of the MIT License (also sometimes referred to as the Expat License). Basically, you may use, copy, modify, merge, publish, distribute, sublicense, and sell RadioFreeKerbin as long as you both include the license agreement if you redistribute it and agree not to blame me if it messes something up.

Addendum for Clarity

It has come to my attention that there is disagreement between many members of the KSP modding community about the role of licenses with regards to redistribution and/or modification, so I would like to clarify my stance on this. I selected the MIT License for RadioFreeKerbin after careful consideration, fully understanding the possible consequences of this choice in the future. I have no illusions that everyone else happens to share my exact same concept of what is required by "courtesy", so I chose a license that reflected exactly how my content may be used. There is absolutely no request or obligation on your part to ask permission before following the terms of the license. This is how permissive licenses have operated successfully in the free and open source software (FOSS) community for decades, and I see no reason to use such licenses with an additional de facto requirement based on arbitrary, unwritten rules of community conduct.

I suppose that I would prefer that you notify me if you redistribute my content (simply because I'm curious about what I've made being put into other cool stuff!), but this is neither a requirement nor a weird KSP community "courtesy" thing that people get bent out of shape about. If you choose not to do so (even if it's just because you don't particularly feel like it), that's awesome too and I'm not going to be upset about it; I already told you what you may do in the license agreement, which I chose in part because of its lack of a notification clause! If the license says you can, do it; if not, then don't. It's not rocket science... (or is it? :P )

 

Changelog

  • v1.2.1 (07 August 2017)
    • Updated version information to reflect compatibility with KSP 1.3
  • v1.2.0 (14 October 2016)
    • Added compatibility with the CommNet system in KSP 1.2
    • Slightly nerfed antenna specs for balance with new antennas in stock pods
  • v1.1.2 (30 July 2016)
    • Changed Kerbalism patch from .txt to .cfg
    • Fixed spelling errors in readme
  • v1.1.1 (29 July 2016)
    • Added Kerbalism support
    • Fixed syntax error in AntennaRange config
    • Removed unnecessary config value from RemoteTech config
  • v1.1.0 (16 July 2016)
    • Added RemoteTech support
    • Added AntennaRange support
    • Removed unneccessary config values that could cause compatibility problems
    • RadioFreeKerbin will no longer attempt to add an antenna if the part has one already
  • v1.0.1 (02 July 2016)
    • Nerfed antenna specs for balance with stock antennas (now same as Communotron 16)
    • Added CKAN support
  • v1.0.0 (29 June 2016)
    • Initial release
    • All base functionality is implemented and has passed early testing.
Edited by Ben Garner
Release v1.2.1
Link to comment
Share on other sites

On 7/3/2016 at 4:00 AM, GSUI5051 said:

How to make it work with Remote Tech or AntennaRange?

It does not yet work with Remote Tech or AntennaRange, but I will add it since you requested it! Expect support for both mods to be included in the next update.

On 7/3/2016 at 7:31 AM, Deimos Rast said:

It just adds a equivalent Comm 16 stock antenna to Command Pods.

I would suggest "borrowing" the RemoteTech patch for the C16 and using that as well; Antenna Range probably has one too.

Also...MN represent!

Cheers

And welcome to the forums.

:)

Well, when you put it that way, it seems clear that I should have put that in the description; it isn't clear that that's exactly what it does! I'll edit it.

Yeah, that's definitely the best way to go about doing it; no sense in re-inventing the wheel.

I don't often see others from Minnesota out on teh interwebz, so that's pretty cool. Or, at least I don't see many people that advertise that fact... :sticktongue:

Thanks, it's great to be here! I figured that I may as well contribute to the community with my first post here, so I published this mod glorified MM config file. I'll probably be uploading some other stuff eventually. I plan to create some parts that I've been wanting for a while; I have a feeling that they may fill others' needs as well.

Link to comment
Share on other sites

Heh, yea.

A few more things:

  • Maybe make the MIT license bit a bigger or it's own section; it's easy to overlook the little icon. You might need to include it in the download as well (and maybe mention the MM license somewhere just in case).
  • I looked into doing the RemoteTech patch for you (see below). Feel free to use if you like it (or not). Not trying to steal yo thunder - just trying to help a local boy out, ya know? :D
  • I added a couple things to your current patch (see below). Feel free to use if you like it (or not). My thinking is that (albeit rarely) pods will already have data transmitters and your patch will double it. I added a check for it.
  • You probably don't need "DeployFXModules = 0" as that assumes there is a ModuleAnimateGeneric (or something similar) is Module index slot = 0 which deploys the antenna. Unlikely to be the case in this situation.

Seriously, not trying to step on your toes - you really don't have to use any of this.:)

//--------------------Stock Support---------------//
@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[ModuleDataTransmitter],#CrewCapacity[>0]]:FOR[RadioFreeKerbin]
{
	MODULE
	{
		name = ModuleDataTransmitter
		packetInterval = 0.6
		packetSize = 2
		packetResourceCost = 12.0
		requiredResource = ElectricCharge
		//DeployFxModules = 0
	}
}

//----------------RemoteTech Support------------//
@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[ModuleRTAntenna],#CrewCapacity[>0]]:FOR[RadioFreeKerbin]:NEEDS[RemoteTech]
{
	!MODULE[ModuleDataTransmitter] {}
	%MODULE[ModuleRTAntenna]
  {
		%Mode0OmniRange = 0
		%Mode1OmniRange = 2500000
		%MaxQ = 6000
		%EnergyCost = 0.13
		//%DeployFxModules = 0
		%TRANSMITTER
    {
			%PacketInterval = 0.3
			%PacketSize = 2
			%PacketResourceCost = 15.0
		}
	}
	%MODULE[ModuleSPUPassive] {}
}

 

Edited by Deimos Rast
Link to comment
Share on other sites

 

On 7/8/2016 at 1:46 AM, Deimos Rast said:

Heh, yea.

A few more things:

  • Maybe make the MIT license bit a bigger or it's own section; it's easy to overlook the little icon. You might need to include it in the download as well (and maybe mention the MM license somewhere just in case).
  • I looked into doing the RemoteTech patch for you (see below). Feel free to use if you like it (or not). Not trying to steal yo thunder - just trying to help a local boy out, ya know? :D
  • I added a couple things to your current patch (see below). Feel free to use if you like it (or not). My thinking is that (albeit rarely) pods will already have data transmitters and your patch will double it. I added a check for it.
  • You probably don't need "DeployFXModules = 0" as that assumes there is a ModuleAnimateGeneric (or something similar) is Module index slot = 0 which deploys the antenna. Unlikely to be the case in this situation.

Seriously, not trying to step on your toes - you really don't have to use any of this.:)

I'll address your bullet points respectively:

  • The MIT license and the Module Manager license are both already included in the download. I will add a section to the post, though, considering that that little icon could indeed easily be missed.
  • Wow, first, I've got to say thank you for taking the time to do that! Actually, if you have a GitHub account (I'm guessing you probably do), could you fork the repository (dev branch, please), add your changes, and submit a pull request? That way, your contribution is noted more "officially".
  • Good point, I didn't consider that; definitely a needed change!
  • Whoops... :blush:   I set it to 0 because I thought that DeployFxModules was included in ModuleDataTransmitter, although I may have been mistaken. Either way, it is unnecessary, and worse, could cause problems with any pods that had DeployFxModules already (I don't know if there are any, but there's no sense in leaving that pitfall in there since it's not needed).

You can rest assured, my thunder remains unstolen and my toes untrodden. :wink:  Actually, I appreciate the fact that you took the time, however brief, to bother doing that; it saves me the work :P and you caught some things I had missed. Please do contribute these changes to the project on GitHub; you deserve credit for it. :)  I will wait to add them until Friday around 10:00pm if you don't respond or submit a pull request.

Edited by Ben Garner
Added quote for context
Link to comment
Share on other sites

coolbeans.

One problem in the RT patch: you added in MaxQ (or maybe I did, who knows:rolleyes:): it causes the part to break if exposed to high dynamic pressure, which:

 

  • a) only applies if the part has a two stage animation (these are always on antennas) e.g. a physical communotron opening and closing
  • b) command pods are frequently the root part, and if these root parts are broken by remote tech, it causes "bad things" to happen.

 

Also, not sure on syntax, but can you even do a :NEEDS[AntennaRange],[!RemoteTech] ? I've always seen [AntennaRange&!RemoteTech]. It might need to be inside the brackets if you use a comma, or else a double :NEEDS.

Cheers.

(I can do another pull request if you like).

Link to comment
Share on other sites

On 7/17/2016 at 3:04 PM, Deimos Rast said:

coolbeans.

One problem in the RT patch: you added in MaxQ (or maybe I did, who knows:rolleyes:): it causes the part to break if exposed to high dynamic pressure, which:

 

  • a) only applies if the part has a two stage animation (these are always on antennas) e.g. a physical communotron opening and closing
  • b) command pods are frequently the root part, and if these root parts are broken by remote tech, it causes "bad things" to happen.

 

Also, not sure on syntax, but can you even do a :NEEDS[AntennaRange],[!RemoteTech] ? I've always seen [AntennaRange&!RemoteTech]. It might need to be inside the brackets if you use a comma, or else a double :NEEDS.

Cheers.

(I can do another pull request if you like).

Yep, looks like MaxQ was in the RT config you provided, glad you caught that!

Yeah, that syntax is wrong; don't know what I was thinking. I've never seen a double :NEEDS and I don't know how MM would deal with that, so I'm steering clear of that. I also didn't see anything relevant in the documentation. The comma does indeed need to be inside of the brackets, given that the brackets are delimiters containing the arguments of :NEEDS and not part of the identifiers. I've made those commits to the dev branch and will probably pull them to main and do another release in the next day or so.

Cheers.

Link to comment
Share on other sites

On 7/17/2016 at 3:04 PM, Deimos Rast said:

coolbeans.

One problem in the RT patch: you added in MaxQ (or maybe I did, who knows:rolleyes:): it causes the part to break if exposed to high dynamic pressure, which:

 

  • a) only applies if the part has a two stage animation (these are always on antennas) e.g. a physical communotron opening and closing
  • b) command pods are frequently the root part, and if these root parts are broken by remote tech, it causes "bad things" to happen.

 

Also, not sure on syntax, but can you even do a :NEEDS[AntennaRange],[!RemoteTech] ? I've always seen [AntennaRange&!RemoteTech]. It might need to be inside the brackets if you use a comma, or else a double :NEEDS.

Cheers.

(I can do another pull request if you like).

 

On 7/22/2016 at 2:02 AM, Ben Garner said:

Yep, looks like MaxQ was in the RT config you provided, glad you caught that!

Yeah, that syntax is wrong; don't know what I was thinking. I've never seen a double :NEEDS and I don't know how MM would deal with that, so I'm steering clear of that. I also didn't see anything relevant in the documentation. The comma does indeed need to be inside of the brackets, given that the brackets are delimiters containing the arguments of :NEEDS and not part of the identifiers. I've made those commits to the dev branch and will probably pull them to main and do another release in the next day or so.

Cheers.

Whoops, I forgot to update it after making the changes. I just released v1.1.1 which corrects this and adds Kerbalism support. Sorry about that.

Link to comment
Share on other sites

Given that all command pods have this inbuilt antenna, what made you decide to go with the home scope rather than the orbit scope?  (They also do expand over time - orbit will eventually become most of the home system, kerbin + mun + eventually minmus in stock).

Link to comment
Share on other sites

15 hours ago, JeffreyCor said:

Note that your Kerbalism patch was packaged as a txt, not a cfg so those with Kerbalism will need to rename the file to take advantage of added support. :)

Wow, ouch. Fixed and creating new release. Thanks... :blush:

9 hours ago, darloth said:

Given that all command pods have this inbuilt antenna, what made you decide to go with the home scope rather than the orbit scope?  (They also do expand over time - orbit will eventually become most of the home system, kerbin + mun + eventually minmus in stock).

The Kerbalism patch was provided by the mod's creator, so I figured there was a good reason for that and I didn't modify it. If enough people would rather have the scope changed, I can definitely change it.

Link to comment
Share on other sites

  • 2 weeks later...

G'eve, sir, and first off, thanks for this mod. I've long wondered why this wasn't done stock, and it certainly simplifies some of my builds, especially in the early tech eras.

Since you mention in your OP that CKAN is your recommended installation method, however, I am surprised that (as of this AM when I last checked it) the 1.1.2 version hasn't propagated to CKAN yet. Was this overlooked, or was this deliberate for some reason not mentioned in this thread?

Either way, my thanks again.

Link to comment
Share on other sites

On 8/13/2016 at 7:38 PM, Shadriss said:

G'eve, sir, and first off, thanks for this mod. I've long wondered why this wasn't done stock, and it certainly simplifies some of my builds, especially in the early tech eras.

Since you mention in your OP that CKAN is your recommended installation method, however, I am surprised that (as of this AM when I last checked it) the 1.1.2 version hasn't propagated to CKAN yet. Was this overlooked, or was this deliberate for some reason not mentioned in this thread?

Either way, my thanks again.

You're welcome; I'm glad you enjoy it! This was not intentional and I'd like to apologize to you and my other users for letting this go on so long; I was preoccupied with developing another mod I plan to release an early version of soon. I think what caused this problem is that I erroneously tagged the latest release on GitHub as "1.1.2" rather than "v1.1.2", so the URL I provided in the .ckan file didn't actually link to it. I fixed that a few minutes ago, so hopefully this issue will be resolved with the next CKAN-meta update. Here's the issue on GitHub in case you want to take a look. I'll reply here with what happens as well.

On 8/18/2016 at 5:49 PM, Bombaatu said:

The Kerbalism info panel reports that pods do not have antennas - I get the red 'bars' symbol, even though I can transmit data. Is this a known issue?

This is probably caused by the above issue: if you installed via CKAN, you don't have the new version that added the Kerbalism patch. Sorry... :blush:

Edited by Ben Garner
Added links
Link to comment
Share on other sites

  • 9 months later...
  • 1 month later...

@Ben Garner its good that this works in 1.3.  For those of us that prefer to automate the updates, are you going to do a 1.3 recompile/release so CKAN and AVC will see it as compatible with 1.3?  If not, would you mind if someone else did and gave you the results?

Edited by Murdabenne
Link to comment
Share on other sites

  • 4 weeks later...
On 6/12/2017 at 5:29 PM, Rohaq said:

Has anyone tested this on 1.3 yet? It's still showing as max version 1.2.99 on CKAN.

On 6/12/2017 at 5:52 PM, dragonsmate17 said:

I am using this in 1.3 with no problems

Radio Free Kerbin v1.2.0 works in KSP 1.3 with no problems. I have updated RFK to v1.2.1 to include the most recent version of MM and to update the version metadata included for mods such as AVC. None of the actual .cfg files have been changed.

On 7/13/2017 at 5:20 PM, Murdabenne said:

@Ben Garner its good that this works in 1.3.  For those of us that prefer to automate the updates, are you going to do a 1.3 recompile/release so CKAN and AVC will see it as compatible with 1.3?  If not, would you mind if someone else did and gave you the results?

I appreciate the offer, but I just now updated it. I apologize for leaving it like that for so long; I honestly thought that I had done this months ago! I've been pretty busy with real life over the last several months. I hadn't noticed that it wasn't updated on CKAN because I have my Compatible Versions set to include KSP 1.2 (I use several mods that have the same problem as RFK did). As soon as CKAN-meta updates (should be in under 24 hours), the new version should get picked up.

Link to comment
Share on other sites

  • 7 months later...
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...