Station Core: General Feedback #343
Comments
|
I just built a station in career mode. A soyuz, with a HAB-A1. It was the simplest station contract. Must hold 5 kerbals, have a docking port, antenna, and can generate power. Inflated hab, bumping me well above 5 crew. Everything turned green, except the docking port, antenna, and power. I added a stock HGA, still didn't satisfy. I checked the known issues and todo list, didn't see this. I've been looking at "balance" issues, as well. |
|
It's the solar panels on the Soyuz SM. |
|
Noted, and fixed. Those panels (and the ones on the LC-POD parts) should now fulfill 'generates electricity' contract requirments. |
|
I posted this in the forum as well, but a version of the COS-XS (or perhaps just the one that is already made) with a bunch of windows forming a sort of cupola would be incredibly nice to have. The shape remains identical, it is not a copy of the real ISS version, but the windows (paned, with wide mullions) would wrap enough around the curve of the shape to give a wide field of view in multiple directions (if it had an IVA). This would allow SSTU stations to complete many of the career contracts that require a cupola part---and the stock cupola is... awful. Since the part is fixed geometry, it's not the nightmare of adding windows to inflatables, right? The COS-Cross texture could replace a number of Xs with windows. The handrails would need to go away in the window areas. The current model is divided into 4 sections of 2x4 cross panels, I'd suggest one such section on each side as windows. Ideally, there would be an adapter part that would match, like the 2:1 Flat but with a few matching windows on the 2 sides with windows---it would have 2-3 windows like the X pattern basically. This adapter would also allow any COS (or other) part to be used by players as the "control" segment of a ship, visually. |
|
I was messing with small inflatables as munar bases (Messing with a Blue Origin type cargo lander), and I found myself wishing that the Bigelow-like inflatables had the airlock option as the COS parts do for top/bottom since they would be deployed on their sides for that application. |
|
I'll see what I can do, but those adapters will only work for 2.5m parts -- so something new would have to be created for the other sizes of inflatables. |
|
Ah. I suppose it could just be for the 2.5m versions. Just looked nice, I thought. This is the little test without the airlock(s). There is a near future hub in the middle. The whole thing can fit inside a fairing just larger than 7m (New Glenn size). Quick and dirty, not actually scaled to kerbals.
|
|
On that note -- I've been contemplating if I should add an adapter for the HABs that includes animated landing struts (rigid, not using spring/suspension mechanics). Either way likely at least a few weeks out on any of it. Still knee-deep in wheel stuff, and trying to get the RD-180 engine (and derivatives) in-game. |
|
If you get your horizontal landing stuff working... the already built inflatables are clearly a no-brainer to have instant landed bases (and Bigelow even has the cool diorama to sell them ;) ). The adapter idea sounds pretty cool. It might also include an airlock and stairs: |
|
The CFG parts misspell accommodations in the part description. I would suggest adding "for XX crew." to the end of the description as well, for all inflatables (the Bigelow types don't have too much in the way of description, though). (typo fixed and added content shown) |
|
I know this should have been said perhaps earlier, but the hub parts in typical tech tree nonsense are sort of screwy, though this is the fault of the STOCK game. You have them exactly where stock has them, but really they should either be earlier, or all the station parts should have those adaptors like the solar panels and unavailable. Odd that I can make a hub with parts, but can't use the single part option (if that makes any sense). The joy of a "career" game that the devs never really gave much thought to... |
|
Thanks for the feedback -- yeah, definitely need to take a pass over the HAB part descriptions. Tech balance -- indeed, I'm about done dealing with the stock career 'balance'. Might be making a 'complete conversion' tech tree overhaul... but unsure if I feel like putting in that much effort, or just moving onto something else (as I'm 90% certain that the KSP devs are never going to fix career mode or make it moddable). |
|
I could try again to do it on here, but when I tried a branch before I was sort of clueless and didn’t figure it out.
I might try again and edit stuff that is just text.
… On Mar 16, 2017, at 9:03 AM, shadowmage45 ***@***.***> wrote:
Thanks for the feedback -- yeah, definitely need to take a pass over the HAB part descriptions.
Tech balance -- indeed, I'm about done dealing with the stock career 'balance'. Might be making a 'complete conversion' tech tree overhaul... but unsure if I feel like putting in that much effort, or just moving onto something else (as I'm 90% certain that the KSP devs are never going to fix career mode or make it moddable).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#343 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARIoq0rf4vWypxCY6XJ_DaIwjKluCFtrks5rmU8ogaJpZM4JZryg>.
|
|
Don't worry yourself about it -- I can get the description stuff cleaned up easily enough. The tech tree though -- not even sure where to start, or if I want to get into it at all. Obviously I can/could move around some of the SSTU parts, but as you point out, they are inconsistent with the stock part placement in quite a few aspects (solar panels on SC-A, adapter types for StationCore, fuel cell on SC-B, several other misc parts/features as well). |
|
Yeah, it's really tough. On option is to go "quality of life" and just ignore stock parts. Other than a few things completely missing/out of scope for SSTU, I never use any, frankly. So it might be easier to put them where you want in the tree, and delete the stock parts, lol. Who would use the stock "hub" part when the SSTU part is available? Any masochists out there? Maybe a "tank" that is an APU could be a thing (they exist already for Apollo SMs), and have it early in the tree? |
|
Have updated the descriptions on all of the HAB and CFG modules to fix typos and include crew capacity. |
|
The ST-GEN-WDP has given me a few odd issues. It occurred to me, that I could assign 2 WDPs in the VAB as part of a stack, then retract and arm them, then weld them on orbit (reducing part count once there, without having to dock, etc). If not under a fairing, I could do it on the pad, actually. It usually works, but a few times I have set it (in this case to 2.5m) in the VAB, and when I go looking for them on orbit, they have reverted to default diameter, and are invisible to click. I then adjust the camera, and zoom inside, and still can weld them with some effort. Sorry the bug report is vague, but it is not predictable to reproduce, I'll try some more for you. Also, does the diameter matter? Meaning that when I zoom to the default 1.25m versions inside the craft, by all accounts they seem to weld, they welded regardless of the size, right? (in which case for an intermittent issue it's not a big deal). |
|
Wait! I might have found how to reproduce the issue! Place an Apollo capsule. I then attached a 2.5m SSTU tank. Then the 2 welding ports (directionally appropriate), then I added another 2.5m SSTU tank. Launch. Revert to VAB. Welding ports seem gone, but have in fact reverted to 1.25m diameter. I think last time I did this, and saw them disappear, I had launched (under a fairing) a craft that was supposed to include a tourist, got it to orbit, then realized that I forgot to change the crew so the tourist was aboard. So I reverted to add the right crew, and relaunched to find the welding stuff apparently gone. |
|
Diameter doesn't matter -- its just a visual effect so that you don't have to zoom into the part. Model errors with revert-to-VAB -- uhh..yeah...awesome. Love that stock code. Will look into it though. Edit: Thanks for providing reproduction steps, should let me at least figure out what is going on with it. |
|
This is utterly outside of the scope/point of the welding part---I think---but is it possible to weld parts in the VAB? Typically the most part-intensive time of a given craft is launch, given that as the launch progresses, you stage away parts, paring the craft down. I have in more than a few instances placed a part, then the 2 welding parts, then the next part, then 2 welding parts, etc, then welded them as soon as I can on orbit (or even on the pad if possible). Usually this is stations, or interplanetary craft. Just spitballing ideas. |
|
For the first part of your question -- No. The closest you can come is Ubiozor welding, but even then it requires that you first weld the parts (which creates a new part definition with MODEL nodes for the models on the original parts), reload the game (to reload that newly created model definiton), and then finally you can use that -new part- as a 'welded part'. It has all sorts of technical limitations caused by the stock modules.... which is the reason I started SSTU in the first place (the inability to weld, for example, multiple solar panels into a single part). For the second part of your question -- The welding docking ports don't combine the two parent parts into one, they merely remove themselves and join those two parent parts to each other using standard stock attach nodes and joints. So you are not saving any part count by doing that, and only increasing your building time and effort. Welding ports are intended to be used for orbital construction as an alternative to using regular docking ports in situations where the port would be docked only a single time and then permanently left docked; in those cases you can use welding docking ports and save yourself two parts on the finished craft. |
|
Oh, that was a fundamental misunderstanding on my part then. Is the joint stronger than wobbly docking joint?
…Sent from my iPhone
On Mar 30, 2017, at 2:55 PM, shadowmage45 ***@***.***> wrote:
For the first part of your question -- No. The closest you can come is Ubiozor welding, but even then it requires that you first weld the parts (which creates a new part definition with MODEL nodes for the models on the original parts), reload the game (to reload that newly created model definiton), and then finally you can use that -new part- as a 'welded part'. It has all sorts of technical limitations caused by the stock modules.... which is the reason I started SSTU in the first place (the inability to weld, for example, multiple solar panels into a single part).
For the second part of your question -- The welding docking ports don't combine the two parent parts into one, they merely remove themselves and join those two parent parts to each other using standard stock attach nodes and joints. So you are not saving any part count by doing that, and only increasing your building time and effort.
Welding ports are intended to be used for orbital construction as an alternative to using regular docking ports in situations where the port would be docked only a single time and then permanently left docked; in those cases you can use welding docking ports and save yourself two parts on the finished craft.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
The joint should be as strong as if the two newly-joined parts were joined up in the editor originally. So, for most uses, yes, the joint will be stronger than the docking port joints. However if the two joined parts do not have much mass, they might be even more wobbly than the docking port joint. Joint strength seems to rely on the mass of the part, so more massive parts will have stronger joints; as most parts have more mass than a docking port, most part-part joints will be stronger than port-port joints. Basically, it allows you to design a super-massive craft in the editor, break it into sections each joined by welding docking ports, and then launch each of those sections on individual launchers. Once in orbit, they can be re-joined into the original craft, just as if it had been built and launched as a single craft. |
Station Crew capacity, balance, etc...
I think it needs a little tweaking, though it very much depends upon life support assumptions in some sense. Below the capacities, plus images (I did not include the versions with RCS, etc for space).
COS-XS: 2 crew
COS - S: 2 crew
COS- M: 4 crew
Hitchhik: 4 crew
HAB-A1: 4 crew
2-4 crew image:
2-4crew.png
The COS-M is a real outlier here, unless it has decently higher LS capability (habitation and supplies, etc). The XS, should then have shorter duration LS capability in LS mods. Also, the COS-S is as big as HH or HAB-A, but has half the crew. I think this needs some real tweaking. XS=1? HAB-A = 2, COS-S = 3, HH = 4 and COS-M = 5?
CFG - A: 6 crew
HAB-A2: 6 crew
COS - L: 6 crew
HAB-B1: 6 crew
HAB-B3: 6 crew
6crew.png
This is where it gets more pronounced, IMO. CFG-A need loads of long term capability out of the box to make sense (which is fine). HAB-A2, OTOH, is just grossly smaller. I might be inclined to bump it down to 5 crew. It's actually about the size of COS-M, so maybe HAB-A2 and COS-M go to 5 crew (with the COS having slightly better LS stats)? Then the problem becomes the COS-L. It's substantially smaller than the HAB-b1/3 parts, and the torus. To scale the CFG-A is just like the centrifuge inside Discovery from 2001, so I like the lower crew, better stats there. I might be inclined to keep the COS-L at 6, and bump the HAB-B1/3 to 7 or 8 (it looks to be on the order of 7-8 times the volume of the stock hitchhiker, and is considerably lighter---3.45 tons inflated vs as much as 20t for 8 HH).
HAB-B2: 9 crew
HAB-B4: 9 crew
(no pic)
CFG - B: 12 crew
HAB-C1: 12 crew
HAB-C3: 12 crew
12crew.png
Reasonable, with the torus getting a huge LS bump. Frankly I'd like to see the CFG vs HAB different, just to be different, lol. Maybe 13 or 14 for the CFG-B?
CFG - C: 18 crew
HAB-C2: 18 crew
HAB-C4: 18 crew
(no pic)
CFG - D: 24 crew
(no pic)
My gut says for gameplay balance, it might be nice to have the COS-L in fact be 7 crew and the COS-M with 5 crew. It gives a wider array of capacities with one unit---2, 4, 5, 6, 7, 8, 9, 12.etc. I also might consider bumping up the tori by even just 1-2 crew to make them different than the larger inflatables that currently have the same capacity. Even though there is no need for larger crew, I'd still likely bump the CFG-D higher (largely to distinguish it more from a couple of smaller inflatables---it's the same as just 2 HAB-C3s!). Note also that a CFG-D is 158 tons, vs 15t for the same crew with 2*HAB-C3. 10 times the mass, same crew. It needn't go 1:1 on crew/ton, but that torus can easily hold 50. I get the lower numbers because we don't need high numbers... but just to make them seem as big as they really are is worth something (the CFG-D is magnificently huge!).
This would alter the following:
(COS-XS: 1) (or keep it 2, but with very little LS)
HAB-A: 2
COS-S: 3
COS-M: 5
HAB-A2: 5
HAB-B1/3: 7
Possibly bump the CFG-B/C by 2/4, respectively, and the CFG-D to 30 or more.
The crew per ton (fitted out) of the parts is fairly consistent at about 1.3-1.7 crew per ton. The outliers are COS-HAB-S at about 1/2 that, and the HAB-A1/2 parts that are about 3.75 crew per ton. I like the idea of the A1 in particular needing few (or NO) rocket parts, but then the crew space should be more limited, I think (think if it like a more capable BEAM). The A2 should have the fitted out mass increased, I think---maybe to 2-3 tons, with 5 crew (but lower stats than COS units). The other outliers are all the tori. They go from 0.48 crew/ton, to 0.15. That's 3-10X fewer crew per ton than the rest of the parts.
More capability is obviously required (LS supplies, and modifiers to make them terrific in other words), but even than, possibly more crew. The C and D could double their respective crews and still be in the range of the 2 smaller tori, which would still be 3-5 times fewer crew per unit mass than the other parts.
The text was updated successfully, but these errors were encountered: