Kegereneku

Members
  • Content Count

    694
  • Joined

  • Last visited

Community Reputation

161 Excellent

About Kegereneku

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Back and reporting for duty (maybe). I'm going to update KSP for the latest version of your mods right away, can't promise I'll have as much time to stress test it, but I'll be damned if I don't comment like an armchair developer. Btw, the link you just poster is not accessible to me, I don't know what new feature it is from the forum, maybe you need to be a mods developers or something? I'm pretty sure my anti-script isn't blocking it.
  2. Novel opinions : Playing Without Mechjeb is cheating. Dead serious here, real rockets were never flown by hands except in rare & exceptional conditions, everything was programmed even before the invention of the transistor and will always be. The future of Astronautic is pre-programmed interface for their users, far better than pitiful hum...kerbal skills. Seriously... everybody play how he want. This is not a competitive game.
  3. When its launch tower double as a space Elevator.
  4. Let's bump this, we've been waiting for too long. Also, when do we get that damned Kerbal-Engineer dV-per-stage-reader ? When you have a Node Maneuver system which give maneuvers-cost in m/s the first question that come is "how much do I have left ?" and it is a critical tools to learn the distinction between high-thrust and high Impulse.
  5. That's..... a tweak which should be suggested (moving the topic) in the suggestion forum. That's a very good idea. I wish we just had as many tweakable that we hoped for.
  6. Then there's no more reason to pick on what I said about "maintaining thrust" (which is as correct as "not loosing thrust"). It's been a while since I last played, but I remember the Aerospike as not particularly different/efficient in comparison to other engine, at least not enough to use them for a light SSTO/reusable SSTO. Doesn't help that there is only one size available and that engine-clusters lose in efficiency. You also have to balance them/balance the jet-engine to not overshadow it on Kerbin.
  7. I'm not misunderstanding really, having a Specific Impulse as high as possible is so obvious that it is meaningless to mention, you wouldn't even bother to compare a classic Bell nozzle to an aerospike if it didn't have any use. In terms of game-design the Isp would be the specs you change to balance the Aerospike, after making its dynamic correct toward other engines. What you want to compare is whether you can use one aerospike for an atmospheric ascent rather than 2/3 specialized engine. But for that the other engine must not act like Aerospike themselves. NothingSpecial above explained it simply.
  8. I'm also sorry, but that's nitpicking. Aerospike are best at maintaining thrust over through their resistance to pressure change, which in term of gameplay basically meant the very same as being able to maintaining thrust at (any)various altitude. I do not have right now a working KSP install to check out the newest value, but as long as the Aerospike do not have the advantage over other engine to maintain the thrust BETTER at different pressure, then its intrinsic quality are not properly taken into account. And so, maybe the problem isn't the Aerospike but how all other engines were originally balanced with static thrust (as an consequences of the old aerodynamic system) and the Aerospike to not be utterly superior under the old unrealistic rules. I understand that SQUAD can't simply rework entirely the balance without making the forum burst into an infernal rage, but at least we can search where the real problem is. The Aerospike isn't simply an upgraded engine, it is the one engine to rules them all ...... as far as varying pressure is concerned. It's non-stackable nature and low TWR is enough to balance it. That's all I have to say on this.
  9. Maybe we can agree that with the new aerodynamic model, an Aerospike should in fact maintain Thrust at any altitude whereas classical bell are optimized for more specific altitude. This is to me the most critical point. The Aerospike must become the engine of choice for all Single-Stage vehicle.
  10. Cycler's DO save deltaV... indirectly. Their point is to avoid accelerating-decelerating each time an important mass : the live-support infrastructure. ex : Rather than needing to spend (say) 100tons of propellant to accelerate (then decelerate) a large ship containing both Engine, fuel, A LARGE LIFE-SUPPORT INSTALLATION (and the fuel to propel that mass) it would allow to just use a shuttle which can be kept more versatile later. So they are to be useful if : - You need Life-support (space farm, centrifuge gravity...etc) - You already have comfortable habitat and life-support at your destination Also, it can allow tremendous economies of scales. If we ever were to colonize a close by planet, a Cycler would over a few years save as much dV as its life-support would have added for the same number of colonist. Though, just saying : I don't believe we will ever have a need for them. Colonizing a planet is less efficient that simply living in asteroid belt (though you could use an asteroid-cycler).
  11. Just to counter-arguments, Procedural content, especially if they are active game-mechanic (engine & tank) rather than passive one (fairing), are so much of a pain to balance right that you recognize a game built around them by their simplicity and monotonous gameplay (MMO like Eve Online or Elite Dangerous). This is not to say that procedural generation do not have its use, quite the contrary. But it is hard to keep a game balanced if several features can now fail in an infinite number of way. - The fairing being procedural is... mostly complicated because of aerodynamic. Just to make sure everybody know, Realism don't necessarily equate to "more fun". - Tank being procedural cause problems on the little balance there is, you would have to balance the system for Technological-progression anyway, and prevent the game from becoming too easy, or some Exploit (at least not make clipping easier) - Engine being procedural, as much as I see an interest, would be the trickiest as any change to them or the ability to massively parallel them is enough to break the game. Another unforseen consequences is that you need point/form of reference to estimate the size and "range" (dV bugdet) of a spaceship, yours or seen in a screenshot. Procedural many-thing, even with standardized capsule/hatch can make this hard. Equally there is an innate interest in SOLVING THE PUZZLE that are Standardized Part Size & Spec into whatever you want which isn't available the same with purely procedural. So I mostly wanted to remind people that LEGO-style construction is a perfectly legitimate and voluntary game-design choice and not any sign of weakness or bad/incorrect design, not everybody have the time (or knowledge) to finely shape the fuel & aerodynamic until it work. In the end : I would rather improve the TWEKABLE than go further on the procedural route. (and this post got longer than wanted, that's all from me)
  12. As last time I'll recommend OpenTree. That's not the total-reworking some want but a good stock tree.
  13. Nice contradiction with your edit... Procedural only mean that you generate following a method, randomness is something that must be added on top of it, they are separate things. Ex : The planets of KSP are generated procedurally, will always appear the same way and are not randomized between players, something they don't need to. Still, I'm giving you the doubt that it is all a semantic error... Did you as I think (rereading 3 times your posts now) : generated ONE map where you procedurally generated the main feature (volcano, wind, rain...etc) and use a random tool to fill-up the crater/volcano...which will always appear ? OR... did you program something that actually generate a new continent/map/weather each time one play following only basic layout ? Because, yes, if you don't attempt to randomly generate planet surface/geomes "each game", you indeed keep your geomes only procedural, not random. No matter if a noise generator is used to shape the original relief. Still, to me it seem you still haven't understand how you are only changing the problems while solving the rover's one. - increasing mindless click-fest. - making rover dominant over static probes (though I'll agree it can eventually be accepted as a feature). - worsening the balance of reward per biome/planets. Anyway, I will stop participating to this discussion. Even if you were supporting me or I supporting you, your way of "discussing/editing" is giving me headache and I've better things to do. ps : I should have been clearer that I meant 10 Area-of-Interest per planet, but it really should have felt obvious considering the number of them I gave as example for Duna. Thank you for that, but you are also giving me headache (really). So I'll try my best to answer a few points without being unnecessarily blunt as well (note : I failed). First, I insist you are like children who speak of stacking features that are mutually exclusive/self-defeating. Yes you can call that a strawman, know that it is occasionally a valid rhetorical device to make someone understand his error, albeit in an irritating way. ...just like calling someone's argument a strawman is also a form of strawman, and not necessarily the constructive kind. NEXT ! I'm one fervent defender of time-based game-mechanism...I made a few thread about it, especially go along a periodic-budget. Still, the flaw in your 10h-scan logic is that you are still considering the Act of scanning the planet as a GOAL rather than as a MEAN to have fun. It is a understatement to say that not everyone here play to have the planets 100%-explored, really most play for the Act of exploring which include a lot of firework. During timewarp you aren't playing, Timewarp is meant as a tool to lessen a boring parts of a game that have little to no relevance in the gameplay : waiting. In our case, you still have to make it relevant in the first place. The act of waiting for the scan is pointless (and punishing) in term of gameplay. Even if Career-mode had periodic-budget it would still be pointless. So once again I think you are confusing "it's realist" for a game-mechanic and simply going for the argument because you really like the idea. NEXT : Trial & Error Again, just because you can don't mean you should. Apollo-13 random part failure would NOT be fun. It only "could" ...assuming some miraculous Game-AI prevented it from happening every time it would make players tears their hair off and cursing. Basically you are trying to 'win the argument' with an hypothetical situation based on pure luck. That's certainly a logical fallacy. No, no, no... that's also not the rationales quoted at all, and that's also wrong !!!1! (1 for emphasis) The less two player have in common, the less experience they share. The very reason Seed were created in Minecraft was to share them ! Solving what was a FLAW in randomly generated map. Anyway the whole comparison with Minecraft make no sense ! Different game = different design. I could make thousand analogy of what you've done here but it would only detract us more. NEXT : "God doesn't play dice" Well, sorry but I can't imagine your game being well made seeing how ou are confusing the game having randomization features with the game rules being made up randomly. You think you are doing the former when you are doing the later (KSP's uniques planets parameters act voluntary as rules, same rules, same players experiences). THAT. IS a strawman, just so you know. I won't deny my provocative rhetoric, but keep in mind that if you DO say stupid things, reader might agree you are. Also, you are confusing a specific use of FoW (for exploration, wargame do not randomize) with random generation and grasping at straw to justify a GOAL for players (exploration) which is a subjective opinion. Which is what I was trying to make you understand. I gave many arguments explaining in details why random generation conflict with many of the aspect of the current OR expected/wished game balance/gameplay. So your dismissing of all this as "me saying stuff is always bad" is insulting. Not that I frankly expect you to understand anymore... Even though you like some of my idea, I don't think you get the logic behind. So, since it's clear this whole discussion is leading nowhere, I'm out. I'll still read answers for courtesy.
  14. What kind ? None. It's a feature I will easy ditch to avoid needless micromanagement. Rocket-science is all interlinked, but Life-Support is only a timer or at best temperature&ISRU that are already covered in more simple (and fun) way. So I'm not yet interested.
  15. Mr.Scruffy, with all the respect I give to longly constructed argument that are not quote-war. I do not see answer to my/ours points in your updated-posts and you do not seem to be getting answers out of mine, so we are still in disagreement. Even if you think we are not that far of each others, generating automatically sub-biome based on randomly-generated topology is still not different from random generation since the result is random (and worse if homogeneous), dixit what I said about increasing the click-fest and grinding. (btw : so far we also have yet to address the topic of how the player will distinguish in-situ/non-map the different sub-biome) At least I think we can agree that we do not see "RANDOM procedural generation" the same way. The personal anecdote you described is everything but random (you choose the equator to be hotter for ex) and the finesse of the details you required to actually improve the game was clearly inferior than needed in KSP. Different Game = Different design = Different method = different finesse. Hence to me you are suggesting to improve an AAA game using Candy-crush design. To rephrase it : What is the point of your sub...topological-biome/geomes if it is only dividing the click-fest from probes unto rovers ? I'll wholeheartedly agree that Rover really need incentive but making them the next "only efficients mean" of getting science (due to the necessarily world-wide homogeneity of automated topo-biome/geomes generation) would simply change the problem. A note on my "huge rover trek" : You seem to believe that I want to force people to accomplish the entirety of the trek for it to have any meaning, this is not the case. By focusing so much over the sheer leng....Epicness of accomplish suck mission, you are missing the implication that -even on a smaller scale- by manually choosing/refining/improving/balancing where Greater quantity of Science-point are localized (with a voluntary dichotomy between high-science area and normal-science area) you are adding a different gameplay that properly make use of the relief in a way that no automated generation can distinguish (unless you've all hidden sentient AI from me). so, consider the following along what I've said : - Each Area-of-Interest can go from intricately complex (ex : all science at various place of a giant rock that EVA have to climb) to methodical (ex : you know you have to stop every 100m-1km starting from the center of a crater/magnetic thingy to get all the science) - Each AoI have been placed to make the best use from an human perspective of the already generated reliefs (this cannot be automatized) - Each AoI position have been considered & balanced for an optimal user experience (see High-science / Low-science dichotomy) - Subtle "road" (aka : rover-friendly surface) could be generated in between on the height map (best use of procedural generation) to ease high-speed travel. - Overall AoI diversity is made unique and fulfilling by not auto-spamming them. And don't be fooled that it look like more work, this is nowhere complicated or long for human (by that I mean it's been done in other games), it would actually take longer to automatize right (or why so many modern game still use tiles-based map, it's easier to generate and not f***-up). The way I see it, you can procedurally generate Place-of-Interest, just not their placement and balance. Note that making them random would bring strictly nothing for reasons already explained before, Players like having the sames maps/challenges. Example of Area of Interest : -type 1 : concentric circles of science, to be manually placed and sized to match BIG crater size. (plus the mentioned mean of delimiting the sub-biome) -type 2 : non-concentric circles of science, to be manually placed over a gigantic mountain, a distinct one as you go higher. -type 3 : area of science, to be manually painted to match canyon/crest -type 4 : rocky-terrain with big pebble, various size. A sub-zone by themselves, generated or not around other AoI feature. -type 5 : dozen of small-asteroid-like rock with 1 sub-zone each, randomly generated over an non-randomly positioned/wide area. -type 6 : dozen of small-asteroid-like rock with 1 sub-zone each, those generated in a random-looking line toward the next AoI. -type 7 : single BIG-asteroid-like rock with 3/4 biomes, the biggest generated alone, like a rocky mountain. -type 8 : single BIG-asteroid-like rock with 3/4 biomes, small surrounded by pebble and/or smaller asteroid-like rock. ...etc I think what describe the best my preferred approach is : - classic biomes that can be 100% explored with classic means. - super-Area that can only be 100% explored with more complex means but only break even if ~25% of one is explored. The goal being to make unique zone that you are encouraged to explore (which wouldn't be the case if they were too numerous to balance, leading to grindiness) and which require Rover and/or Crew. The only downside I see is that, knowing which Instruments to use is still a trial&error click-fest. It would have to adapt.