vasya pupkin
Members-
Posts
12 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by vasya pupkin
-
Do we really need game modes?
vasya pupkin replied to Vanamonde's topic in KSP1 Suggestions & Development Discussion
yes, i do need. all of them. -
Besides the obvious part, that IRL a scientific research is even more repetitive and boring, there is another consideration IMHO. Rephrasing what authors of the game said more than once - this is not a game about research of science (in this case, and there are others), but about launching a rockets. Whatever authors/developers decide to incorporate into KSP, IMHO, they always keep this in mind. The more complicated some additional content, the more this draws attention away from the main theme. So authors took a decision to enhance a gaming experience by adding a science concept, and made this change as simple basic ability. Just to an extent of keeping it from overshadowing the main theme. Here is an additional example of similar suggestion, which was brought to attention previously: Repetition isn't necessarily tedious, but science is. Why, and what should we do?
- 20 replies
-
- 1
-
Different music for each celestial body
vasya pupkin replied to juvilado's topic in KSP1 Suggestions & Development Discussion
Yes. Very yes. But not limited to topic-starter's suggestion. I say - KSP soundtrack! For example: as far as i can tell, a huge amount of my game situations completely fall into the Hans Zimmer's - No Time For Caution (Interstellar Soundtrack). Sometimes fine and tight like instrumental version. Sometimes epic and intense like organ version. And so on. Furthermore, KSP can be enriched by unique whether AAA or indie soundtrack of its own. Gave this suggestion 5 stars. -
Great update. Add fuel transition section to the KSPedia. And add the Borderless window mode (otherwise it displays a window title and partially hides the bottom side of game).
-
Let's give SQUAD our point of view.
vasya pupkin replied to tntristan12's topic in KSP1 Suggestions & Development Discussion
- i'll oppose that your opinion. Although i am a newbie in this game, i am already realized that KSP perhaps had never made it to current state of development had it not provided such good and flexible mechanism for making add-ons. IMHO, so many add-ons drew to the game so much attention of general public of players that it made possible further continuation (and not the least from the financial point of view) of KSP. In the mood of old russian saying which i put on title of my reply: IMHO all the improvements to the game might had been not possible not because squad developers are unable to master them, but because to develop, test and implement all possible ideas, that already done by 3rd parties, entire lifetime of limited number of squad team wont be enough. As for me, squad might just buy the code of desired ad-ons into official KSP just to save their and our time (though they don't have to). -
- And before "science" points, people probably were bored by "the only challenge is to get to another planet". All the adaptive changes require a lot of work and customization. So developers added this unified approach which might not be the best, but it works. Personally, i think (and i completely possible may be wrong) it is more laying in the field of compatibility with chosen philosophy of add-ons. And if radical change of research system will demand from 3rd side developers to complicate their add-ons, they might just give up on these. If so, from the point of view of squad team, it might be concluded to a challenging question: whether or not to throw away enormous number of hours spent by vast number of people? And if so, the answer might be obvious. Again, as to your a suggestion, i think it brings a reasonable points, and partial automation gives a start to think about. If at all.
-
- As i wrote, IMHO, because of inevitable choice of keep/lab/transmit. All you can shortcut in these circumstances (if not changing science system entirely - that i wont address since that thing beyond the scope of this thread) is an automation of actual click on report button, but this brings additional questions of automating the research itself (like whether and how if yes).
-
Hello, i'd like to address some of your points (and you definitely made some reasonable ones). When you write: - in the same theme it sounds a bit mutually controversial. Because when you landing on another planet you're actually "repetitively drive laps around a track", and the change you're making is in, hopefully, learning about making it to "that far". The difference in approach pops-up when one compare progress towards final results. In same racing games with each passed lap you'll approach to the finish and eventually end of a game, because these games concentrated more on sportive aspects which are particular case of competitive spirit in general, what demand results (and like other arcades are). Þn the other hand games which are true simulators of something, like flight simulators or spaceflight simulators like KSP, do not have an explicit finishing point just because their main experience lay less in achievement of something than in emulating experience itself. People stop playing simulators when they had enough and play again when they want repeat that experience. While, as i wrote, there's a bit of contrariety, the main theme make a reasonable point regarding work with reports and search for science experience. In the same RTS games, experience usually acquired automatically, from time to time "bothering" a player by just a pop-up notifications of collecting. It sounds good until you recall that you have to choice between keep/lab/transmit; sometimes you know that you'll not bring that back and transmit data before your probe will be destroyed; sometimes you run out of electricity and cannot transmit anything so you keep your results in hope of bringing them back. IMHO, all these decisions can't be made automatically. But simple automation (doubt if it is actually simple) of the actual search for biomes and bringing-up the report windows indeed might be found useful (IMHO of course). Though it might be also good idea to make such automation switchable (on/off) in case one want to concentrate on flight mission itself. - Mapping planets in general, and making some map of locations (probably interactive) sounds very constructive (towards fun) idea.
-
- No, it is not what i tried to say. I literally meant new separate attachable part. Although i never thought about EVA suit in upgradable direction, i think it is interesting idea too. Though imho EVA pack in tech tree might be much more complicated and less obvious than simple attachable "button" and raising more questions beyond the scope of halyard (like - "what besides suit and halyard a complete EVA pack should include?" or "how i attach it and to what?"). - That is exactly how i understand a definition of innovative ways of exploring
-
- let's say this idea in its own right deserves another researchable stage in tech tree.Looks like (besides me) you're the only who think that this is a good idea, at least to the extent of stating it explicitly in this thread. Not to speak that this thread seem unlikely to become So you might consider using Rate This Thread tool as the only given alternative to inflating meaningless discussion just to get noticed (like my reply).
-
You may call it "safety belt", "tether" or simply "rope", but here i'll refer to it as halyard. OK. I read these: Already Suggested List; What not to suggest?; official planned features list; A list of all the default parts in KSP - and searched the forum for safety belt, tether, halyard, and did not find a respective direct suggestion, so if any of them exist do whatever necessary. So i went on EVA trip during suborbital flight and somehow have been immediately torn away from command pod. Turn on EVA suit and fly to your spacecraft, one may immediately say, but i'm a newbie and did not know about this feature and worse - it wont help because kerbal flown away too fast and too far. I immediately thought about any kind of tether to secure kerbals in space. My suggestion is to add a halyard as attachable (clickable) part. Desired functionality may be added as new option into context menu of respective modules (like "EVA on halyard") and as context menu of attached halyard-part. I suggest that it might have 3 (or more) researchable stages: Simple rope to attach a kerbonaut to module before exit because this is the point of safety precautions, and may have an ability to attach kerbonaut to halyard after exiting. The halyard may visually appear and be animated in any way while not affecting anything; as long its length isn't reached the kerbonaut flies EVA suit in regular way like it's free and nothing was attached. When length was reached, halyard will momentarily look and act like a strut (and if i understand this math behind it, spacecraft and kerbonaut should get respective momentary impulse like impacting wall-surface perpendicular to vector of halyard, or sort of... something...). Anyway, as an amateur programmer i say with limited responsibility that it shouldn't be much harder than implementing a strut, which is already present. If EVA suit ran out of fuel, kerbonaut will hang on this halyard until winded/collided into spacecraft, or approached a spacecraft during maneuver (same if spacecraft has unmanned command module or another approaching spacecraft) or torn away by excessive force (if spacecraft maneuvered too roughly or during collision with another object - what may damage some parts). Same as 1, with clickable option to reel it back if EVA suit runs out of fuel. (Drum-like shape may visually be added.) Halyards of variable lengths may also be added. Same as 2, with fuel and electricity flow what enable "infinite" (depend on spacecraft's fuel) EVA capability and maybe future handheld electric tools. (Straightening Mechanism - aka anti-tangle - may be implemented; making the halyard look like strut by tensing it back and of course through this resistance drawing some power from EVA suit thus lowering its performance.) That's it. http://www.nasa.gov/images/content/235794main_GPN-2006-000025_full.jpg http://www.nasa.gov/centers/kennedy/images/content/182021main_Jennifer%20Astronauts%20training.jpg P.S.: Although halyard may be implemented (if at all) not as new attachable part, but as additional clickable function or item in context menu of respective modules, IMHO this way is less preferable 'cause it will have less functionality and fun. - If you think that this is a good idea, then Rate This Thread to make it notable.