Haustvindr

Which marketing? Did we see any marketing? Or did we see those videos directed to us who were following the development? I don't know about you, but I did see basically zero ads for KSP2. If you weren't already in the community or following KSP2 channels, you would miss the EA launch pretty easily. Sure, it could have been a closed beta a la WoW with their beta realms. The real question is, would you have prefered it that way? Only a limited number of people able to enter? At this point, it is likely that they prefer a smaller but very dedicated number of players that will actually help, and not tens of thousands players that their single focus is just "wanna pley now". Thing is, they opted for not limiting the access, and I can understand that, and I simpathize with that.

I think you misunderstood. There was certainly hype for the EA, but it was hype built by ourselves, in the very own community. I don't know about you, but I didn't see even one advertisement for KSP2 yet. Maybe if you count Steam own highlights that popup when starting the program we could count 1 ad, but I seriously don't remember seeing it there either. Either way, you are talking about hype before launching the EA. I'm talking about using an EA to build hype for the release. That's something that studios do nowadays, and it is annoyingly common, but sadly it works.

Counterpoint: do you really think they are worried about the number of players in the early access, or use it as any metric of success? That might be the case when EA is used for hype, gauge the current interest, or as an early marketing platform... but this one is obviously not the case?

It's not just that we understand K^2 expertise, but also that there are a lot of people who mostly shares the same opinion. There's a suprising number of users in this forum related to the software development world, and even I, working in a field far away from games (but still development) agree that a restart happening is very probable. But instead of dismissing my opinion right away, I can also offer a new insight and a different option for your train of though: legal issues, clauses or limits over the ownership of the code. When people migrate to other workplace, they will absolutely bring their know-how, it's obvious since it is ingrained in their own memories and that's something you don't lose in a few weeks (except in rare cases I guess). What is not always able to be migrated in the source code itself. I'd even say "typically not migrated", but I don't know what common options contracts bring to the table in the US. This is due to companies covering their own bases against unexpected troubles. When we e.g. develop a custom solution, the end result (software) may be property of the client (if they request it), meaning we cannot reproduce it for another client and a tad more constraints. What is never property of the client is the code itself, because in the code there is all the know-how, techniques, algorithms and so on, that we use as a company in a wide range of places. If we somehow relinquish the ownership of our code, we are opening a door (big and wide) for any client to attack us due to using fragments of "their" code in other projects. As we don't know what specific clauses T2/PD had with Star Theory, we don't know if the source code could be witheld by ST. But, if companies over there are used to cover their bases, there is a chance that ST may witheld the source code. And if ST witheld the code, there's no code. And if there's no code, there's no way to keep working on it. And if you cannot keep working on it, you are left with nothing else than restarting. So, speculation again, no evidence, apocrypha, heresay, yada yada. What I'm trying to convey to you is that there are possibilities as to why they WOULD NEED to restart from zero, and not just keep working on ST code. Very real possibilities.

Check out this thread, and see if it matches the problem you're having. If it matches your problem: If you are lucky, you may be able to get the game to work with some of the proposed solutions in that thread. If none of them work, I'm afraid you'll be stuck until the studio releases an update.

Oops, mea culpa, I guess. In my defense I can say that I thought about it as a complete renewal and not just a new coat. Bringing new things never demerits the work done in the older ones, neither demerits the people who worked on them. Never, ever, and I'll volunteer to fight whoever says otherwise (but, uh, can we fight metaphorically?). And people are enjoying a lot PQS+ judging all the screenshots, and will continue to do so for as long as you allow it!

Hi there, since it seems I won't be able to play for another week (touch wood), I'm growing a little impatient to test out some things. Is it possible to do something like this with the current procedural wings? Someone dare to try? I'm guessing that the wings may not be able to get that big?

That's easy, it is related to how the color picker UI works. This particular kind of color picker is common because it presents to the user a logical and predictive way to pick a color, making it really easy to use. At the top you've got a color wheel, that one is easy to understand: navigate through primary/secondary colors, and everything in between. So if you want a green, you're seeing it in the wheel, and you pick it. Easy peasy. That's the hue. Then, in the square area, you've got a representation of the brightness and saturation for the picked hue. Since they are 2 values, it is well fitted to be presented as a 2d chart, which makes the square area does. In the horizontal axis you've got saturation, from the least saturated on the left (gray), to the most saturated in the right (pure color). In the vertical axis you've got the brightness, from highest to lowest. Full brightness is white and lowest is black, that much we can infer instinctively... but the top right corner is not white! Brightness can, broadly speaking, be understood a little better if we compare it to how strong is the light the color emits. Therefore, a green lightbulb in a dimmer at 50% makes green light, and if we set the dimmer to 100%, it makes... <drumroll> green light! But stronger! So how to get white? By using a lightbulb with no color, i.e. with zero saturation. This is picked by people really really easily after a minute fiddling with the color picker. So, to go back to the question, why is the bottom all black? Because as stated before, it is the result of those 2 axis (brightnes and saturation) plotted in a 2d graph, which brings a square. At zero brightness, it is not feasible to get any other color than black (zero light = no light = black). Even if the picker right now may have a problem, in reality it should not matter where in that border you pick your black, it should still be pure black. So yes, it is kind of redundant... but it is not. That's because once you begin to raise the brightness, even the smallest amount of brightness will throw you off the pure black, and if you are out of the pure black realm you'll need to represent the variation of the color through the saturation levels (the horizontal axis). That's why the bottom border being all black is not perceived as a big deal. Theorically speaking, you could represent the pure black in a corner, just like pure white is, but you'd need to fiddle with what each axis represents, making it more complicated to understand. There are also other kind of color pickers that have an one-point black (there are indeed many types of color pickers) but the one used here has grown as one of the, if not the most, easier to use for all kind of users.

As far as I'm seeing, at scale=1 the KSP1 navball area looks that is not much smaller than KSP2. But due to density of information the navball itself is smaller, giving the illusion that the whole area is bigger. What it is bigger is the attitude/SAS widget, but I think it's not bad (until I can actually use it at least, I may change my tune). The other widgets are what makes the UI looks more cluttered, specially I'd say the staging one. Either way: in the game config json there is an option for UI scaling, so it is coming. I can't test it but for those of you that can, maybe it is worth a shot to check if it is working already or not.

Oh I know, I really know the pain of being too close to Kerbin. Thing is, we don't know what kind of modifications and improvements they did to the original PQS, so we don't know how much improvement there is. Through their words, it seems they deemed them sufficient enough even when accounting for the current not-fully-optimized state, so it seems their revamping included bettering KSP1 system all the way around and not just applying things on top. To me, it reads as if CBT was going to come anyways, but probably much later on, probably well into full release. Thing is... it seems they still want to apply more things on top of their PQS+, but after diving into these days feedback data from the people playing, they decided against it and to spend the time to bring CBT now. Either way, as I said it's a guess, no more than an opinion. We won't really know, but it's fun to speculate! Edit: And now I'm actually curious, about the neat new terrain with all those details we've seen in the works, was that still PQS+ or was that already experimenting with CBT?

I'm going to cut you there, because, you know, to forget something you first need to memorize it. You may be overstimating some capabilities there, you know.

If I were to make an educated guess even though games are far from my expertise, and based on what was said in the post, they probably used an already implemented system to experiment and try new things they wanted in the renderer. This probably allows them to both trying new things and evaluating the current capabilities, while keeping the work in an already known and familiar environment to be able to iterate much faster. Also, the words are there: If I were to keep guessing, they probably already experimented a little with CBT, which is why they quickly decided on the switch once they found that PQS wasn't going to be able to cut it. I'd even say that the switch to CBT is something that probably were discussed internally and decided against it for now... until it didn't. Then again, that's my own impression, and as I've said I'm a little far from games, so some salt is required ¯\_(ツ)_/¯

Early access is not linked to the state of development. Early access is the studio letting people try the software before it is released. Not more, not less, just that. By its very own meaning, it directly implies that generally the software is not finished. The degree of completeness is totally independent of an early access, and there is another whole commonly used system for that. Early access is not alone, there are also other less generic programs the studio may run that directly implies the degree of completeness (e.g. open betas). It's perfectly fine if a studio wants to run an early access program with an alpha, as well as it's perfectly fine if a studio wants to run an early access program with a release candidate. You don't get the decide that, the studio does. We got it, you don't like it, tough luck but that's on you. Let's go again: Early access is not linked to the state of development. And again: Early access is not linked to the state of development. And one last time: Early access is not linked to the state of development. Gosh, I wonder when people will get it. So... tiring...

One of us! One of us! You're not alone, there's a small pocket of people who are affected by this, there's a thread in Bug Reports about it: Unfortunately, if you already tried the proposed measures and none worked for you, there is not solution at the time. They know about this issue and we expect it to be solved in a patch (or should I say update?) soonish. As far as I've read around, there is not a fixed set of rules for it to appear, I've seen people have it with either strong and weak hardware. Most probably there's nothing wrong with your hardware, just... welcome to the bad luck room, it's cozy and calm here.

That's not really true, and you should not believe that. When games goes "gold", they freeze everything for the distribution in several media, i.e. they stop working in that build. Then, and because they know they have still issues, begin to work to have a patch ready for the day of the launch (day zero, does it ring a bell?). If I am to believe my memory, I've read that between going gold and release day it can take around a month or more, but I guess in full digital distribution it might be a little less. That's one month companies gives themselves to patch their "full" games, and sometimes it is far from enough. So much for "good" companies eh. Hours vs. weeks. Not the same at all.

There's a number of places in the UI where the font family used doesn't support accented characters. I guessing that all of those are using the same one?

KSP Version: 0.1.0.0.20892 Settings menu - general Spanish translation for the description of "unbreakable joints" reads a little rough, possible better translation can be done. Correction: It should read better if translated to something like "Las juntas entre una pieza del vehículo y otra no podrán romperse debido a las fuerzas.", which would translate as "cannot be broken due to the forces" instead of "cannot be broken with the force" (star wars vibe?). Forces, in plural, is more proper as well (aerodinamic, gravity, lithobraking... there's not just one). KSP Version: 0.1.0.0.20892 Settings menu - general Spanish translation for the description of "probes need signal" is not very clear: "los núcleos de sonda deben devolver su señal al CEK para no perder el control" translates roughly to "probe cores need to return their signal to KSC to not lose control". Correction: that "return" signal looks odd, I think it would be better to translate as "Las sondas deben tener una conexión con el CEK para poder ser controladas". Notes: The correction, translated to english would be something like "Probes must have a connection with the KSC to be able to be controlled." The "core" (núcleo) can be lost without losing any meaning, making the phrase cleaner. The connection to KSC is explained instead of the odd "return signal", and it is correctly stated that you need that connection if you want to control the probe. KSP Version: 0.1.0.0.20892 Settings menu - general In the resources section, the infinite fuel is in german? instead of spanish. Correction: change it to "Combustible infinito" KSP Version: 0.1.0.0.20892 Settings menu - sound Spanish translation for master volume is "nivel del control", which is... weird (translates to "control level"). Correction: change it to "nivel general" or "nivel maestro". Notes: The whole "nivel" is a little spicy, it is far more common to use "volumen" (volume): "Volumen general", "volumen del sonido ambiental", "volumen de los efectos", "volumen de las voces", "volumen de la música". But technically it is "volume level" -> "nivel de volumen", so it can be understood fine with either ¯\_(ツ)_/¯ KSP Version: 0.1.0.0.20892 Settings menu - sound Spanish translation for "modo nocturno" is a little wider and forces a smaller font size. Correction: change it to "modo noche" (night mode), it should retain enough meaning and will free 2 letters worth of width. KSP Version: 0.1.0.0.20892 Settings menu - accesibility Spanish translation for quickload hold/press setting is showing "hold" and "press" modes in english. Correction: change it to the spanish names (as it is already done in the buttons): "Cambiar carga rápida de [Mantener] a [Pulsar]" KSP Version: 0.1.0.0.20892 Settings menu Spanish translation for "reset all settings" got a little long for the button: "restablecer todos los ajustes". Correction: change it to "restablecer todo" - "reset all". Notes: due to the context, "reset all" should be fine as the button label, because there is already other button to reset the current page. Moreover, there is the description in the warning explaining everything in detail. KSP Version: 0.1.0.0.20892 New campaign menu Campaign difficulty is not always translated. It is showing "easy" in spanish, even though it shows "fácil" in the options. Correction: show the proper translation in the difficulty field. KSP Version: 0.1.0.0.20892 New campaign menu Spanish translation "ingeniería aeroespacial" gets a little long for the button. Correction: change it to "ingeniero aeroespacial". Notes: instead of a generic "aerospace engineering", targetting the player itself with "aerospace engineer" saves 1 letter in spanish while not losing any meaning. It's not a lot, but it may give just the little space it needs to look better. EDIT: I reviewed this in the middle of the night, on a sleepless one, so I apologize if I proposed weird translations. Either way, I think it's a little early to review the localizations and that's why I suggested the most glaring ones. I will try to properly review the spanish translation in a future, more complete build, and hopefully more than just the menu.

Between what I found, I'm skipping all of those where the "issue" is that they don't have translation yet, since I guess those are already in the queue. #1 KSP Version: 0.1.0.0.20892 Settings menu - input Action group descriptions shows an incorrect number. Group 1 is fine, group 2 shows description for group 3, group 3 shows 4, etc. Group 10 shows description for group 2. Correction: The obvious, I guess, just set the right number in the descriptions. #2 KSP Version: 0.1.0.0.20892 Settings menu - input In the EVA section, there is a setting for "Center camera in VAB", but the description talks about pitch forward/backward. Correction: Obviously the name of the setting is wrong, it should be something like "Pitch Control (Jetpack)". #3 KSP Version: 0.1.0.0.20892 Settings menu - graphics In the quality presets section, the name of the setting is simply "PC". Correction: I guess a proper one would be to change it to "Quality Preset". #4 KSP Version: 0.1.0.0.20892 Settings menu - graphics In the quality presets section, the description of the setting PC refers to presets as "pre-set". Correction: Change the wording to match that of the section: "Quality presets" -> "Adjust all graphics settings to a preset".

EA is what it is: an early access for people who want to help, don't try to look for things that aren't there. It is not linked to any state of development, it is not earlier than alpha or later than beta, it is something completely independent. You can do EA at any point, even with a tech demo barely working. It you want to do an EA in some platforms, they (the platforms) may put some constraints, but that's an artificial constraint decided by the platform. E.g. Steam requests the EA to be playable (i.e., to run), which it's something they ask for to prevent crowfunding schemes. Does KSP2 run right now? Well, reading the forums, it certainly does for many many people. Point checked. They knew, and they know. They probably know far more bugs than those reported in these few days. Do you really think they don't? I knew perfectly well what was in the EA package. Why? Because Steam warned me about it being incomplete and probably having issues. Pretty sure similar disclaimers are found in other platforms. That's sure quite enough, right? After all "incomplete" means something like "not completed", "things missing", "things can fail", and so on. Even without lurking in the forums, I think it is a pretty clear message. And that is just the Steam default message for EAs. Really, I can't think on any way that said message can be reinterpreted as something like "it should work fine and dandy because my expectations says so". So, you don't like the state of the game right now? That's fine, get a refund, breathe, come back at a later point if you want. Nobody is holding a gun to your temple. But please don't go telling that your expectations for an EA is what an EA needs to be. News flash: you dont't get to define what an EA for this or that game should be, the studio in charge decides that. I may be wrong, since I've been lurking over this forum for... a number of years and at least a couple redesigns, but... most people who are long term users are just chilling, testing and submitting, and letting the studio work (pretty sure with some popcorn nearby while watching the fire). That should be pretty telling since they are, and have been, at the core of the community. Heck, I'm pretty chill about the whole ordeal and I can't even get to play due to the dreaded pumping sim. Do you know how enervating it is for the people sharing this bug when we read about people karening away because their running game don't fully cover their expectations? Really, people need to chill out, enjoy what the game has to offer for now, and dream with the things to come. And... I'm sorry if I came a little rude, not really my intention, just venting a little frustration. Because really, it is becoming pretty tiring.

After all the noise I've been reading... I actually think that many people don't really know the implications of an early access game, and can't (or won't) understand what is expected from the "player" in EA. I feel they are accostumed to the many studios that nowadays use EA as an early marketing platform. KSP2 is a "real" EA, and KSP1 was as well. People seriously need to deal with it already. You don't get in an EA to play earlier, you don't get in an EA to save money, and you don't get in an EA to have fun (though we will obviously try). You get in an EA to lose hours trying to find how that bug can be replicated, you get in an EA to try to break the game in wathever way you can imagine, you get in an EA to test to the limits the game loops and find imbalances, you get in an EA to review over and over the same points, and then you go over them again. You get in an EA because you want to help, and you do that on your own good will. If someone is not ready to do at least some form of helping work, EA is not for them. The studio may compensate your good will in some form, but they are absolutely not obligated to do so. So, it is typical to see things like offering a cut on the price, unique cosmetic items, places named after contributors, exclusive merchandising, etc. And the most obvious compensation is that when the game starts to stabilize and have all systems in place, you actually can start having fun before the full release.

Maybe it is related to my findings in the color picker for new campaigns? The active pixel of the mouse is at the top-right corner of the circle sprite, and not in the center. If it is the same in the VAB color picker, you should be able to click and drag to the black corner (even draggin out of bounds, it doesn't matter if the circle gets thrown out), and get pure black.

Some of us are stuck like that, it's just our bad luck at the lottery ¯\_(ツ)_/¯ No working solution right now, and I've tried a number of things outside those mentioned in the forum. BUT, there's some info about this issue being worked on in the incoming first patch, so hopefully we'll get to see the rest of the game soon(ish).

I... I'm stealing that to tell to our clients. Sorry not sorry. Maybe they will finally understand (yeah suuuuuuuuure).

Oh hey, hello, I knew I've seen that design somewhere else. I'm not a dude that usually engages, I mean, look at my # of posts and date of my account, but in fact I've been lurking in the forums a loooong time. But I will engage this time because I need to thank you for not taking those points as an attack, as it was not the intention. The amount of vitriol I've seem in the forums these days is astounding, not like the rest of internet is much better though! As I said, I like many things about the mockup, and I think it's generally okay. What I meant about "designed for the visuals" is that it looks like visuals were prioritized when a conflicting point was found (e.g. the RCS/SAS positions), at least in some points. It is not a "bad" thing either, after all it is all about finding the right balance between ergonomics and visuals, and the hard part is that not everyone have the same standards. I think... I would had tried to set the RCS and SAS buttons in place of temperature and signal status, and setup the mode change and its icon within a box-button, much alike those in speed and altitude. Writing also the selected mode text (orbit-surface-docking) along the icon and it should eliminate the disconnection between the selector and the icon, providing enough visual reference to the user. About the 3d attitude gizmo, I can't say for sure since I couldn't play yet, but I suppose that the little ship is showing the current relative orientation against the direction of the orbit (represented by the gizmo). In that case, yes, I think it should be a very good visual cue for new players to learn about the different attitudes, and how it will change when you lock into one of them. If it does not work like that, then no, the gizmo is not that useful. Now, take my comments with a grain of salt, I'm not really an expert at UIs. I work in the web side of the developer world, and I'm simply way too accostumed to work with existing UIs and build some more, therefore my experience is both tuned for the dumb(er) public and for extreme pixel-peeping (because clients won't forgive a 1px offset). I just was in critic-eye mode making my own post and happened to land in this thread before I could tune out ¯\_(ツ)_/¯ You do good work in my eyes, both in this design and in the other one, don't worry too much and don't let anyone say otherwise.

You though I was done, BUT IT WAS ME, D... Ok, enough fooling aroung, here comes part 2: Margins boogaloOoOoO There are quite a number of UI elements with inconsistent margins. If you can homogeneize them it should help a lot with perceived consistency. Making them homogeneus != making them all the same, but making them consistent. Some images are much better than a few words, so there you go: