-
Posts
279 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Tarmenius
-
-
I mean it's meant to only be used with one other part.
Ok, fair enough. Just bear in mind that even if it's meant for use with one other part, doesn't mean it's only possible use is with that other part. For the airlock, I think a bell shape (instead of the current cone) may still be suitable for re-entry and provide enough length to stow helmets. Thoughts?
-
We just dropping the discussion on inflatable airlocks? Ok then...
The problem with a special size of shield is you would need a pair of size adapter which would only have one use. Kit craft is a bad thing.
I think the inflatable airlock is a great idea, as long as the pod is made long enough for us to imagine that their helmets could be stored somewhere. As for the "one use" argument, any adapter has only one use: Adapting from one size to another. If you're referring to limited use, what about the antennas? They're only used for "one thing" (at the moment). A very necessary thing, of course, but it's still just one. Or how about solar panels? They only do "one thing." But perhaps I'm not understanding the nature of that argument. Feel free to explain if I've got it wrong.
-
The new mk1 plane parts cover most of these needs assuming the tech tree is balanced properly leaving just the need for a deep space reentry pod which is what the proposed 2.5m pod is for and again if the tree is balanced properly its diameter won't be an issue.
Sorry, allow me to clarify: What we're wanting is a command part which is a size category smaller than 2.5m and which can hold 2 Kerbals. I've been trying to keep up with the news but I may have missed something. Will the new Mk1 Cockpit seat 2 Kerbals? Or does the Mk1 Crew Cabin provide Reaction Wheel torque and allow the ship to be controlled? If either of those is a "yes" then the new plane parts definitely fill that need for me.
btw the mk2 landercan shouldn't be able to renter kerbin's atmosphere safely if it does it means squad screwed up.Add a heatshield and it should be perfectly capable of re-entry without breaking any kind of logical consistency. But that's a whole other discussion.
-
For me its either 2.5m pod or a whole set of new sized parts which is welcome rocket parts are always useful, but a 2.5m reentry pod is much a more practical suggestion.
What we're wanting is something which is a size category smaller than 2.5m and which can hold 2 Kerbals, so this suggestion doesn't address the issue. There's already a 2-Kerbal, 2.5m pod. It's the lander can. Whether that should be suitable for re-entry is another discussion entirely.
-
A slightly larger pod would do. 1 heatshield for it, and 2 decouplers that work as adaptors. 1 from 1.X to 1.25, and another from 1.X to 2.5.
I agree that this is probably the solution that stands the best chance of being implemented. Though personally, I'd prefer the 1.25m series be increased to 1.7 or 1.8m instead. Ever since EVA was introduced, I've always felt it was a little thin anyway.
-
If their helmets could be slimmed down a little (and maybe shortened slightly), they'd totally fit:
That's an overturned Mk1 Command Pod, by the way...
-
I think the "gap" people are referring to can be explained as follows:
1.25 +1.25 = 2.5 (+100%)
2.50 +1.25 = 3.75 (+50%)
So, the relationship between small and medium is greater than the relationship between medium and large. This difference creates the sense that there is some unused "space" in the scaling of parts. Apologies if I've misread.
As for the crew capacity issue, I would definitely love to see a 2-Kerbal pod in the smallest standard part size. Sadly, they just wouldn't fit within a 1.25m pod unless one was behind the other (maybe also slightly higher, as Kerbals are very short when seated?). Of course, SQUAD could just decide to do it anyway and leave us laughing about the way Kerbals magically shrink when they enter. That could be fun, too. Another alternative would be to change all 1.25m parts into something large enough to seat 2 helmeted Kerbals side-by-side (would 1.7m do it?). No need to add a whole new part category. I personally think three standard and 1 non-standard (0.625m) is a good balance.
-
I see day 233 Kerbin time, day 59 Earth time, are you adjusting to the earliest time or something?
Yeah, the earliest edge of the dark-blue area. I probably should have adjusted all of them similarly, but oh well... The windows are pretty wide anyway.
-
Remember that windows only represent times when the transfer can be done with minimal fuel costs, and as such they have no hard "start date" and "end date." But, according to the alexmoon launch window planner (linked above by mhoram), the order is as follows (in Kerbin time):
Duna: Year 1 Day 216
Moho: Year 1 Day 253
Dres: Year 1 Day 340
Eve: Year 2 Day 117
Jool: Year 2 Day 230
Eeloo: Year 2 Day 250
These "windows" usually last several days (in a couple cases more than a week), so launching on exactly the listed days isn't really necessary.
-
I recently made a first attempt at a small re-entry glider. Well, first attempt post-1.0 anyway. I brought it down from 100km in a descent path that was probably about 20 degrees or so during the upper atmosphere and at a fairly dramatic AoA. Almost "bounced" right back into space. Next time, I'll be taking a page from NASA's shuttle and performing S-turns instead.
-
So what? Most people don't think about delta-v in their daily lives either. Should KSP not model delta-v?
I wasn't actually defending instantaneous light. My only point was that the simplification is a low-cost design choice, unlike the choice to disable probes completely when they lose communication with Kerbin.
Personally, if they decided to make light (and therefore signals) travel the appropriate speed, I don't know how I'd feel about it. At interplanetary scales, light feels a lot slower than you might think. And now I'm curious... which mod models this?
-
I've played with exactly that behaviour from Antenna Range and found it good.
Ok, so maybe "unreasonable" was the wrong choice of words Still, I imagine that would frustrate more players than it would please. And while it's no more realistic than instant-light-travel, most people don't think about the speed of light in their daily lives (though many of us here do, I'm sure). So the fact that it's instantaneous likely doesn't even register to most players. That unrealistic "game simplification" is much less likely to be noticed in the first place than the fact that people's probes don't work at all sometimes.
Actually, the reason we announced this feature early was to give the community some time to mull it over, and to provide constructive feedback (a great deal of which has already been reincorporated into the design).Glad to hear that. I'm looking forward to the feature regardless, and it'll be interesting to see how you implement it.
-
From what I understand based on the article (and someone correct me if I'm wrong here), the Relay Network feature will affect 2 Game Systems: probe control and science transmission.
For probe control, I see only 3 ways to handle occlusion: 1) The player loses all control of the probe; 2) The player retains all control of the probe; 3) The player retains some control of the probe. #1 is unreasonable (and unrealistic), #2 means the feature will only affect 1 Game System, making #3 the likely solution. To implement this they could say attitude control is removed but throttle control remains (or vice versa), but that doesn't make much logical sense. So, the most reasonable solution seems to be some form of "programming" of the probe. Allowing it to execute maneuver nodes is likely the best way as tater most recently mentioned, and for the reasons he gave. But given that the current probe control mechanics limit which can be used for SAS functions, it could end up that only some probes can be "programmed" at all. If that's the case, I hope it's only the very early one or two probe cores which lack that functionality.
For science transmissions, the solution's probably obvious to anyone: No transmissions without line of sight to Kerbin or another probe which itself has line of sight to Kerbin.
What I am saying is that there are other ways to simulate partial control other than 'signal delay and a flight computer', simple as that.Care to elaborate on those other ways? I'm having a hard time imagining what they are.
-
Thank you Tarmenius! I wasn't aware of the bounty of examples available on the forum. I will be sure to search next time before I trouble anyone.
Glad I could help! And most people around here aren't troubled by even the most frequently asked questions, so don't even worry. At worst, someone might point you toward an answer and roll their eyes, but this is generally a very helpful place.
-
Turbojet SSTOs were definitely doable in 1.0.2. In fact, all you really needed was a single Whiplash: Take a look at these examples
They key is to build as much speed as you can through at 10-12km. The ascent profile looks pretty different from pre-1.0 techniques.
-
Like back in 0.9 I ran into a situation where a crewed vessel ran out of fuel while performing a burn to return from the Mun. Resulted in an periapsis that swung close by Kerbin, but didn't contact the atmosphere. Was playing with limited life support, so they were essentially doomed.
Wound up putting together a rescue mission that managed to intercept them while they swung past, transfer them to a fresh capsule, and then deorbit it, in what was probably one of the most epic experiences I've had in the game, and it's not an isolated incident either. I'd say that many of my best experiences in the game have resulted from running out of fuel due to my guestimates being off.
I have stories like this as well and remember them fondly, as you do. But mine only exist within Kerbin's SOI. When KSP had only Kerbin and Mun, the "trial-and-error" mentality totally worked well as a design choice. Even more so when there was no persistence: Flights never lasted longer than a single play session anyway, so simply ending a mission was common practice. But this is no longer the case. Ending a mission now destroys the crew, flights last through several play sessions and represent many more hours of player investment, and travelling beyond Kerbin's SOI involve more planning and effort despite the fact that a Mun-capable rocket can reach Duna.
So, from where I sit, the original plan of "figuring everything out yourself" really needed to be re-evaluated once the level of sophistication and scale grew beyond a certain point. I think the data SQUAD has which indicates most players don't leave Kerbin's SOI should have been the first hint that something wasn't working as they intended. A core game feature that goes largely unused highlights a major fault in design. One of those, in my view, is the lack of information and tools provided to the player caused specifically by the "trial-and-error" mentality.
Take a hypothetical mission to Vall for instance. Say it runs out of fuel in Jool orbit before getting an encounter with Vall. To mount a rescue mission, I have to re-design the craft, repeat the previous mission events and hope I tweaked it correctly. That's a lot of effort for potentially no reward. It's for similar reasons that classic-style western RPGs have the adage "Save early, save often." Nobody wants to just lose a few hours of advancement in the game, and so most players decide it's not worth the risk to leave Kerbin.
That a dv readout is coming to KSP at all is a great thing. And I can understand the choice to bind it to Kerbal skills, though I disagree with it. Hiding this kind of information behind "gates" is bad game design in my book. As a designer, you ask yourself "Do I want the player to have this item/information?" If the answer is "Yes," you give it to them. If the answer is "Yes, but the player must work for it," then the mechanic you design must be interesting enough for the player to enjoy "earning" it. Making players grind for something you want them to have anyway is no way to build an engaging experience.
-
"If anyone can guess what important event is coming up next week.. then you are.. probably very close to something."
The conjunction of Jupiter and Venus is supposed to occur on July 1, so perhaps Jool, Eve and Duna will be visible from Kerbin?
-
I've been following this thread from the beginning, and I think I may have a way to clarify what's being misunderstood here.
With the addition of new parts, the possibility space for craft design has been expanded (a wider range of part combinations exist). The possibility space for successful designs is much smaller, and the new aerodynamic and heating models have made it smaller still. This is good for people who favor Realism over Gameplay (when the choice needs to be made) because it more closely mimics our reality in that we must carefully design our spacecraft. However, consider that this extra time and effort is spent just to achieve the same goal as before: Getting to and from orbit. Increased effort for the same result is the very thing HarvestR was trying to avoid when he decided Kerbin should be much smaller than Earth.
Thus, the new systems have shifted KSP a bit toward the "Simulation" side (for lack of a better term) and for people who favor Gameplay over Realism, this is a negative change. So, Vanamonde's issue here (if I've been reading correctly), is a reflection of that shift. Hopefully there exists some solution that will reduce the time and effort aspect without sacrificing the Realism of the game's calculations. Honestly, I think this also highlights the fact that the physics simulations being run by the game are far more sophisticated than the tools available to the player. This is the game design fault I was referring to much earlier.
-
Looks like we may be missing a couple of buttons. Without a doubt, action groups would be ruined.
I'd say the way to tackle Action Groups would be a dialogue wheel: Hold a button, the game pauses and a wheel is displayed, divided into segments for the various Action Groups, or other common commands that don't need to be used immediately. Staging wouldn't be there, for example, but Toggle Solar Panels could.
-
Why would anyone expect a lander like that to reenter in one piece?
Why would anyone expect it to not be able to reenter in one piece? Sure we all know that reentry heating is a thing, but how is anyone supposed to know beforehand that their lander is going to flip over and potentially roast on return to Kerbin? With the current Science system, players are encouraged to bring back the instruments (and other parts, thanks to Recovery). Yet the aerodynamic and heating models make that difficult to accomplish and the game gives us no tools to predict that difficulty. The solution of "Move all Science to the pod and ditch the equipment before reentry" is not something a first-time-to-the-Mun player is likely to think of naturally and they won't realize their mistake until it's too late. I think this highlights a fault in game design and Vanamonde is right to point it out.
Sadly, I don't have any good solutions. As I see it, either include some tools for the player to make sense of the atmosphere and heating models, or simplify the models themselves. Both would require significant amounts of work and each would displease a segment of the playerbase.
-
is it a new bug or feature that closing air intakes no longer changes their drag value ?! I don't understand how an Intake can generate so much drag anyway, its streamlining most of the air through to the engine so where does it pile up ?!
From what I understand, it piles up in the engine itself. Or, it would in real life; I doubt it's actually modeled that way in KSP. Come to think of it, closing the intakes should probably generate more drag as you could imagine the air entering the intake only to hit a flat surface inside.
-
New entry... clocking in at a whopping 45.6 tons wet on the runway. Orbits at at 25.1 tons. Landed safely at just under 25 (burned off 100 units of fuel to deorbit and final approach).
Astonishing is definitely the word for this! Way to go Falconer!
-
redsh: Very cool high-wing design! I especially like those LV-909 pods underneath.
---
This talk of turbojet boosters has given me another idea...
-
If you change 1 FLT200 tank for 2x FLT 100 (because of the smaller units in which you can lower the fuel) you can drop 5 units of L+O ...
Very clever! I never thought to subdivide the tanks to get more precise control over fuel amounts. Also, from what I understand (someone feel free to correct me) the Shock Cone generates less drag so you could probably squeeze a little more dv out of the design that way.
Devnote Tuesday: New Format!
in KSP1 The Daily Kerbal
Posted
How much of that news got "consolidated" into this article? I feel like there was some stuff left out
---
Since there's a new format for the DevNotes and we're all providing feedback, I feel it's a good time to say I miss these. When I first discovered KSP (Dec 2011), it was these blogs that really set SQUAD apart from other developers. It kept us informed, which meant there was a lot less speculation and a lot less room for misinterpretation. Sure, it probably impacted HarvestR's productivity, but I believe it was more than made up for in the relationship it fostered between SQUAD and the players. Plus, it seemed as though he genuinely enjoyed sharing. And as an indie developer, shouldn't that be more important anyway? If there's anything to be learned from the development of KSP, it's that open communication is vital to preserving a positive atmosphere in the playerbase. It's my opinion that the instances of community backlash against SQUAD for various actions is directly related to the disappearance of these kind of blogs and the openness they brought with them. And while I understand the fear of similar backlashes in the future, withholding communication in the way we've seen over the past 2 years is only making those fears a reality.
Another key point is that those blogs were usually featuring work and systems which were already done (or mostly done) and the hurdles which had been overcome. Since then, that fear I mentioned has driven a more defensive communication style "Here's what we're planning," instead of "Here's what we've done." But while prefacing everything with "Things can change in any way at any time" is good CYA, it means that anything that follows won't actually tell us anything reliable (the source of speculation) and excessively qualifying every statement only comes from a place of fear and weakness. As game developers who want to interact with their players, you must grow some really think skin. Harsh criticism will come, regardless of how well you communicated. That's one price of being in this industry. So, since you're already making changes to the way you communicate anyway, consider keeping us in the loop about what's actually been done in a given time frame going forward. It doesn't even have to be weekly, really. Remember, we can't get outraged at things that are already done when we had no idea what the original, nebulous idea had been in the first place.