Ruedii

The position of the engines in the tech tree needs adjustment. Some should be early on, some should be later. Most of them should be in some of early flight related nodes (based on power) except the really big ones which should be in heavy aerodynamics, and the ones capable stable flight above 16.5km which should be in high altitude flight. The same should go with complementary parts, which should be positioned based on size. These changes are very simple. I could make them for you. If you had a github or bitbucket page for the project it would make it a lot easier, though.

I recommend making a separate one for each resource for balance.

As of 1.1.x you don't want to limit to 2 cores. KSP is now capable of utilizing as many cores as you have. You need to insert a line divider of some sort there. I'm not sure what it is. Also, "exec taskset -c 2-3" is no longer an optimal option as of KSP 1.1 due to the fact that KSP now utilizes all cores. (At least up to 10, I'm not sure the maximum number the updated PhysX library is compiled for.) There may be another option to discourage moving the threads between cores, which would improve CPU Cache hits without slowing down the physics simulation. I know there is one somewhere in the /sys fs or /proc/sys fs. (I forget which or where.)

Fairwell, you will be missed. Good luck on your future endeavors.

Guilty!

As long as your card supports DirectX 9.2 or OpenGL 3.2 you won't notice any difference in quality. If you already have settings maxed you won't see improvement there, although you could improve quality further with the nvidia utilities that allow for supersampled resolutions.

Would be nice to add simple meshes to them.

Yes, so long as it's nerfed to not be able to make reentry, it might be good for one of the earlier flight-related nodes. Are those trees scatters or Kerbol Konstructs objets. It would be really cool if you could get some trees and shrubs in as kerbol konstructs objects that are actually solid.

First, try a new save file. Second, make sure your plugs are securely connected. (Yes, you need to use the plugs). Third, make sure the station has power.

I would be safe to assume this works on KSP 1.1.3, right? It's just a simple parts pack. Any chance we could get the version files updated for CKAN? Seems it uses SpaceDock metadata, so updating there should get it to work. (You have to love the SpaceDock integration with CKAN.)

First, Question: Has anyone tested it with 1.1.3 yet? Second I have some replies and comments for other people's comments/questions. The rear seat would need to be lowered, but it might fit. If not, a two seater version could be made by simply making ever so slight variations to the model. I would think that it should be moved to the heavy flight node.

Can we get the AVC files updated for 1.1.3 so that CKAN will know?

That particular function relies on KAS, so it may be a KAS issue.

It seems it combined too of my posts, and didn't properly quote either. The experiments explode when the move around on the ground. You need to secure them to the ground using a kerbol engineer and a tool. Any experiments that don't properly secure to the ground need a ground base, which is an item in your KAS pack for mounting items to the ground in a more secure fashion. Yes, perfect example, basically if you are having trouble with an experiment slipping, use a ground base as pictured here. I commonly have problems with my control station and batteries slipping. The battery has a lot of stuff attached to it, and the central station is just big and bulky.

Hmm, so you can't do that without a major plugin? Hmm. I don't think there is currently one written. If you'd like to integrate such a plugin into your mod, you'd probably be the one to put it on the mod request forum.

I was thinking, making these experiments like the science lab, and having to leave them running for an extended period of time would be a really good addition. You would need a scientist to start the experiment and download the data. The experiments would run unattended for a period of time. To be more specific, each module should have 3 experiments: Basic reading: Immediate, low science yield per data. Short-term monitoring: Works slowly, runs for three hours, Requires scientist to collect the data. Long term monitoring: Creates continued science data like the science lab for a maximum of one Kerbin year. Data slowly gathers in main controller unit automatically for later transmission or collection by a scientist. Finally, there should be a plug device to stream data from these experiments to science labs on ground bases, to create a steady stream of science data over a year. The device should include a buffer for if the lab is full. Double check that all your connections are secure. Movement in KAS connections can sometimes make them disconnect. Generally I recommend securing your plug to a ground base so it doesn't move around and break the connections. This also makes it look nice.

I was thinking along the same thing. Probably just fuel tanks (including monoprop), couplers, adapters engine mount plates, and a cargo bay. For docking a Docking port adapter plate could be made, which simply is a nice little shim with both navlights and spotlights to fit around a smaller docking port. Any pre-made engine cluster should use existing assets and pretty much just be to save on part count. You probably just poll people on their favorite combinations after the release. You may want to do the same to reduce the number of pre-made engine cluster in the existing packs as well. Additionally, above 5m should really be controlled by RCS, as reaction wheels don't do well with extremely long rockets, which is the whole point of going to such wide widths.

Any chance we could see 10 meter and 15 meter behemoth rockets in this pack any time soon? I'd mostly just use them for fuel tankers, fueling stations, and ultra-heavy lifters.

Yeah, that's right. I can't find the number used by Star Trek for Life the Universe and Everything. I do know 47 was used a lot in Star Trek (TNG and later). It was a reference to a writing by a math professor of on who arbitrarily chose 47 for a fake proof to teach his students to determine if a proof really actually proved what it said it did. The number 47 was chosen because, like 42 it is a seemingly arbitrary number that has a lot of numerical and pattern based coincidences. In fact, I suspect there are only two reasons 42 was chosen for HitchHiker's Guide to the Galaxy over 47 was because Douglas Adams wanted an even number, and the Alice in Wonderland series that also uses the same number a lot was a major influence on Douglas Adams. (I'm not sure if this was exactly why the number was used, but it was likely an influence.)

I was thinking that it would be cool to do add an "advanced monitoring" experiment version of each of the stock experiments. Basically add an advanced monitoring device to attach them to which has to hook up all these other parts. Also, it would be really fun to have to use an engineer for some tasks relating to this mod, and a scientist for others.

I just realized the type of fuel cell that should work on monoprop. A membrane electrostatic transfer membrane. Basically when any fluid is pushed through certain membranes, electric charge (either electrons, or electron holes) is moved with it. Some fuel cells can utilize this technique to generate electricity from pressurized gases such as expanding propellant. I can write up a description for a github pull request if you like.

Oh, and if you need someone to scrounge through config files to fix some minor bugs, I may be able to help. I'm still learning though, and I'm sort of stressed from a family emergency right now so I can't reliably work on anything. (Probably going to be at least a few more months.) Update: the family emergency is about as resolved as it will be for now. (My Father in Law has late stage liver disease). I can certainly help with config file editing if you get a list of changes needed up on GitHub I can get started. However, I can't guarantee that there won't be any interruptions in my work.

If you need a tester, I'm glad to ruin my save files for you.

Could we get a suborbital node on them. Obviously this means a suborbital arch that has an apoapsis high enough for orbit entry? This would make stage planning easier. (Ascent burn requires higher TWR than circularization burn.)

Is there a way you could get a read-only mode backup server running during the maintenance cycle this time? It would be very nice to be able to read the forums even if you can't reply. After all, many of us fetch certain references from the forums like the community list of mods. p.s. if not this time, could you see about doing it next time there is a maintenance/upgrade cycle?