Jump to content

r_rolo1

Members
  • Posts

    909
  • Joined

  • Last visited

Reputation

299 Excellent

Profile Information

  • About me
    Rocket Scientist

Recent Profile Visitors

2,244 profile views
  1. Couldn't agree more. I'm also in a non English Keyboard ( Portuguese ) and suffer from the exact same issues: some native keybindings do not work ( exactly the same one you mention, next and previous craft in flight view ) and special chars are not even usable ( in my case ç ). Ok, unlike olden days we have a significant latitude in remapping keybinds, but it is still a issue .
  2. That is a fair point, mostly because, due to the nature of physics, there are only three ( or four ) real dificulty bumps in space exploration for non-ageing beings that don't need to eat, drink or breathe : getting to orbit, docking and make a return mission ( the fourth is getting functional IRSU ). Tailoring a dificulty curve out of a curve with a couple of cliffs is hard, especially if you add the assumption that parts in general have to get better with time ingame ( gamers absolutely loathe "Dark ages" in game progression, where stuff doesn't progress or even regress ). That said, note that the current interaction of the game tech also does not work very well in keeping the game enjoyable and challenging after you have managed to dock and have 2,5m parts ... and it is discussible if it does that before as well, so it is not really a defense point for the current interaction of the tech tree
  3. Well, the issue is that there is a not so fine line between having parts strategically placed to various places of the tech tree and having them scattered around the tech tree to force players to go everywhere. The second is the exact oposite of any normal game with a tech tree or equivalent does ... most games ( and RL, I might add ) make very that you reap rewards of specializing in between some very distinct branches ( also in most games you have at all times between 5 or 6 choices in the tech tree at all times to promote diversified game play and keep the player with the feel they can actually choose ... ) and yet it is what KSP has at this point: we have both parts sneezed out through the tech tree to basically force the players to go everywhere even if they don't want to ( note that this is not my words ... just rewind to the pre-1.0 dev notes and see what SQUAD says about how the current interaction of the tech tree was chosen ) and basically a railroaded best aproach to it, dictated by the fact that most science gatherers are in a conga line through the tech tree... Besides that KSP is suposed to be a Tycoon-like game ( BTW SQUAD, I still want to train my astronauts after all this years, and with that I mean something diferent than going to Duna to learn how to change a tyre ) and any Tycoon game worth his salt has their progression bunched in discrete untis that unlock similar upgrades. Say, using OpenTTD example, you don't start the game with rails and buses and only some years later you learn to make trains and roads ;), Yeat in KSP nowadays, you can easily get locked in a situation where you have to choose between having X m fuel tanks but no X m engines or X m engines and no X m fuel tanks ( again, let me point out this is a deliberate ( and IMHO stupid ) choice to make the players go in fetch parts quests through the tech tree ) and we get stuff bunched in the same tech that has no business going together ( say, that nice tech that unlocks 2 extendable stairs ... and a Mobile crewed Science lab :| One of those things is not like the others, methinks ... ). OFC that being a tycoon like game would also mean that the price structure of parts making and unlocking would also have to be sane, something that it also isn't ( Good ol'Mammoth vs Vector example ... ). P.S I : Getting this balance between having diferentiated branches and keeping the player with 5-6 choices at all times while still keeping a somewhat coherent experience is HARD. There is a reason why game design is a job, and a well paying one I do not criticize SQUAD for not being able to get it right, but SQUAD made the conscious choice of making people go around the tech tree to fetch parts that were scattered all along with the exact propose of making the players to wander around ( BTW the same strategy they implemented to their comunications with the fanbase: one tidbit in twitter, one on reddit, a crumb in Squadcast ... maybe marketing people think in everything that way nowadays? ( and before someone says anything, this is the official position of SQUAD, by KasperVld mouth, in this forum ) ), a aproach that was doomed from the start to produce the kind of results we have. Well, TBH, in all of this years KSP never really had a game designer that knew it's trade ( with all respect to Harv, but we all know that even Harv agrees that he would had not made some choices he did if he knew what he does today ), so maybe I was expecting too much ... P.S II On the manned vs unmanned issue some others brought out: the current state of career mode makes that the whole "we need green animated ragdolls in first flight " a little moot , since we can't see them in flight until we upgrade a KSC building. Sure we can see some animated portraits in the bottom right corner in the first flight, but in gamewise visuals it makes very little diference if Jeb is the capsule or sipping coffee in the Mission control reading telemetry in the first flight, because you can't EVA You could even plast the same portrait in unmanned flights if you really , really want to see kerbals and say that the kerbal you have there is the Flight controller for that mission More seriously, the fact that SQUAD chose against all clamors to stick to manned first ( not even manned OR unmanned first ) aproach has has some IMHO bad repercusions on the rest of the game, including on the parts avaliable in game. Say, the RT-5 "Flea" only makes some sense in existing compared with some other probably more useful SRB options ( say, a RT-10 lenght 0,625 m SRB ) because SQUAD wanted to have a SRB for the first flight that could basically send a MK1 capsule to 10 Km if finely tuned ( like the RT-10 did in the soupsphere of old ) and obviously you must have a 1,25m SRB under a 1,25m capsule ... ( again, not my words. In this case Scott Manley and NathanKell ones ). So we ended up stuck with a part that , while useful, probably is taking the place of ther even more useful parts just because Jeb had to be in the first flight. Other issue is that, IMHO the unmanned rockets are having too much of a nerf already even without forcing the players to not using them in the first flight: manned flights can get more science collecting options than unmanned ones ( crew reports, EVA reports and samples ), 2 of them that can be dialed home without losses. More, most probe bodies are ridiculously underpowered in terms of actual control force even compared with the weakest capsule and even probes + reaction wheels ( that also come somewhat later in tech tree than desirable IMHO ) normally lose to a capsule of the same weight, probes bodies can't store RCS for fine control and , probably the worse, manned missions can reuse two experiments that unmanned missions can't and the data crunching you can do on the science labs if manned to get even more science you simply can't have in unmanned missions. EDIT: You can also put all of your collected science in a nice reentry worthy manned capsule to 100% recovery in Kerbin, something that you can't do in unmanned missions ... and we know how heat sensitive some science parts are :/ It is really needed to push usable probes to the 4th tier of techs vs the fully controlable manned capsule in 1st iter on top of all of this to balance the rocket equation tyranny? I wonder...
  4. But SQUAD named it It is not that they chose to keep the star unnamed , right? They just chose a name that it was not the name the community had chosen back in ol'days and for some reason ,most of the community decided to ignore the devs about this particular name ( it is not that we see people asking to name Kerbin Kearth )
  5. Well, I described succintly what stock burn time does in the post you quoted, but I can obviously do it in more detail ... First of all, you are half wrong, since the stock burn time is not necessarily a instantaneous measurement and it does not use the current acceleration. What it does is to get the maximum acceleration you got in your current map session since your last staging event and use that for the burn time calculation. So the value the stock burn time is only right if you're at your max thurst all the time and will only self correct if your thrust is increasing ( if you don't believe me , just boot the game and decrease your thrust after creating a manouver node ). In other words, the current stock burn time, unlike you state, assumes stuff about your ship in the future: it assumes that you'll not stage during the burn and it assumes that you'll never decrease your thrust in between staging events. Those are quite heavy assumptions and the reason I brought it to this discussion. It was SQUAD that defined the level of what is to be expected in terms of gauge quality by doing the quite hacky burn time meter we have since manouver nodes exist and it is somewhat intelectually dishonest to pretend we have some kind of high quality bar for a dV meter when both devs and players have been OK with a low quality gauge elsewhere.that shares pretty much all the same potential issues a stock dV meter could have :/
  6. Well, on your a) ... well, I definitely don't need it, but I also don't really need manouver nodes, burn times, close aproach markers or even SoI change signaling since I learned the game before any of those things were even in the game at all ( and people earlier than me don't even need map view, since they learned the game when they had to do math to know they were in orbit ). Other people mileage might not be as long as mine or yours, mind that and OFC, not needing a thing is not the same as having that thing not being a plus On your b) ... well, that is pretty much why I brought the burn time to the fray. As you said , the burn time calculator uses the max thrust of your map session to calculate your burn time ( that alone is problematic by itself, because it does not save the time to burn if I get out of map session and go to the VAB or something, but that is not my point here ). That brings errors everytime your burn is made at diferent thrust than max session thrust, as you point, but ,unlike you assume the errors do not self correct ( they would only self correct if your thurst either flatlines at max thurst or if your thrust is ever increasing 100% of the times, hardly a certainty ). I also must point out that the game burn time is also increasingly not assuredely correct as your ship increases in complexity ( besides more engines being a source of more variable thrust levels, more parts normally also normally means more losses to mechanical deformations of the ship ), effects that are not taken in account in the stock burn time meter ... not mentioning that it doesn't care if you will have to actually stage in between the burn My point in here is that it was SQUAD that lowered the bar in what is to be expected in terms of quality for stock. You can't drop something like the stock burn timer, that gives almost always bad answers and it gets worse with more complicated ships, leave it there basically unchanged for years, and then be all prude and saying that you don't want to make ( in case of the devs ) or want to have ( for the rest of the mortals ) a stock dV meter because you don't want to put in game a possibly inacurate dV meter that can get more complicated ships wrong. That is incoherent at best .
  7. Well, by that logic, we should also take the burn time of the game, because that thing will spit nonsense numbers a lot of times, when it simply does not throw a N/A on you ... I really, really, don't get the whole " if it can't be perfectly accurate, better don't have it" line of thought some people showed in this thread. RL doesn't work like that and TBH, games also don't work like that ... and in case of KSP it is even worse because the whole game is built on top of a not so accurate representation of orbital mechanics that will always get things wrong
  8. To not lose a lot of time typing it all again ... So, I assume that you want to make Kerbin Kearth again as well, right ?
  9. Yeah, I have to agree that "Sun" is a very flareless name, but well, "Mun", "Eve", "Duna" , "Pol" or "Ike" are not exactly exotic or space-sounding , so it is not that Sun is somewhat not fitting with the theme ...
  10. Because you're speaking english If you speak Spanish or Portuguese, we call Sol ... Sol
  11. Short awnser: the star in KSP planetary system it is called Sun . Not Kerbol, regardless of what people say to you Slightly longer awnser: Originally in KSP neither the planet or the star in KSP were named in game and so people in the the comunity, in what would be the beginning of the quite ol' tradition of "adding K to the beginning of each word" named the planet Kearth and the star Kerbol ( you can still find some 2011 youtube videos using that naming scheme, like "The Dark side of Kearth" by Scott Manley ). When the devs finaly decided to name both bodies , they went with Kerbin and Sun and , while people dropped Kearth quite fast, they continued to pretend that the star was named Kerbol. And here we are 4 years later still saying to people that "Kerbol" does not exist in game ...
  12. And OFC, we have take in account that the modder said that he is not sure he can pull it out in Unity 5, because the function he was using in Unity 4 for this was heavily changed and is no longer a fit for this...
  13. Well, as I said this week to a streamer that got the same issue, this is not SQUAD fault, while it's true that the devs here are guilty of both corner cutting ( by using crew capacity alone to determine if a part is avaliable for the rescue contract ) and by, in this case , not providing the modders tools to deal with this issue... well, the modder was ( or should be ) well aware of those limitations when he created the parts, I assume ( being the modder in question Roverdude ), so he chose to put parts that would give problems in his mod. That said, and again, if you ask me if I think SQUAD "solution" here is a good one ... well, it reminds me of the warnings of my programming teachers of almost 20 years ago to always check if your checks are being done on the right variables ( and also to never use magic numbers, another thing that SQUAD does a lot ). If a part realistically requires both crew capacity and a way of getting out for a contract to be fulfilled ( barring some dubious Klaw usage ), the code should check for those two things, not only one
  14. Well, I do not speak for the devs, surely ( neither of us, TBH ). I do know their thought process partly, though, because the devs fortunately can speak and type, and Harvester was always very, VERY adamant that he wanted to smooth out the game for newer players in his public interventions either here or in other media. OFC intentions do not always beat with final results and my point in this discussion was always that while the devs tried to make the entry of new players in the game easy, some of their actions worked in reverse. About the game being a learning tool, yes, it is .I already used it to tutor high school kids about physics. But letting the players happily crash stuff until they got it right, while it is a learning experience, is probably not the optimal way of doing stuff, because while they can learn to do stuff right, they are not learning how to do it or why it worked this time and not the other. For a quick example, I can say to a kid that the reason his rocket is not taking off is because the weight of the rocket ( pointing out ot the number in the flight engineer menu, maybe also taking the cue to explain the diference between mass and weight and how to get one from the other ) is bigger than the thrust of the engine ( pointing out to the parts menu number and maybe explaining other details depending of the age ) ... He could probably discover it by itself by taking out weight ( or adding boosters, most likely ), but I ,as a tutor, might point out exactly what he is doing right or wrong without much fuss because the numbers are there ,even if somewhat hidden ( more on that below ). OTOH when a kid asks me what is that number that appears in manouver nodes, I can explain what it is and where it comes from ( it is actually a good starting point to introduce velocity as a vector ), but then the inevitable next question is "How do I know how much dV I have in my ship?", while I can talk a little about the general idea ( most of the times I can't really enter in much details because they don't know log tables ), I can't really do like in the above example, because the number simply isn't there , in plain sight or not. I can't simply say: "Do you see? If you put this part here, your dV decreases because you're adding mass that is not fuel. Now if you take that part off and add a fuel tank, you're adding dV because your initial fuel load is bigger. So this ship might go where you wanted and the other one will not ...", while I can do this in the above mass of rocket vs thrust ASL example. All of the above already happened to me, so I think I can talk about it I'll not enter in the discussion of simulation vs game or about what is fun. Both are highly subjective and I assume our positions are quite divergent on both issues. And it would be even more off topic than most of this discussion... Let me point out that a variable, besides being in plain sight or hidden, might be acessible. Or in other words, besides throwing him information or not, I have the option of saying to him "I leave this intel here. If you feel like it you want or need it, give it a look. But you don't actually need to see it at all times" .Every program that displays any kind of intel in it's UI has variables that are visible, others that are hidden and others that while not visible at the moment , can be acessed at the user will, normally under a submenu or another tab. Say, let's look at the flight scene on KSP by default and the intel it is there. You have exactly 3 numerical variables displayed: Mission time, Altimeter and Velocity relative to surface and a couple more non-numerical variables ( thurst percentage, g-meter, the thermal gauges, fuel in tanks, ... ). Those are visible without any more interaction with the UI and this is what a 1st time player sees and barring some random clicking or some self or assisted tutoring, this is all he will ever see on that screen. Now note that the flight scene has far more intel more or less acessible , under sub menus of the already displayed intel ( say, you have speed relative to target and orbital velocity in the same UI part of the surface speed if you click it ), on click in some UI parts ( say fuel quantity in total and per state and rate of consumption/generation ) or via documented keyboard keys ( the drag/lift/thrust vector display ( F12 ) or the flight log (F3) are good examples ). This intel is avaliable to the player, but only on command by the player. That is, the player wants to see it and has to take a conscious step to see it and the game itself provides the way to get that intel. If you don't want a certain intel to be seen by most players, you can always let it only acessible via game console, like KSP does with a lot of variables. It is assumed most players will not go there without a good reason, right? Then there are hidden variables that are never stated in the UI. Say, the game never states the densitity of Kerbin oceans or the air viscosity, but has surely variables inside that represent them and if you really, REALLY want to know them, you can only know them via trial and error in game or check the source files. My point of view, that apparently I was not able to pass to you, is that the dV number should be acessible in game, like, for example, the wet mass of a in flight rocket or the lift vector on a part are. That is, the number is there and if I want to, I can go check it. I don't want or need the dV number in sight all the time or even most of the time, like the mission time is, but I would like that, when I want it , I could check it, like the ASL thrust of a engine in the VAB. In resume, there is a middle ground in between thworing intel to the player and withholding that same intel in the depths of the source files. I think a ship dV fits there nicely.
  15. IIRC there were some parts up to 0.25 ( that in my head is 3 versions away ) that had not exactly 5kg per unit of LF due to most like some rounding errors of the devs. It was nothing very serious, though
×
×
  • Create New...