-
Posts
310 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by dr.phees
-
The issue is, that wobble was in at all. They should not have started with a situation where they had to solve it. Wobbly rockets were the one big thing to solve to cure everything from bad performance with large craft to issues with landed craft. Sure, there were other issues, but simply the fact that they started with wobbly rockets made me loose all faith. I couldn't believe it when I saw it, but I knew KSP2 was doomed. They were doing graphics bling, not an engine update.
-
Marketing. Funny, how KSP 1 was made by a marketing company turning game dev and KSP 2 was made by a game dev studio turned marketing company.
- 75 replies
-
- 13
-
There is a brilliant addon for KSP 1, fleshing out the idea with mission ribbons/badges etc. I would have thought to find something like that in KSP 2...
-
Wheel "low gear" or other torque solutions
dr.phees replied to a topic in KSP2 Suggestions and Development Discussion
Why shouldn't I send a rock crawling rover to another planet if I want to? -
Control Contrails on a per-wing basis
dr.phees replied to mattihase's topic in KSP2 Suggestions and Development Discussion
Or simply make a small, "invisible" part, a contrail source, with a simple setting for minimum g-forces or similar. I would be perfectly happy with manually placed contrail sources. -
Please fix the bugs before adding more content
dr.phees replied to tuxkiller's topic in KSP2 Discussion
And that is where they are wrong in my opinion. Me playing and liking KSP 1 was the reason for 6 more sold copies that I gave to various kids of various ages of friends and family. And probably a couple more who bought it themselves. -
For me it is mainly a result of KSP 2 being art driven. Fleshing out all the planets, the large parts catalogue etc. before you know the core mechanics work seems unbelievably wrong to me. Having a "Testing" star system of a star, two planets with two moons each would have provided everything one needs for proper systems development. The biggest problem are the many many hours spent into the assets. It raises the bar to throw something over board and redevelop if it does not work. It feels, like KSP 2 is already trying to cope with a bad systems foundation, just as KSP 1 did all the time, but this time many people expected to first learn from KSP 1 and have a rock solid base with better physics (wheels for example) to build on. It was clear from KSP 1, that Unity's physics system was simply problematic - but KSP 2 uses it again. With the same bugs, again! That's also why the spaghetti rockets with the "struts" solution simply killed all my expectations - it is just the same process again, the same old bugs, this time with higher hardware demands. I say it again: A KSP 3 should start with systems. Small start, a star, a planet a moon, then work with the community on the systems, multiplayer etc. until it is rock solid, perfectly moddable and performant. Then widen the scope. Another thing that really disappointed me: Why play in the same setting as KSP 1? Same planets, same maps? Why did no one have the idea to have a new setting/background story? My idea was that of a stranded Kerbal Mission in another Star system - the first Kerbals having left Kerbol system. Now they must develop technology and a civilization, starting from some data and basically mission scraps, to get home - a great reason for interstellar travel and possibly the absence of money. That is a pretty standard sequel-setting, but so much more imaginative than the current - Let's do it all again. And it could also have been a tutorial setting, being stranded on a small and resource poor moon, having to get down the potential well to the planet would have been a great setup for beginners. To me it seems all thoughts went into art, none into story, and only a few into systems, but too late. Edit: I think that much frustration is a result from that weird decision to basically turn back the game calendar and clock to the exact same start setting of KSP 1, which makes KSP 2 not a second KSP game, but a remake. A remake must have to be better than the original to be a success. A second game can do things differently. Now they are locked into remake mode, not finding a way out of it. (They can have my idea of the stranded mission and turn back the EA release to build from there, but only if they really start systems first ) They could have sold a limited KSP 2 with a small test star system at a lower price as the "Foundation" version, built on that and finally sold the KSP 2 full version again. I would have happily paid for both. But now they have to work with the money that came in with not a big chance to get much more. Bad decisions all around.
-
This forum was a community once, where people knew each other. Your kind of answer ("only say productive things") is just sad, and your "you won't be missed" is offensive as hell. I, for my part, do miss all the engaging and cool discussions in this forum, and I miss many of the older gang, who seemingly have gone silent over the new Kids on the block. And, yes, I like to hear from people leaving. Not that I like it, but I want to know. There are KSP 1 veterans here, that are much more interesting than you. Next time, save your sarcasm, it won't be missed.
-
My Kerbals are preparing to have a firework ready on every planet with a surface. They will be fired in queue from outer planets to inner planets, each a bigger explosion for new year celebrations. Sadly I have already stranded two teams without a way to return, but, hey, the show must go on. And they seem to be quite happy with that. Who knows, maybe some rescue mission will swing by one day. I have no pictures yet, but I hopefully will remember to take screenshots of the fireworks...
-
You can type the _e variant to replace an umlaut (ä/ö/Ü) and ss or sz for ß. But you pretty much never see that in german texts, pretty much only where input devices or fonts limit you to non-umlaut characters. I have not heard of any spelling reform with the goal to remove umlaute. There were some suggestions over the years, the last is from 2001, I think, but I have not heard of any reform being actively pursued. But maybe I'm wrong.
-
Why has the UI to be so ugly?
dr.phees replied to tomkpunkt's topic in KSP2 Suggestions and Development Discussion
One wonders what has happened. Did they at some point loose their code and had to get it working in a hurry? Those pictures look positively awesome compared to the current UI. Whoever made the decision to abandon that theme should take a step back, look at it again and hopefully understand it was a bad decision. Revert and move on would be a good way to go. -
The science implementation, compared to interstellar, colonies etc. is the easy one. I completely expect the other milestones to take much longer.
-
Throttle "Blipping"
dr.phees replied to Brandog's topic in KSP2 Suggestions and Development Discussion
I wasn't even aware that was a thing!! Thanks! (And now I also hope for this feature to find its way into KSP 2) -
Wobbly Rockets with David 'Trigger' Tregoning - KSP2 Dev Chat
dr.phees replied to Intercept Games's topic in Dev Chats
That's where the huge parts catalogue bites the development. It is beyond me, why they didn't start with a smaller catalog while implementing systems and only flesh out the parts list when ready. Starting with design before systems is a very weird decision. -
There should be one part that adapts to what it is being connected to: Attach it to one part and have it adjust to its form factor, then attach the other part and have it adjust as well. One slider would allow us to set a length (could be stepwise). This would cut down on the part catalogue's count and would be much easier to use. If you want to override the automatic selection, you could always manually set the form factor. As an alternative, this part could be made with one fixed form factor, the other side would auto-select. This would still cut down on the part count.
-
I posted this before, but I think it is more fitting in this thread. I have a suggestion, to make money really working and better than pure resources limitations - it would work well together with that and, most important, it would remove grinding. I always thought it would be nice to be able to play these missions if you wanted, but not to gather money for further playing. A good way would be for specific mission types to act as proof-of-concept milestones for other such contracts. You could decide to set each unlocked mission type to "automatic" and it would unlock that level of cost for later rockets, in the sense of: You were able to run a profitable mission with a rocket that cost [this much], so we will fund any future rockets of that cost, no question asked. The idea behind this is, that we are the designers of new vehicles and try the new stuff. Someone else is running similar missions with the craft we provided without us having to know, producing these vehicles for profit and we only have to fund further development. One could even opt for some monthly income to our budget, but that might collide with fast-forwarding. I would be fine for money/earnings to just expand our mission cost envelope. Every mission type could have escalation steps: (rescue from Kerbin orbit, Mun orbit, Minmus, Eve...) Another way to expand your budget could be to set a mission type, that you would be willing to do: Landing & return operation on Eve would give you a couple of generated missions: A rescue mission, a sample return mission etc., while orbital mapping operations on gas giants would give you exactly that. Maybe including some high-profit/high-risk mission like a low orbit mapping while within a planet's athmosphere or very low down, pushing you into dipping into a gas giant's athmosphere if just for a very short moment, etc. So, to make it short: You have a vehicle budget and you play missions to expand that budget. If your mission is successful, your approved budget is raised. If you mission is profitable, your budget is raised even more. From then on you may repeat that kind of mission to get more profitable in that mission profile/type. You can simply browse mission by type and set them to not bother you anymore. Why? It removes grinding, but still incentivizes you for profitable missions and cost saving. And it adds a new thing: Competing with yourself for more profitable mission setups. Why at all? Not having money/budget in a Space Program game simply does not make sense! Budget makes you go for efficiency, which can be a very driving factor behind designing good ships. Just slapping many tanks on and adding power is boring once you can build huge rockets. Science and budget are the way to go, but not in KSP1 style.
-
End game content?
dr.phees replied to CiberX15's topic in KSP2 Suggestions and Development Discussion
That also works with my suggestion, but you would still have to push the budget envelope from time to time. There might be a way to finish enough missions / milestone missions to unlock an unlimited budget for your personal endgame. I really think that resource gathering, especially with the mentioned automation in mind, is a poor idea in a game with time-warp. The budget way would be much more game-play fitting, in my mind. -
End game content?
dr.phees replied to CiberX15's topic in KSP2 Suggestions and Development Discussion
Sure. But such limitations would only lead to grinding. My expandable budget idea would allow proper progress. While you could do that with fuel availability, or any other resource (but it would probably feel a bit ham-fisted), you still would have the situation, that at some point you will simply be swimming in resources. My budgetary approach would still give you limitations that will force you to properly design vehicles. -
End game content?
dr.phees replied to CiberX15's topic in KSP2 Suggestions and Development Discussion
I always thought it would be nice to be able to play these missions if you wanted, but not to gather money for further playing. A good way would be for specific mission types to act as proof-of-concept milestones for other such contracts. You could decide to set each unlocked mission type to "automatic" and it would unlock that level of cost for later rockets, in the sense of: You were able to run a profitable mission with a rocket that cost [this much], so we will fund any future rockets of that cost, no question asked. The idea behind this is, that we are the designers of new vehicles and try the new stuff. Someone else is running similar missions with the craft we provided without us having to know, producing these vehicles for profit and we only have to fund further development. One could even opt for some monthly income to our budget, but that might collide with fast-forwarding. I would be fine for money/earnings to just expand our mission cost envelope. Every mission type could have escalation steps: (rescue from Kerbin orbit, Mun orbit, Minmus, Eve...) Another way to expand your budget could be to set a mission type, that you would be willing to do: Landing & return operation on Eve would give you a couple of generated missions: A rescue mission, a sample return mission etc., while orbital mapping operations on gas giants would give you exactly that. Maybe including some high-profit/high-risk mission like a low orbit mapping while within a planet's athmosphere or very low down, pushing you into dipping into a gas giant's athmosphere if just for a very short moment, etc. So, to make it short: You have a vehicle budget and you play missions to expand that budget. If your mission is successful, your approved budget is raised. If you mission is profitable, your budget is raised even more. From then on you may repeat that kind of mission to get more profitable in that mission profile/type. You can simply browse mission by type and set them to not bother you anymore. Why? It removes grinding, but still incentivizes you for profitable missions and cost saving. And it adds a new thing: Competing with yourself for more profitable mission setups. Why at all? Not having money/budget in a Space Program game simply does not make sense! Budget makes you go for efficiency, which can be a very driving factor behind designing good ships. Just slapping many tanks on and adding power is boring once you can build huge rockets. Science and budget are the way to go, but not in KSP1 style. -
Control Surface Rotation Speed
dr.phees replied to AngryBaer's topic in KSP2 Suggestions and Development Discussion
It is the old problem of KSP 1 again. If SAS is on, input should add/subtract an offset to or from the PID's target or a rotational target speed, not 'switch off' SAS until input stops. Alternatively SAS could work by shifting trim instead of simulating steering input. While steering input is received, SAS should stop adjusting trim until input is released. Both solutions would give us smooth steering. This had been discussed so unbelievably often with KSP 1 and should be very obvious.