ethernet

I considered doing this but decided against it based on two of my design goals: 1. Add new gameplay that is challenging, with commensurate rewards. 2. Only add to the stock gameplay; don't remove anything. If I add my Science Lab functionality to the stock Processing Lab, I have to violate one of those goals, due to the mass. If I leave the mass as is, I eliminate all the challenge in launching the current Science Lab. The stock Processing Lab's mass is ridiculously low for its size (less than the 3-man pod), and trivial to launch. But it's approximately appropriate for how little it actually does. Therefore, if I increase the Processing Lab's mass to account for my added Science Lab functionality, then it disrupts anyone who wants to use the stock functionality on its own. They now are dealing with a module whose mass is too large for the benefit the module provides. Certain mission profiles could become non-viable.

Haven't been able to reproduce this. If you can, please send me your persistence file. Once I release the custom model for the Science Lab, that might take care of the issue. Not aware of any issues with Interstellar. Do you have any other mods installed? Is the hitchhiker storage container also showing this issue? The Science Lab uses that model, so it would be strange if one were affected and not the other.

Not technically fairings, but did something along similar lines: a 50s-Sci-Fi style single-stage rocket.

Obviously the "Kraken Drive" should be fixed. It breaks game balance. If you want a reaction-less drive, it would be trivial to do so in a mod. Same is true of "Ram-Intake-spam turbojets", and part clipping (without the debug menu), and I say that even as most of what I've been doing lately uses those things. It's fun to take a game and push it to its limits and see how it breaks. But when those limits are obviously contrary to intent of the game, they should be fixed. Getting angry about the devs fixing the bugs you found is looking at it backwards. You should be grateful for the new challenges, the new limits to look for.

Yes, that kind of Surface Sample. But a Surface Sample from Kerbin would be pointless. The only purpose of the Spectrometron is to enable transmitting Surface Samples at 100%, but you can trivially recover a Kerbin Surface Sample for 100% as soon as you get it. It's kind of like the stock game's Processing Lab. It's pointless to bring things up from Kerbin to analyze in an orbiting Processing Lab. The point would be to put a station around another planet or moon, and use it to process Surface Samples from below and transmit them without having to make the trip back. It'll be more useful once interplanetary destinations get biomes.

The Spectrometron analyzes "Surface Samples", using Kuarqs. The Kuarqs should be generated at the station; they don't need to be "brought up" from anywhere. Do you have a Surface Sample somewhere on your station?

Sorry, I'm not sure I understand your meaning. Are you saying the Science Lab part became smaller when you swapped to the station and back, or that you lost Eurekas when you swapped to the station and back? BTW, there's a bug that permits doing Station Science experiments on the launchpad; they're supposed to be locked out on Kerbin's surface. It'll be fixed in the next release.

Ah, missed the EVA reports. Shouldn't be hard to restore the stock ScienceDefs.cfg, but delete everything but the EVA reports section. Glad its working now! So, anyone else still having issues with the Deploy bug?

I believe a better workaround would be to just remove the stock ScienceDefs.cfg file from the Squad/Resources folder. BTSM does a full replacement of the stock ScienceDefs, so having both is redundant, and as it turns out, causes problems for other mods. Ideally, BTSM would use ModuleManager to make its adjustments, but I'm not sure ModuleManager supports changing EXPERIMENT_DEFINITIONs (I've never worked with it myself), and I know the BTSM author doesn't care about other mods working alongside his mod, anyway. Another solution might be to simply rename the StationScience folder to, say, AStationScience, to ensure that my experiments get loaded before BTSM's.

Thanks. Naturally, I load this up, and it works fine for me: the pod says Finalize Results, and when I click it, I get the experiment results as expected. One oddity I found: in your log file, the game seems to be loading a file GameData/Squad/Resources/ScienceDefs.old.cfg (or ScienceDefs_old.cfg): [LOG 18:10:58.223] Config(EXPERIMENT_DEFINITION) Squad/Resources/ScienceDefs_old/EXPERIMENT_DEFINITION This line appears a number of times in a row in your log. When I start my version, I don't see it at all. Do you have such a file in your install directory? If so, do you know where it came from? Does removing it help? edit: Just tried it out myself by copying ScienceDefs.cfg to ScienceDefs_old.cfg, and I duplicated the issue! Now, the pod says Deploy, and clicking it doesn't do anything. What I suspect is happening is that after the stock ScienceDefs get loaded, the duplicate ones in the "old" file screw up the loader, and when it comes to my experiments, it isn't loading them correctly. So now the question is where does the "old" file come from? Are all you guys having this issue using Steam? Maybe it's an artifact of the Steam upgrade system?

Is your rocket breaking? You can view the F3 log to find out. Those parts are quite heavy, so if you're not careful, its easy for them to sheer off the part below. If that's the case, use struts to reinforce the connection.

The missing Eureka resource suggests a problem with the files in the Resources directory. You should have "Experiments.cfg", "Eurekas.cfg", "Bioproducts.cfg", "Kuarqs.cfg", and "Kibbal.cfg" in your Resources directory under GameData/StationScience. Are they there? I'm still not having any luck reproducing the "Deploy" bug. I think it's caused by the game not seeing the experiment definition (in Experiments.cfg) for the one specified in the pod part, but I don't know why that's happening for some but not others. From someone who's encountered this bug, I'd appreciate the following: The persistence file A list of all mods installed A ZIP of your GameData/StationScience directory

Yeah, sorry about that. This mechanic seems to be causing more problems than I'd anticipated; you're not the first to be hit by it. I'll probably add an exception in the next update so that moving between high and low orbit doesn't trigger a reset. There's no difference in science value (even though the internal data structures say there should be...) so it's not a balance issue like moving an experiment to another planet would be.

What is the periapsis and apoapsis of the orbit? If you're crossing between high and low orbit (boundary is at 250 km), that would cause it to reset. If that's not the problem, can you send me a persistence file that demonstrates the issue?

It's been suggested before, but I like to keep to simple integer-per-time-unit rates where possible to maintain clarity. The bonus would have to be bigger than I'd like to maintain that. Also, Interstellar's Science Module already does what you suggest, and I don't want to just copy that. There isn't a good way to do power consumption while the station is unattended; this is why the Cyclotron doesn't work while unattended. But I want the Science Lab and Zoology Bay to work unattended to allow for long-duration experiments, so they can't depend on electric charge for their functionality.

In addition to the little capsules, you also need the Science Lab included in this mod; not the "Processing Lab" provided in the stock game. For Kuarq experiments (and to use the Spectrometron), you also need the Cyclotron attached, and for the animal experiments, the Zoology Bay.

I don't want to move things later in the tree, otherwise they get unlocked after they're useful. As for mass, I'm open to tweaking the masses if I don't think they're right, but I want to provide challenge, because challenge is fun. It could be too far, and be frustrating, but most of the feedback I've seen so far seems to be OK with the masses as they are. It's certainly possible to put the parts into orbit with just 1m parts. Try starting a Sandbox game and see if you can see them in the VAB there. You should actually see two sets of experiment pods there; the old "welded stock parts" placeholders, and the new models. Can you send me your persistence file? All the stock command parts include SAS; the old ASAS part is actually quite pointless now. Reaction wheels can help, but are hardly necessary. And are an early tech, anyway. RCS is unlocked just after the Attach-O-Tron, along with fuel lines. I think this is OK. It means you can send up the Science Lab first, and then unlock RCS later to send up more modules to dock with it. Ultimately, I don't think these sorts of issues are a problem. If someone doesn't have the chops to put together a station with just the bare minimum tech needed to unlock the parts, they can just wait until they unlock more parts. I don't want to change stock parts/mechanics with this mod. My goal is to add new gameplay, and I don't want to bundle it with changes to existing gameplay that some people might not like. But if you want to put together a science mod that overhaul's the stock parts, my source is open for you to use.

With EVA'd Kerbals. Move a Kerbal near an experiment part, right click it, and collect the data. Then board the lab or capsule to store it there. Command pods can only hold one experiment from a given location at a time. The Processing Lab can store any number of experiments, of any kind. Given how light it is, its' actually quite viable to use it to return experiment data to Kerbin for full Science credit.

Still not seeing the issue on my end. Tried extracting the spaceport download to a fresh install of 0.23. Everything I attach works as I'd expect, with or without angle snap, and in both the VAB and SPH. Do have other mods installed that might be interfering? Thanks for the suggestion. I hadn't realized that model is public domain. I don't think I'll be going that way for a few reasons. First, it's already in well-known use by Interstellar, and it would be confusing to use it in my mod if people use it alongside Interstellar. Which I want to support, as it gives a good use for the large amount of science this mod can produce. Second, it's not really "stock-like"; it's a bit more futuristic. Good for Interstellar, but not what I'm going for here. Finally, since zzz didn't provide the source model, just the compiled .mu, it would be hard to create other parts, like the Zoology Bay, in a consistent style.

Thanks for the feedback, but I've not been able to replicate the issue. Everything seems to surface attach correctly to the experiment pods. Could you send me a .craft file that demonstrates the issue? I.e., attach something to a pod without adjusting its orientation manually.

Yes, but to be clear I'm only talking about the pods from my mod. There's no effect on other science parts. I wouldn't call that "game breaking"; cleaning experiments is a pretty minor part of the game, and it does work. It's a problem with the stock game logic for the Processing Lab that I don't see a good way around. The first screenshot in the OP shows the new experiment pod model. They're all the same just with a different decal for each. The new docking port is visible as well. Never got a PM. I'm making progress on the other part models. Thanks, but at this point I'd rather do it myself. A lot more elegant in concept than in execution... the game really does not want anyone messing with fuel transfers.

The fourth alpha is now available. Changes include: 0.23 compatibility. Changes to the resources system caused problems with the small resource quantities this mod deals with. Added the Attach-O-Tron docking port. This "prototype" port is available early in the tech tree, but does not permit fuel transfer. Added models for the experiment pods. These models will only apply to newly launched vessels. Old pods will remain as-is. Moved parts to the science branch of the tech tree. The parts are more spread out, but generally permit gaining science with this mod sooner. Experiments can now be transmitted, but at a low return rate. Finished non-bioproduct experiments can be collected by EVA'd Kerbals. Fixed an issue with unattended operations. Known Issue: Using the stock Processing Lab to clean this mod's spent experiment pods takes an extremely long time, and cannot be timewarped. The issue appears to be that processing time is proportional to the value of the experiment. There doesn't seem to be anything I can do about this. Delete the old StationScience folder if you're updating from an older version.

Thanks for the link; hadn't seen that. I'll look into it incorporating it once it's released.

I'm working on an update for tonight or tomorrow. As far as I can tell, though, the existing release still works with 0.23. Only problem I've found (and am now trying to solve) is that rounding errors seem to be preventing Eurekas from accumulating while playing at real-time (outside of Time Warp). 0.23 changed Science a lot less than I expected. The Science Lab (which ended up being the Processing Lab) turns out to not have any real overlap with my mod, so things won't be changing all that much. I'll be releasing models for the experiment pods, but the rest are still in-progress. Biggest new feature will be a "prototype" docking port that can't transfer fuel that I'll place early in the tree, so I can place my other parts earlier in the tree where they'll be more useful.

It should say "Finalize Results", not "Deploy". So something's wrong. If the StationScience/Resources/Experiments.cfg file is missing or incorrect, I've seen that happen. Try deleting the StationScience directory and re-extracting it. If that doesn't fix it, please send me your persistence file and I'll see if I can find what's wrong.