Orionkermin

Now that I've had more time to think about it, if I enlarged it I would probably do a 0.625 top and 1.25 bottom node. The good thing about making it bigger is that there is potential to make an alternate "voskhod" version by using some creative model welding and an alternative IVA set up. Out of curiosity why do you feel the original doesn't work for Vostok missions using the parts in HGR? Just too small?

Well I have two different thoughts on the spud. 1: remake the pod and supporting parts in way that's similar to the way it's currently implemented. And branch it off into its own mini mod as it isn't really a 1.875m part set and is likely more fitting being on its own. 2: I could turn it into a 1.875m pod with 1.25 nodes. This is closer to the scale of actual Vostok and LK, but it might be strange having such a big pod only carry one Kerbal. This would be a big change and might upset a largish portion of the user base however. These are just my initial thoughts

I wonder if this means that the LV-N will have much more thrust in vacuum than it's current form.

Thanks, I'm glad you like them. I always felt the jump between 1.25m and 2.5m was too big and awkward for my taste. Now 1.25 feels a bit small for manned flight when I play. The Leek was still working correctly for me when I loaded it up with no other mods installed. So, I'm not sure what could be causing it sorry!

Any chance you're playing with remote tech? If so it might not be configured to work for that mod. Just a guess off the top of my head. I don't think that bigger engines should also be more efficient... That just incentivizes bigger rockets over smaller ones, look at how many people feel that KR-2L is overpowered. The engines should all work well with the diameter of tanks that they are designed to lift. What's the point of having a 1.875m engine for example if it's just better to use a 2.5m one instead? I think the balance should be that these engines are good at working with 1.875m tanks and less good at working with the other diameters than their own engines. (With a reasonably sized rocket of course)

Thanks. I knew it would be a little bit breaking to change the engine to a dual nozzle set up and while I feel bad about that I still think it was for the best. Engines like the the centaur's aren't something that is really seen out of realism mods, so it was more fun and interesting to work on. One thing to keep in mind too is that I'm making sure to keep the reboot compatible with the original version, so you could always just keep the old G90 as well if you wanted. Balance will be difficult. I'm hoping to find some kind of middle ground between the stock 1.25 and 2.5 engines. I'll be using KER to get some readouts to make sure things don't end up overpowered.

Finally got an engine in game. Sorry for the lack of updating recently, I've been a bit stumped with the engines lately and things kept not really coming out in a way I was happy with. Unfortunately, I'm going to have to drop the whole "optional" boatail idea. it just costs too much time from me and too much memory from the game. (Basically doubles the memory usage of engines) Really sorry guys, I did try a lot and it just sort of wasted a lot of time. At least they won't have fussy nodes and i can just concentrate on actually getting parts made and get this mod moving forward again. Anyways, this is the new-new G90. (Now the FG-90) It's based mostly on the centaur upper stage, and obviously is now a two nozzle engine. There's a couple more images in the album.

I'm certainly not against the idea. I am however, pretty unfamiliar with CTT's layout and balance. Maybe this will be something that gets added after the reboot is finished and I can look into it with the whole part range in mind. Or possibly a helpful community member will make one at some point. I'll make a note on it so I don't forget down the line.

Goodbye Rowsdower, you were a great community manager and you had the best avatar ever. So long Zap, we'll miss your hockeyhair and jean jackets.

Sorry I won't be able to anytime soon. Right now I don't have much free time to work on modding and what little I do get I need to devote to my primary mod. When my schedule opens up more I'll see about making them.

I can certainly see why you feel that way, the single adapter doesn't make it feel that way to me, but I do understand why it would to others. It's become a tough call and I think that no matter what there's going to be some members of the community that don't like it. I'm trying my best to find a way to make the most amount of people happy. There is an option that I don't think has been brought up and I might as well throw it out there. I could roll the Radish and into one thing. A 1.25m pod with a 1.25m-1.875m service module. Biggest issue is a cramped IVA and the pod would be somewhat tiny. The whole thing would still be made from scratch and would still use the new style of SM I plan to use. (Hollow, no fuel/engines/etc.) It's at least something else to consider, I guess.

I don't disagree with you here, but it isn't the only thing to consider. This works for FASA, because it is aiming to fit the stock part sizes. For a mod like HGR wich is trying to introduce an all new diameter, it feels weird that the first craft* would be essentially 2.5m. *craft as in the way the soyjuice lets you build something "like" a real life counterpart, but can be used however you want. I don't see why an adapter like the current one couldn't be used. That doesn't make the pod feel like it needs a whole new set of sized parts. To me it's more like the pod is a stopgap between two sizes and the adapter could be considered a part of the pod itself. People can already do what they want with the current Radish, I frequently use it with both 1.25 and 1.875 parts in the early career. I would definitely include an adapter similar to the current one, auto shrouds don't play well with FAR and reentry and don't take up any less memory anyway. It could even be designed to be flipped over and used to taper the SM down to 1.25 this time. Two sizes of SM is an interesting idea and might be possible, but I'd only pull the trigger on the larger size if It could be mapped to the same texture space as the "standard" one, because I don't want to do the texture work for two service modules and it would take up more memory. I'm mostly sure I could do it, but don't want to promise anything this early. Thanks for all the input so far everyone, I appreciate the brainstorming.

Ah ok, that's what I thought you were talking about. Don't forget that not all of big G was the reentry module, the rear section was planned as a cargo space. Example It would be something like: Radish(current size)>Big R crew module(1.875 at the large end)>1.875-2.5 interstage That would allow you to make a fair mock-up of big G in the 2.5m diameter and would even leave space for something like a docking port if you so choose. Would you mind linking your source for the diameters of the spacecraft? From what I've found both have an approximate diameter of 2.2m for their reentry modules. And Gemini's instrument module is about 3m at it's max(Base) with the soyuz service module has a max diameter of 2.7m. I know that doesn't debunk your point, I'm just trying to find the right values. That being said proportions are important to consider. If the radish has a 1.875m base then the service module has to go out to 2.5m, making it seem as wide as the Apollo analogue. (MK1-2) Compare the entirety of this spacecraft to that of the soyjuice and suddenly the Radish is looking huge, even if the widest point on Gemini was wider than Soyuz it isn't as big of a difference as I think that would make it seem. It also could make the nose seem too tiny as well although not by a huge margin and its hard to say before its modeled. Lastly it gives the impression that the Radish as a set of parts is actually intended to be a 2.5m spacecraft rather than a 1.875m one. Don't get me wrong, I see reasons why making it a more standardized size would be appealing too. I'm just glad this is being discussed before I start working on it.

I'm not 100% sure what you're asking. The way I see it for a big G type part the heatshield would be a seperate part. The way I'm envisioning it right now is that one end would be sized to the radish and the other to 1.875m so it would be an alternative adapter to the SM and would use a generic 1.875 heatshield if you want one.

Yes, it's been requested a lot so sure I'll make a big R this time. Might also make the little one man lander that was proposed for the gemin LOR mission, because I've always wanted it and hate direct ascent missions.

In layman terms yes, that is what you can call it. Much like 1.25 and 2.5 are often called size 1 and 2 respectfully. As the mod author I prefer to say the exact measurements, so there's no confusion. So far it seems that most people either don't care or prefer the original size. I'm somewhat surprised, as I had assumed people wouldn't like having it an awkward size. (Although I prefer the original size as well to be honest) Anyway, just did some rough sketches and I'm pretty sure that by using what is basically the same size for the pod, I can create an appropriate looking SM that would act as an adapter for 1.875m. (My plans for future SMs is that they are basically thematic cargobays/interstages) Then I could make a small 1.25m adapter/decoupler like the current one as a separate part. (Without the need for fiddly nodes) The 2.5m adapter would be dropped as it's sort of unneeded. I plan to actually make the top 0.625 size and add a more appropriate chute. The pod will stay at a two kerbal capacity.

Why not give scientists a unique experiment? Something like, "field studies" where he reports his professional observations. Maybe there is a way to make it limited use and higher levels get more times they can perform a "field study." I do agree that scientists need an active ability, but also that engineers and pilots could use passives. Likely in the form of additional recovery funds and reputation respectively.

So on the subject of the radish: A while back Gregrox Mun suggested increasing the base size to 1.875m. How does everyone feel about that sort of change? My only real concern at this point is that it may seem a little big compared to the soy-juice, especially since I want to make the soy-juice reentry module 1.875 in the future as well. Just curious on the comunity's thoughts.

What about a deep sea exploration game, where you build submarines? Similar enough in spirit to KSP, but a very new and different environment. It could still even be abbreviated as KSP, Kerbal Sub Program. Or KSP: terror from the deep

I don't think that will be a problem, I'll look into what goes into making them. Well no, what I mean is that I'm going to be remaking it so I'll miss the old version, since it was one of the first things I ever made.

Started working on the G-120. Still some refining to do and I have to make the aeroshell and frame. I think I'm going to go back to the drawing board with the G-90 remake. It wasn't quite how I wanted it and now that the other two engines will have optional aeroshells/boatails it seemed like it should get one as well.

I'm really excited to redo ALL the spacecraft! It will come in due time, I'm working on everything as much as time allows me to. For being my oldest part I think it's held up well though. It has a special meaning for me since it was my first ever mod. A little part of me will be sad to see the old radish retired, but it must happen. - - - Updated - - - I'm really excited to redo ALL the spacecraft! It will come in due time, I'm working on everything as much as time allows me to. For being my oldest part I think it's held up well though. It has a special meaning for me since it was my first ever mod. A little part of me will be sad to see the old radish retired, but it must happen.

I based the math from the H-800, since they are close enough to that height. (The difference could be assumed to be structural) I ended up with a final value of 108 liquid fuel and 132 oxidizer. These numbers burn off completely. The dry mass was also increased accordingly.

Thanks Pulsar. I've made the changes on my end, including bumping the dry mass by the correct amounts. It will be in next time I release an update.

I'm not sure if there is a way to tie RCS to the multiengine module. However you did give me an interesting idea. Unity lingo incoming: If I child an RCS transform to a ThrustTransform that has a gimbal applied to it, will that basically create a gimballed RCS? As long as the engine is active, even without throttle, it still gimbals around. So, the RCS transform should be getting rotated around as well. Might be something to look into, FOR SCIENCE!