kfsone

Yeah, I've tried adjusting graphics settings up and down, but I figured starting from clean was probably safest for diagnosis. I figured I'd save posting full size images until someone said it wasn't normal Those were actual resolution images, just cropped to emphasize the banding/other issues. These are images from my current modded game, so I acknowledge they're not showing default images, but I see the same dithering/banding issues in a stock clean install (I just don't want to interrupt this flight right now, I can post those a bit later if needed). Log: https://www.kfs.org/oliver/ksp/ksp.dithering-modded.log Images (as links so they don't get resized/bloat the thread) https://www.kfs.org/oliver/ksp/dithering1.jpg https://www.kfs.org/oliver/ksp/dithering2.jpg https://www.kfs.org/oliver/ksp/dithering-settings1.jpg https://www.kfs.org/oliver/ksp/dithering-settings2.jpg And this is exiting out of the tracking station, but it's pretty much every transition including from the menu where something like this happens https://www.kfs.org/oliver/ksp/transition.png

Just returned to KSP after a long hiatus. First, let me say: All hail King @linuxgurugamer, for thou art great and full of mods. Second, the game has come along nicely. One thing I don't remember from early KSP but I guess it was this way, was that everything seems to be in 8- or 12-bit color - there's a lot of what looks like visual dithering/banding, and while I remember there were a couple of places that could be seen (mostly in atmospheres) I don't remember it being so pervasive - e.g even on the loading screens? I'm also noticing weird artifacts on what should be black screens, that seem like uncleared shader data or back buffers when the game stops rendering. I'm running Win 10 (insiders slow branch build 19577), GeForce RTX 2080 8GB with current nvidia release drivers, and this is a raw fresh install of KSP with no configuration, as well as a fully modded version with settings tweaked for aa etc. 35in ultrawide 4k monitor, tried hdmi and dp - but it's only KSP that behaves like this. Is there something I can do to fix this? -- Aside: While looking into this, the painfully slow loading of KSP got annoying, so I shaved about 1/3rd off load times by running this from wsl in my KSP gamedata directory: # s://.*?([\r\n]+):$1: - removes comments but leaves end-of-line as is # s:^[ \t]+:: - removes leading whitespaces # s:[ \t]+([\r\n]+):$1: - removes trailing whitespaces but leaves end-of-line as is find . -name \*.cfg -print0 | xargs -0 perl -i -pe 's://.*?([\r\n]+):$1:; s:^[ \t]+::; s:[ \t]+([\r\n]+):$1:'

Depends which side of the great firewall you are.

After toying with SketchUp (for 3d modelling) I'm reminded of the snap-to stuff I've been using in editors since MSVC 6; as you move something past an item across alignment with another relevant line it sort of sticks briefly, making it easier to do - say - alignment of the nozzles of your engines (drag an engine placement down and when it notices the bottom of the bounding boxes line up, you get feedback without too much hinderance). Is there a mod that does something like this, already?

Bleah, I was lazy and tried to use the search to see if it was mentioned. Sorry!

Nope. It went from "Sub-orbital trajectory" on the way up to "Above 150,000m" when I got into orbit and then, when I decelerated, dropped back to "Sub-orbital trajectory" and then back to just "Destination: Kerbin".

Having problems with the R-2A mission: I seem to be able to get either the "above 150,000m" check or the "sub-orbital" check, but not both at the same time. I'm thinking that the solution is a deceleration burn from orbit above 150,000m and when it becomes sub-orbital I'll get both checks, but this is not made clear in the description. It's also not clear what "return home" means - whether I'm expected to recover the vehicle at ksc or just land it someplace and recover it.

[quote name='Harry Rhodan']And that is really your whole rocket? Even without closing the fairing it only has about 2800m/s in a single stage. That is not enough to get to orbit, especially if you try to go straight up too long like your last picture shows. The TWR of more than 3 will also make you hit supersonic speeds pretty early while using only one stubby stage with a comparably heavy engine will make your dangerously low CoM drop even more during ascent. Adding a wide fairing will only give the aerodynamic forces even more torque to push you around. What you really need is a second stage to keep the CoM up and enough juice in the first to carry you high enough for a safe stage seperation.[/QUOTE] No, it is just the trivial example one I made for the thread after dozens of genuine attempts; a "demonstrator". I'm a software engineer and we tend to try and reduce problems to their simplest reproducible steps, I could probably have made this even simpler but I expected *this* question many replies sooner. Ultimately it was the combination of weird aerodynamics + overwhelming reaction wheel that was the problem. [COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='FancyMouse']Since it is a light rocket with a fairing, it is more likely to be affected by a [URL="http://forum.kerbalspaceprogram.com/threads/139219"]stock bug[/URL] that incorrectly sets CoL for fairing. Try Claw's stock bug fix see if it helps.[/QUOTE] Oooh! Yep - that helped a lot, but I was also making the mistake of making my fairings pointy to save weight rather than making them nicely aerodynamic to save drag. I thought the effect would be more like the rounded shapes you often see: [IMG]http://i.space.com/images/i/000/021/485/original/india-pslv-c21-rocket-100th-mission-nose-cone.jpg?1347312624[/IMG] but it's not.

[quote name='Venusgate']Use the fins, Luke. Trust your (air)foilings. EDIT- Sticking a couple of control surfaces down toward your main rocket engine will give you more control in the lower part of the atmosphere. Like 10 times more than an SAS unit at the top. My theory on your successful one: compared to the probe core, while your cupola is inefficiently placed for control purposes, the sheer power of the SAS unit in it probably made up for it.[/QUOTE] And that's how we get ants, Lana... [img]https://dl.dropboxusercontent.com/u/109944963/ants.jpg[/img] Replaced the RC-001S with the OKTO2, added a Z1k battery, and I was able to make orbit. [url]https://dl.dropboxusercontent.com/u/109944963/CantEverGoBackToArizona.craft[/url] [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] Perversely, the fairing's weight offsets it's aerodynamic advantage, so I find it easier to get a 700 into space without a fairing. Indeed, if I build with one and jetison it during takeoff, the craft immediately becomes easier to control. I think the problem there is that the fairing is bigger than the rocket behind it. This can be countered with larger control surfaces but those also add weight which also helps so ...

[quote name='Snark']Center of thrust doesn't matter much, it's where center of [I][U]drag[/U][/I] is that's the problem. You have a big, light, draggy front end, way out in front of your CoM.[/QUOTE] Yep - so I started out by dropping an anchor chain on the far end. Not literally. Literally, I went out and flew my quadcopter until I parked it in a tree. Then I "dropped an anchor chain" on the end of a rocket. I have no idea what any of that means (apart from the tree bit which is genuine) but it sounds innuendoy. [quote name='Snark']You've got a seriously unstable rocket. Even sticking fins on might not help enough, if they're not far enough behind the CoM. You could help a little with that by sticking a Structural Fuselage in between the engine and the fuel tank and putting the fins down at the bottom of that.[/QUOTE] I tried 1, 2 and 3, to try and give me better balance, but still - 1-2km and *flip* [quote name='Snark']Also, that looks like a Reliant you've got on there? Replace it with a Swivel. The engine gimbal will help you (especially if you move the engine down with a Structural Fuselage as I mentioned).[/QUOTE] I'd tried the swivel (and the vector) which got me to 4k (and 5k, respectively). And then, flip. [quote name='Snark']And if all else fails, you can take it slow for a while until you get up higher. It will mean a less efficient ascent and will be wasteful of fuel, but it will make stability issues easier.[/QUOTE] I often ride the throttle anyway - remember we have better aerodynamic modelling now, and a few quick tests with a clean rocket will prove that riding it all the way at full throttle is *less* efficient than riding it below q (which is perhaps why mechjeb added this in the latest version). Again, look at the station-under-construction I posted, the great big this-is-definitely-not-aerodynamic chunk with the 6-way node, I actually managed to tune to be aerodynamic and launch to orbit and docking by hand. But I [I]cannot [/I]get a damn M700 above 5k. [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='Venusgate']Use the fins, Luke. Trust your (air)foilings. EDIT- Sticking a couple of control surfaces down toward your main rocket engine will give you more control in the lower part of the atmosphere. Like 10 times more than an SAS unit at the top. My theory on your successful one: compared to the probe core, while your cupola is inefficiently placed for control purposes, the sheer power of the SAS unit in it probably made up for it.[/QUOTE] Heh, the launcher for that was a hefty sob. [img]https://dl.dropboxusercontent.com/u/109944963/2015-11-17D-for-derp.png[/img] But I'm pretty sure it worked entirely because of the traffic cone on the top. Anyway - interesting theory. I was going to say "but I don't have an SAS" - and there's the herp. The RC-01S has a built in herp. DERP! Lets try without...

The M700 vexes me. [IMG]https://dl.dropboxusercontent.com/u/109944963/2015-11-17.png[/IMG] No matter what I seem to do, no matter how big or how small I build, I can't seem to launch one. Even MechJeb2 can't do it - I get to about a thousand feet and [IMG]https://dl.dropboxusercontent.com/u/109944963/2015-11-17b.png[/IMG] I've tried with and without fairings, I've tried engines and tanks of various sizes and powers, I've tried riding the throttle and ignoring the throttle. My CoM and CoT look good, so what gives? It has to be something herptastic I'm missing because I was able to launch this single piece [IMG]https://dl.dropboxusercontent.com/u/109944963/2015-11-17x.png[/IMG] to orbit by hand, but I can't get an m700 to space even with mechjeb... :( Does it *have* to go in a cargo bay? Is there some magical effect it has on rockets to force you to do this? My list of addons: KSP: 1.0.5 (Win32) - Unity: 4.6.4f1 - OS: Windows 8.1 (6.3.10586) 64bit Better Science Labs Continued - 0.1.6 Contract Configurator - 1.8.1 DMagic Orbital Science - 1.0.9.1 Editor Extensions - 2.12 EVA Enhancements - 1.0.1 EVA Transfer - 1.0.3 RasterPropMonitor - 0.24 Kerbal Engineer Redux - 1.0.18 KerboKatzUtilities - 1.2.11 ForScienceContinued! - 1.0.4 KSP-AVC Plugin - 1.1.5 SCANsat - 1.1.4.4 SpaceTux: Shared Assets - 0.3.9 SpaceY Lifters - 1.5 TextureReplacer - 2.4.11 +MechJeb 2

[quote name='klesh']Lots of info in that post and probably very well thought out and proper... which leads me to my question, is your name Oliver by any chance?[/QUOTE] Yeah, I'm too lazy to pick a different displayname everywhere - I'd never remember who I am :) (See blog for confirmation) -Ol [COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='Pecan']Someone [URL="http://forum.kerbalspaceprogram.com/threads/139433-Why-aren-t-crash-reports-auto-submitted"]made a thread[/URL] about exactly the same thing just 2 days ago. Oh, it was you. Is it really that important to you that it warrants a second thread as well?[/QUOTE] Presenting it correctly, yes, I take the blame for being sloppy in the original and people just didn't get the question. [COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='Kerbart']In your settings you'd be able to choose from three options: [LIST] [*]Do not send crash reports [*]When a crash report is generated, ask me if it should be sent [*]Automatically send crash report [/LIST] When the game is started for the first time (the flag resets with each update) the user is invited to review his choices and clicking the "review" button opens the settings dialog and shows the above options. That's how this can be done with a minimal of interaction from the player.[/QUOTE] You already get asked if you're willing to have data auto-submitted the first time you run KSP, so it would just be an extension/alteration of that, and presumably we'd all need to be asked the new question. Me - I don't care. This isn't personally identifiable information. But there are people who have genuine reasons not to have a computer on their network trying to send updates someplace.

This is not about getting devs to fix bugs, this is not about trying to store each and every crash report, it is certainly not about trying to violate your privacy and sneakily submit data behind your back. It's about producing stats on crashes (fingerprints) at their end hooked in to the dialog you get first time ("mind if I send some progress data") you run ksp, and the dialog ("the game has crashed, please consider sending the crash report to the game developer [OK]") that pops when you crash the game. If that sounds too magical or not useful enough, read through [B][I]ZOMG That's impossible because ... [/I][/B](otherwise skip to [I][B]TL;DR[/B][/I]) I realize that the crash reports for KSP are polluted with module crashes, gfx driver crashes, and so forth. However the stability of the game itself would still rise significantly above such background noise, and in particular, around release time, Squad should want to see the *shape* of the crash reports to determine if they've unleashed something crazy that's broken everyone but them. For instance, if 30% of your players are crashing because of an AMD driver conflict, you might want to know. To do this, you'd need the client to offer the user the chance to send a few data points: - Client version (a 4-byte or 32-bit number), - Client Platform (a 1-byte or 8-bit number), - Exception type (a 4-byte or 32-bit number), - Exception address (an 8-byte or 64-bit number, you only need 48 bits today and 52 bits by 2020 but lets not fuss about 16 bits) Most users are just going to check the box to let these be submitted automatically, as long as they are shown a simple example of what gets sent, and so no, it doesn't have to become an extra thing to do every time you crash. Or it could be: The default unity crash handler already pops-up when the game crashes and implores you to send your crash report to the developers. It could be tuned to display "You should post your crash report on the forums if it keeps occurring. Would you like to send a crash summary to Squad? [OK] [Cancel]". That's instead of the box you have to click OK in, not in addition to. [B][I]It's a huge amount of data! [/I][/B]I'm not sure what you're thinking of. People can only crash so fast and there's only so many people playing the game. Lets say over the period of 14 days 250,000 players crash 30 times a day. Thats 14 * 30 * 25000 * (17 + 8) where the +8 is to store a timestamp. That's 262,500,000bytes. Ooo, that's a lot! Oh wait, that's 262Mb. That's quarter of a gig over a month. Your niece's website probably stores more data to log all the webcrawlers that visit it. So yeah, you might be talking 3Gb of data over a year, but after about 2-3 months you only need the daily or hourly counts, and I'm pretty sure that the above is a worst-case scenario. It's going to take you a really, really long time to reach 1/10th of a Tb if you do this even moderately smartly. It's a trivial amount of data that gives a game developer a huge insight into the state and stability of their product and can easily be tied into ops-stream reporting to correlate things like "we put out a patch and everyone is crashing". And the non-module crashes will be distinct because they're going to be specific types of crashes with higher frequencies than the module-related crashes. So there's good signal there. It's not hard to do - you simply submit a "GET" request with a parameterized URL, REST style if you want, or a POST with parameters. Beyond that, it's pretty simple. [B][I]Processing all those crashes is a staggering amount of CPU ... [/I][/B] No, it isn't. It's a simple web-handler that logs five values to a database. The crash is already in a machine-readable form on the client, it uses that to [I]generate [/I]the human readable format (output.log) you're thinking of. So we're not talking about building some super-AI that actualy reads the crash report, *sigh*. But maybe you're still thinking that web-servers to handle those crashes are expensive. Nope, probably 2-3 amazon instances would handle it fine - the requests are incredibly light weight and the workload is almost non-existent - write to a database. [B][I]That seems kind of crap and useless [/I][/B] I'm not here to teach you how to be a game developer, but this is the kind of insight that once you have you can't understand how you survived without. Find a game producer of a successful live-development game on Twitter or Facebook and ask them how they'd feel if you took away their automatic crash logging/stats? Now you could also iterate this into something more fancy, like a number of games, and when a particular crash has had 2-3 reports you have the back-end ask the client for the full crash report. Again, user control over whether that happens, but if it's a high-frequency crash, then sooner or later someone will say ok. Once you have more than 2-3 crash reports, you can stop taking reports for that particular crash. But the thing is that now, if you have an interest in a particular crash, you also have some handy crash report instances without having to go to the forums/community. After a few weeks, you delete crash reports that didn't get any traction, keeping the ones that had bugs/tickets assigned to them or were used by developers. It's not "hard" to do, it probably takes a few days to implement the whole thing, and maybe a week or so to tune and get the internal front-end (for viewing the stats) into a useful state, but you can use a lot of off-the-shelf and open-source stuff to implement the vast bulk of it. It's not business criticial so you don't care if some reports get missed, the stats don't have to be perfect, just representative. [B][I]TL;DR: The question[/I][/B] As someone who has worked on/with a number of crash reporting systems, front- and back-end, on a number of games, I'm curious why KSP doesn't auto-submit even the simplest crash-fingerprints for statistics at their end? Is Squad relatively new and just unaware of the value of such a system, or are they just a really small team that doesn't have the resources to develop something so simple (or investigate just how simple it actually is, a lot of people will immediately go to the "that's a ....-ton of data, nobody can handle that" mindset, which is mind-blowingly ridiculous once you actually understand whats involved), or is it just that KSPers aren't going to allow any auto-submission of anything so that it's just not worth doing?

No, you're just trying to implement too complex a solution for the problem. The problem: no visibility of what kind of patterns of crash behavior the development team is causing. Solution: Count them. It's not true that there's an infinite number of addresses that a given build can crash at - it'll only crash at so many locations, even with a stomp or a leak. So - as I teased above, the number of counters you need for a given build is very small. One very, very large MMO I'm familiar with uses less than 50Gb of storage for 11 years of many millions of players automated crash reports. The trick is, they don't store the whole thing every time. They only sample a few so that they have *some* data, and the mass of the rest they just bump a counter. But in order for that to happen, the client has to have the ability to send the crash report. The game already does everything but send the report, and they're using Unity so ... it's a previously solved problem (http://www.jenkinssoftware.com/raknet/manual/crashreporter.html just off the top of my head). Gathering the data is extremely trivial - remember, we're talking summary UPDATE crash_counts SET counter = counter + 1 WHERE platform = ? AND version = ? AND pcr = ? or thereabouts. 1. Write a stored procedure that takes platform#, version#, exception type, and program counter, 2. Have the SP create or increment the plat/ver/exc/pcr counter, 3. Select a cloud and/or web service to host a trivial service that can host a lightweight get-based requester, 4. On receiving a GET and doing basic validation of the request, call the SP, Your choices are: simple, granular counters (e.g. roll counters at the hour) or simply record each crash report as a line item (it's never going to be a lot of data but I'm not getting paid to argue the case, so *shrug*) You could split it into a couple of components: an http request handler and a counter/writer that services a zmq request channel... (Or just write it in go). # HTTP GET handler import json import zmq class Context(object): ctx = zmq.Context() sock = ctx.socket(zmq.PUSH) def __init__(self): self.sock.connect("tcp://counter-master", 10234) # needs timeout def send_count(self, plat, ver, exc, addr): self.sock.send_json({ 'cmd':'count', 'p':plat, 'v':ver, 'e':exc, 'a':addr }) return True def http_get_handler(context, request, keys): try: platform = keys['p'] # 0 = pc, 1 = mac, 2 = linux, etc... version = keys['v'] # 32-bit numeric value exception = keys['e'] # exception code (32-bit value) addr = keys['a'] # program counter (address of crash) except KeyError as e: raise HTTP500("Bugger off, hacker. " + str(e)) try: platform = int(platform) version = int(version) exception = int(exception) addr = int(addr) except ValueError as e: raise HTTP500("You bad hacker, you. " + str(e)) try: if platform < 0 or platform > MAX_PLATFORM: raise ValueError("Invlaid platform") if version < 0x01000000 or version > MAX_VERSION: raise ValueError("Invalid version") if exception <= 0 or exception >= 1 << 32: raise ValueError("Invalid exception") if addr >= 1 << 52: raise ValueError("Valid program counter - if it was 2025") except ValueError as e: raise HTTP500("You're just terribad at this hacking. " + str(e)) if context.send_count() is not True: raise HTTP500("Internal error. You win this time.") return 200, "OK" class Service: ctx = zmq.Context() sock = ctx.socket(zmq.PULL) counters = default(dict) # count by version for various reasons def __init__(self): self.sock.bind("tcp://counter-master", 10234) def run(self): while True: msg = self.sock.recv_json() if msg['cmd'] == 'count': self.count(msg) elif msg['cmd'] == 'flush': self.flush(msg['version'] def count(self, msg): plat, ver, exc, addr = msg['p'], msg['v'], msg['e'], msg['a'] versions = self.counters.get(ver, None) if versions is None: versions = self.counters[ver] = {} verPlats = versions.get(plat, None) if verPlats is None: verPlats = versions[plat] = defaultdict(int) verPlats['{}.{}'.format(exc, addr)] += 1 self.update_database() def update_database(self): # you probably want to mark the record as dirty, # and perform the underlying database commit in a few seconds # rather than immediately, allowing you to batch writes. pass def flush(self, flushVersion): # optimistic approach self.counters = { k: v for k, v in self.counters if k > flushVersion } I didn't spell check that but basically something along those lines. - - - Updated - - - Just about every other game on the planet does this, several game services provide this ability as a built-in. I've not done a good job of addressing my question so that everyone is on the same page: that is, I'm not talking about getting bugs fixed, I'm not talking about sending each and every crash report automatically, nor to some person's mailbox. Indeed, mostly what I'm talking about is using the crash reporter to collect stats. The fact that you could also then collect some small subset of each crash that happens more than N times would mean that the developers would have data on-hand when they need it. As to the size of that data, it's tiny. Radically less than the web-logs for most major websites. And it's not the business end of the system so it doesn't matter if you don't keep every last octet of data. But not having any of it is a problem. What we're talking about is when a new patch goes out. "But mods" - no, you're wrong. Mods will change the crashes, and ultimately what they will want to care about are crashes they introduce during testing and immediately during release. Some of you are thinking of this as a hard direct-to-bug-solving thing, but it's not, it's a "production" issue. What we're talking about is submitting the four key values (platform, version, exception type and pcr) so that they can draw graphs, so that they can tell how stable the current build is, and so forth. Data: In the order of gigabytes for most games after 10 years of collection, Use : Monitoring, not bug fixing - although some games also use it for bug fixing when something spikes really hard, e.g. WoW, Cost: Less than the staff coffee, over time. Difficulty: Well, maybe because I've written something like this for two different games, as well as for two different gaming middleware products, I don't think it's "difficult", but then my wife doesn't thinking it's "difficult" to operate our feking toaster, and I swear she's a witch.

Must be taken up by the other games that do this, then? (EverQuest, DAoC, WWII Online, Blizzard, Eve, have been doing this for over a decade... It's really not hard, and it shouldn't have taken much reading of what I wrote to understand you don't have to store *everything*) If you have a million crash reports, with a platform id, version id, 64-bit address, 64-bit timestamp, and a 64-bit program counter and a 32-bit incident counter... that's 36 bytes per record, so even if you have a million crash reports for a particular build, <drum roll> that's a tiny amount of data by today's standards. 36 million bytes is 34Mb. I'm pretty sure that's not more storage than the entire earth. If you had a billion crash reports for a single build, (a) you're doing it wrong, ( that's 36Gb. Still not more than the entire earth, although it might be more than your PC.

The fact that you imagine it to be harder than it is only speaks to the fact you've not had to deal with it yet. I'm pretty sure that if you were tasked with implementing it you'd quickly realize it's a lot less work than it sounds. You're basically adding mass to the problem and then complaining about the dV required to lift it off the ground. So I'll give you a few starters. - The worst-case RPS is clearly defined: count(players) / maxCrashPerPlayerPerSecond. - The logic is trivial. -- UPDATE crashes SET count = count + 1 WHERE platform = ? AND version = ? AND execption = ? AND pc = ?; -- SELECT IF(count > BETWEEN ? and ?,302,200) AS result WHERE platform = ? AND version = ? AND exception = ? AND pc = ?; - The vast majority of the time you're just handling a GET of "/<platform>/<version>/<exception>/<pc>" based on the parameters in one of the error log files. But how likely is it that you'll experience the critical absolute worst-case scenario? Maybe after patch some large proportion of your players will all play at the same time, but it's rare that more than 10% of the players of a game be playing at the same time. One guy earlier said "there are lots of types of crashes", we're only interested in the types that produce an error.log and then we use the well-defined, well enumerated values that are turned into text in that file. They are: exception type ("KSP.exe caused an Access Violation (0xc0000005)" where c..5 is the exception enumeration) and the program counter ("in module KSP.exe at 0023:005cf31c." where a 64-bit number will handle all the address ranges you need, but you might want to distinguish 32 from 64 bit. I can only speak to how easy it's been to implement at the places I've worked on games in the last 14 years out of my 27 years as a software developer. What I will credit as being "hard" is getting someone on any given team to put together the thing that lets you see the current stats

Once you mind the gap, you never go back.

So, we're not talking about ninja-privacy-violating automatic, we're talking about the system visibly and with user agreement sending the crash reports, and you're not going to lose your job because the corporate firewall catches you submitting a ksp crash dump that you didn't know about.

I find his lack of hair highly aerodynamic. Obviously it creates a sort of videographic slipstream...

It doesn't have to be automatic, which makes it not opt-in or opt-out but actionable. The data submitted would generally be trivial, just enough for them to track "degree of breakage" - how often are we getting crash reports, are they the same crash, etc. Some folks will say "oh no, too many crash types" - no; that's not how it works. If you're getting a million of one crash or 100 of 10,000 crashes, that's incredibly useful data. If you're seeing a million different crashes, you have a stomp. That's why you do either the http or smtp thing, as a filtering process; the server logic decides whether the simple crash submission was enough. So you get prompted: "Hey, I crashed, can I tell Squad this: <1.0.5>/<pc>/<divide by zero>/<0x7fffffffff>?" And sometimes it will say "Great! Squad would like a little more info to help them when they look at this crash, and You've Been Selected. We'll try very hard not to include any personally identifiable data but if you'd just renamed Jeb to Miss Princesses' Little Bunnywabbit we can't guarantee that the text might not appear in the data. Here's what we'd like to send: <more detailed crash logs with some system info, carefully vetted>" They probably only need 3-4 for a given, recurring crash, but then you also don't want it the first time a particular type/addr happens.

Apples and oranges: you don't not go to the grocery store because they sell too many things. Current situation: Dev team has no clue how many of any given crash there is, or what bugs they have introduced, because people don't write bug reports or submit their bugs very often. When a crash *is* identified, it might take a while for them to get good data on it. Alternate situation: After any given period of time, the devs have lots of simple crash data (what type of crash, what memory address, no personally identifying data). So after a release goes out, they can quickly get a sense of "holy crap, everyone is crashing", vs "yeah, there's a few of these", and so forth. When a specific crash becomes a problem, they are highly likely to have a small number of detailed crash reports for it ready to be looked at. This doesn't swamp a dev team, it liberates them. You don't email these reports *to* the dev team, they don't *have* to read them, but not having the data ... is just mind blowing, to me. - - - Updated - - - #1 that's why you want insight into them, #2 no, #3 no. 0/3. Did you even realize I was talking about the crashes that KSP's current crash-handler catches with the little "hey, send my crash log" messagebox? - - - Updated - - - Right now, when the game crashes, it writes everything to a file and then displays a little MessageBox telling you to send in the crash report. So instead of displaying that, that's where you write a traditional "hey, I'd like to send this crash report for you, here's the data I'd send". And in the majority of cases you're just going to send a few utterly unidentifiable data points - exception type, address, possibly the a register dump, but probably not. Just the sequence of: <version>/<platform>/<crash type>/<address> and a counter for that so that at a glance you can see what types and numbers of crashes you're getting can be incredibly helpful. If you're getting crashes all over the place then it's still useful data for someone working the producer role. If you're not, then you have valuable data telling you what issues and what degree you have to help you balance debug vs develop. - - - Updated - - - Taken as read, sorry for not stipulating.

[The original post asked the question sloppily so I rewrote it in hopes that communicating the question better might nix some of the confusion apparent in the thread. I'd posted this as a separate thread but they got merged as of page 3] This is not about getting devs to fix bugs, this is not about trying to store each and every crash report, it is certainly not about trying to violate your privacy and sneakily submit data behind your back. It's about producing stats on crashes (fingerprints) at their end hooked in to the dialog you get first time ("mind if I send some progress data") you run ksp, and the dialog ("the game has crashed, please consider sending the crash report to the game developer [OK]") that pops when you crash the game. If that sounds too magical or not useful enough, read through ZOMG That's impossible because ... (otherwise skip to TL;DR) I realize that the crash reports for KSP are polluted with module crashes, gfx driver crashes, and so forth. However the stability of the game itself would still rise significantly above such background noise, and in particular, around release time, Squad should want to see the *shape* of the crash reports to determine if they've unleashed something crazy that's broken everyone but them. For instance, if 30% of your players are crashing because of an AMD driver conflict, you might want to know. To do this, you'd need the client to offer the user the chance to send a few data points: - Client version (a 4-byte or 32-bit number), - Client Platform (a 1-byte or 8-bit number), - Exception type (a 4-byte or 32-bit number), - Exception address (an 8-byte or 64-bit number, you only need 48 bits today and 52 bits by 2020 but lets not fuss about 16 bits) Most users are just going to check the box to let these be submitted automatically, as long as they are shown a simple example of what gets sent, and so no, it doesn't have to become an extra thing to do every time you crash. Or it could be: The default unity crash handler already pops-up when the game crashes and implores you to send your crash report to the developers. It could be tuned to display "You should post your crash report on the forums if it keeps occurring. Would you like to send a crash summary to Squad? [OK] [Cancel]". That's instead of the box you have to click OK in, not in addition to. It's a huge amount of data! I'm not sure what you're thinking of. People can only crash so fast and there's only so many people playing the game. Lets say over the period of 14 days 250,000 players crash 30 times a day. Thats 14 * 30 * 25000 * (17 + 8) where the +8 is to store a timestamp. That's 262,500,000bytes. Ooo, that's a lot! Oh wait, that's 262Mb. That's quarter of a gig over a month. Your niece's website probably stores more data to log all the webcrawlers that visit it. So yeah, you might be talking 3Gb of data over a year, but after about 2-3 months you only need the daily or hourly counts, and I'm pretty sure that the above is a worst-case scenario. It's going to take you a really, really long time to reach 1/10th of a Tb if you do this even moderately smartly. It's a trivial amount of data that gives a game developer a huge insight into the state and stability of their product and can easily be tied into ops-stream reporting to correlate things like "we put out a patch and everyone is crashing". And the non-module crashes will be distinct because they're going to be specific types of crashes with higher frequencies than the module-related crashes. So there's good signal there. It's not hard to do - you simply submit a "GET" request with a parameterized URL, REST style if you want, or a POST with parameters. Beyond that, it's pretty simple. Processing all those crashes is a staggering amount of CPU ... No, it isn't. It's a simple web-handler that logs five values to a database. The crash is already in a machine-readable form on the client, it uses that to generate the human readable format (output.log) you're thinking of. So we're not talking about building some super-AI that actualy reads the crash report, *sigh*. But maybe you're still thinking that web-servers to handle those crashes are expensive. Nope, probably 2-3 amazon instances would handle it fine - the requests are incredibly light weight and the workload is almost non-existent - write to a database. That seems kind of crap and useless I'm not here to teach you how to be a game developer, but this is the kind of insight that once you have you can't understand how you survived without. Find a game producer of a successful live-development game on Twitter or Facebook and ask them how they'd feel if you took away their automatic crash logging/stats? Now you could also iterate this into something more fancy, like a number of games, and when a particular crash has had 2-3 reports you have the back-end ask the client for the full crash report. Again, user control over whether that happens, but if it's a high-frequency crash, then sooner or later someone will say ok. Once you have more than 2-3 crash reports, you can stop taking reports for that particular crash. But the thing is that now, if you have an interest in a particular crash, you also have some handy crash report instances without having to go to the forums/community. After a few weeks, you delete crash reports that didn't get any traction, keeping the ones that had bugs/tickets assigned to them or were used by developers. It's not "hard" to do, it probably takes a few days to implement the whole thing, and maybe a week or so to tune and get the internal front-end (for viewing the stats) into a useful state, but you can use a lot of off-the-shelf and open-source stuff to implement the vast bulk of it. It's not business criticial so you don't care if some reports get missed, the stats don't have to be perfect, just representative. TL;DR: The question As someone who has worked on/with a number of crash reporting systems, front- and back-end, on a number of games, I'm curious why KSP doesn't auto-submit even the simplest crash-fingerprints for statistics at their end? Is Squad relatively new and just unaware of the value of such a system, or are they just a really small team that doesn't have the resources to develop something so simple (or investigate just how simple it actually is, a lot of people will immediately go to the "that's a ....-ton of data, nobody can handle that" mindset, which is mind-blowingly ridiculous once you actually understand whats involved), or is it just that KSPers aren't going to allow any auto-submission of anything so that it's just not worth doing?

Shouldn't need recompiling, just needs the ".version" file changing to include 1.0.5 so that kcan etc will see it as compatible.

SA intercepts transmissions so that while data is being shipped it doesn't re-detect it as absent. Unfortunately, the API for sending data changed from taking a single item to transmit to taking a list of items to transmit. I tried to fix this myself in the SA code, but there's a bunch of stuff not included in the repos that you can't build without, and it looks like he hasn't checked in the debugtools in a while or something because the ones I found didn't match the ones he tries to compile against, so ... - - - Updated - - - Also the warp-interrupt doesn't appear to be working in 1.0.5.

Also ScienceAlert doesn't think there's any science to be had from the parts.