samhuk

What was supposed to happen: It's all but certain that, regardless of what actually happened, the IG development team clearly *had* an original plan (before it imploded ~4 months ago): Release core game that is similar to KSP1 but nicer UI and gameplay. Work on extra "bolt-on" features like colonies, interstellar, etc. What actually happened: Now, as it all turned out, that didn't happen. What happened is that the development team released what they knew to be a very buggy game that was essentially unplayable as far as any reasonable standards for a AAA game. I recall many retreating to the "it's an EA" defense, but that level of unplayability and 4 months of still-not-fixed time, far exceeds that defense. Why did it happen: Well, there are many factors as play here. First off, AAA game development is really hard. There are several million dollars at stake, with a lot of investors (funding Intercept Games, et al) essentially making a huge gamble that only might pay off in many years' time. Those investors have investors, those investors have performance reviews and a balance sheet, and it all boils down to them. Now, Nate and no other at IG will ever divulge why it went so wrong and why they released what they knew to be a buggy unplayable first drop, but here are the possibilities: They actually didn't know it was as buggy as it was (QA problem). Investors pressured them to release so that investors get paid back. IG spent all of investor's cash and had to release to literally keep the lights on. Nate has made comments that have suggested that Cause 3 doesn't apply, and after seeing the awesome talent at IG, I would put doubt on Cause 1, so that leaves Cause 2. That's why, in all liklihood, investors pressured them to release, with the devs forced to cut a release off of master, knowing it wasn't ready but not being able to do anything about it. That is why Nate's job is so difficult, by the way. He sits right in the middle of the developers, the wider company, and the player-base. That's a lot of angry parties to be sat in the middle of, all wanting things to be done differently. The players wanted a less buggy game, released faster. The investors just wanted to be paid back. IG may have just wanted to keep the lights on. The developers wanted more time to release a less buggy game. All messy, all high stakes, millions of dollars and all - as AAA game development almost always is.

Many will have noticed that KSP2 game save file sizes will, at a particular point, start to exponentially grow, very quickly, until the game save becomes unplayable. The following analysis is for a game save that is only post-Patch 2 with no mods. Here is a chart that shows the growth of my own game save file size (in MB) over time: Each save was created when a new ship was created, launched, then docked to a standard space station. One can see that the game save file remains nominal for a while, with small <1MB increases. This is expected as each save has more and more vessels and other game state. Then, at Game Save 9, it goes from 4MB to 13.5MB, a jump of 9MB, ~15-20 times larger than the previous jumps. Then, Game Save 10 jumps to 70MB, a more concerning jump. Then to 1.6GB. Then to 4.4GB. Then, due to exceeding the capabilities of C#/Mono and/or it's JSON serialization capabilities, the game save reaches a limit at ~4.9GB. I created a little Node.js CLI to analyse a typical game save that is in the exponential growth phase. This tool focuses on what appears to be the problem: Some key observations: 1. The ObjectEvents array within the game save JSON has ~1.7 million entries. 2. The number of unique events is only 33. 3. There are several events that are duplicated exactly 8192 times, which is a power of 2. 4. Some events are duplicated over a million times. One of the extremely highly duplicated events is this one: { "TravelObjectIds": [ "440afbdc-50e4-4841-bfeb-bae414fcb830", "e010181f-0614-4698-8034-b2158744f9db", "4db9bd4b-ead0-470a-98dd-f4bca6e013a8" ], "EventKey": "vesselLaunched", "UT": 48841.746210548554, "FlightReportArgs": [ "Mun" ] },

> Fixed loss of vehicle on reference frame change when physicsless parts present Looking forward to rockets no longer exploding at 21km! However, correct me if I'm wrong, but the bug fix for landed vessels falling through terrain when you retake control of them is not currently checked in for next patch? I imagine it's because it's just a difficult and complex bug, but regardless... yikes Best of luck, KSP team!

Indeed KSP1 was never about world building (just like how Minecraft wasn't until extremely late and even then very tenuously with the End etc.), and adventure = discovery, so I think we can boil it down to "few/no mods were to do with discovery". That isn't true. There are the large number of mods that increase "adventure/discovery" - Kethane (before KSP1 consumed it with "Ore"), life support mods, extra planets (as you mention), science mods, progression mods...The list is endless! I feel like asking KSP to be about "story"/"world building" is just overloading the game. A game can't be everything. There's a reason why the base Minecraft game never got a world-building/story element added to it - the player creates the story and world! No game has one true objective purpose, as you imply. Perhaps it was word-choice though? If you meant "how it feels to play", then I totally agree. I'm not sure I even know what base KSP1 looks like. It's all but an illusion to me by now.

I find this discussion on KSP2 balancing X and balancing Y (e.g. realism, # of fuels, why methalox, etc.) a bit odd. I mean, KSP1 already solved the issue of different player opinions, play-styles, wants, needs and all that stuff with ✨mods✨. KSP1 architecture was made from the ground-up to be moddable (there was even a conference or two held something like 8 years ago by KSP1 devs about how they made the game so incredibly moddable), so that if you wanted larger planets, more realism, futuristic stuff, or whatever, you generally could install mods to achieve your desired gameplay. I find the discussion about what KSP2 should or shouldn't do, respectfully, a bit pointless, because of this. If KSP2 matches or exceeds KSP1's moddability, then it's likely you or somebody else will mod the game to your desired gameplay, e.g. more or less realism, more or less "factorio" play, different aerodynamics/heating, more parts, more planets, etc. Now the base game does need to be at least somewhat balanced and logical, for example there can't be entire swathes of parts that are made pointless by some god-parts, but debates about "keralox vs methalox" I believe are made pointless by mods at the end of the day. Just my 2 cents.

Why did it get so argumentative over such a pedestrian non-controversial topic? O.o Anyway, I've played since the early beta versions, and there are some issues that have continually marred the experience: 1. The binary "stick or slide" mesh friction physics (see: rover wheels, landing legs, etc.) 2. The "broken fuel crossfeed" bug 3. The "craft stuck in landed state even after taking off" bug 4. Bonkers mesh collision physics (ever tried to do anything but the SIMPLEST of EVAs?) 5. Maneuver nodes. Do I need to say any more? 6. The terrible scaling of performance with part number. I would disagree with some of the other comments regarding the inaccuracy of KSP1's aerodynamic physics. Aerodynamics is incredibly difficult to efficiently simulate on consumer-grade computer hardware, and what KSP1 has done is quite remarkable IMHO. Accurate aerodynamics, can actually run on your PC - pick one. Also, what's awesome is that almost all of the above things i've mentioned, the KSP2 team have already directly mentioned in the interviews and dev blogs,. for example the "Collisions" dev blog.

As others have said, it does depend on what KSP2 comes with, but assuming a few things aren't, here goes my two cents: Real solar system So, for backstory, RSS for KSP1 never really worked that well because of all the horrendous workarounds to get it to work and the tendency for it to make KSP1 unstable and slow. However, for seasoned players, the nerfing of planet size in KSP1 made things too easy and boring rather quickly. You could get mass fractions of like 50%. Throwing rocks at your keyboard probably builds something that can get to orbit in KSP1. So when the RSS mod came about, it brought a huge breath of fresh air into the game for many long-time players. When you get a spaceplane with a decent payload into orbit with the RSS mod, I'm pretty sure someone calls you up to give you a nobel prize a few minutes later. Robotics Made KSP1 interesting for much longer. Made planes and bases super cool. Infernal Robotics mod for KSP1 was an endless source of funny wacky krakenesque physics. HUD skins I really liked the reasoure HUD mod for KSP1 because it made the game look a little bit less of an el cheapo default Unity asset game that you could get from your local bakery. P.S. Not too fussed with weapons (this thread really did end up super down that rabbit hole)

If a particular developer is using an X52, then it's highly likely (certain) it will be supported in KSP2. As for KSP1, support for non-keyboard-mouse input devices is spotty, at best. It was mostly just an afterthought, haphazardly bolted on, using some default Unity joystick modules. It is likely that you need to do some manual tuning with logitech software that comes with your joystick set to get it all to work. I have the well-known thrustmaster 16000M set. I have got the whole set to work (in KSP1) only after I used thustmaster's fancy tweaker applications that map certain buttons to keyboard inputs and certain movements to "movement values" (whatever that means), and even edit some C# code to change certain input values (KSP1 uses some default Unity joystick code and it is quite bad). If you aren't too hot on tech and software etc., it may be difficult for you to get some or all of your joystick equipment to work with your X52, to be frank. No doubt that KSP2 will be better on this since it's getting a lot more time and care than KSP1 ever got (after all, it was just some curiosity started by some dude in some marketing company somewhere. Pepperidge farm remembers ).

Not too shabby pingo. I'm liking the horizon colours and fade gradients.

I second this, it would be nice. The problem being, projects as old as EVE have a lot of organisational inertia. They evolve using one system and everything depends on that. It may be an easy change for rbray, however it *may* be very difficult to change the file system now.

It's a known issue of EVE. rbray doesn't seem to be focusing on it right now. I think he's focusing on more fundamental aspects of EVE.

To the naming of EVE... To be honest EVE is a pretty good name for it. All of the letters are needed, and none less or more are. It applies enhancements to the visuals of the environment surrounding the ship in KSP. That sentence covers everything the mod does (well, rbray may correct me here, sorry!), and that sentence has all the words of the acronym, so... I think EVE is a good name. However...there is an Eve the planet in KSP, and EVE online the MMO game. EVE is a pretty popular thing.

Oh I see it there now, cool! Thanks.

Hey pingo, maybe you could post a link to that imgur album of the RVE EVE WIP port on the OP page? http://imgur.com/a/2jMLC#0 <- this one by the way. Just to give people a glimpse on what you guys over at EVE WIP are up to.

That hardcoded sunflare res. pingo :/ That is basically the only thing left for you to high-res-ify haha. These days I have this (probably wrong) idea that everything that "limits" KSP (resolution, memory, CPU/GPU utilisation, etc.) will be fixed after the Unity 5 hype train has docked and it's released. We can hope....

scatterer and EVE. Some very nice pics Pingo. That limitation on sun-flare resolution tho....yikes. I would have expected some wierd stuff going on since they both mod the game in similarish ways.

those clouds doe... Nice work rbray, you got cloud shadows working pretty nicely! EDIT: And also thanks pingo for tracking the progress nicely and for all your value-tweaking HD-eye-watering wizardry

My FPS is fine-ish, but some folks may be running at settings which their CPU/GPU can't handle I suppose.

The red sun flare is a temporary feature, which rbray either added as a placeholder for a proper sun-flare-glow-thing in the future, or it is simple a problem caused by something which rbray will get to fixing. As for the texture resolution, to create high-resolution ground textures would be pretty RAM intensive, unless the same ground texture was used but just loaded again smaller for a small area around the player. Though I'm not too sure. Maybe it will be too CPU/GPU intensive to do this? The mod uses a lot of RAM storage because where do you think all those cloud textures and city textures, and city-lights textures, and enhanced ground textures, and grass textures, and everything else, ......are all loaded into? RAM. Too be fair getting a new CPU/GPU really won't improve much at the moment. Even with an OC'ed i7 4790k with a GTX 970, a pretty high-end setup, you still will have like 20 FPS for flying through the atmosphere at high speed with like 100 parts. Even at 200 parts out of the atmosphere you'll start seeing sub 25 FPS rendering. Just join the U5 hype train and hope SQUAD doesn't SQUAD-ify the update (take 3 years with 20 explanations for "why it takes ages", and in the time they took explaining "why it takes ages" they would have done it).

U5 will bring in some awesome improvements though, including a way more up to date PhysX version, I think more stable 64-bit modes, and basically a bajazillion shader improvements and additions. I wouldn't say it's a full polished silver, but it's somethin' pretty darn shiny.

Just a preliminary comment before the pros clarify, OpenGL is generally glitch, and one should always try and avoid it. For U5, we wait.........

Basically all the colours of the sun and related to it are not finished yet. That includes looking at the sun through a planet and the red glow around the planet edge, and the huge red glow around the sun when looking straight at it through the atmosphere.

Would be nice though if the configs had comments, like a random example.... _DistFade = 420 //this changes the rate at which textures fade with distance Well that's for C languages. Dunno what the comments are for the language you're using EDIT: There are pros and cons I suppose. You could then get an increase in people asking for help with modding the config, which will increase workload way more, which I don't think you would want :/.

Oh, you can't see how he was being facetiously "me no understood"?. Ah never mind, forget it, I like this project and the peeps who help develop it, I don't want to mess things up over something as silly as this. Continue at shader-factor 10 scotty!

Why thank you Proot. Say, if you liked my grammar tip so much maybe we could IRC some time? I would love that. I could teach you how to be helpful and sociable on forums! I'll even throw in the odd sarcasm lesson. Sorry rbray for the forum clutter, but this guy is just on another level...