steve_v

May 7, 2016

1 hour ago, KocLobster said:

Squad's upper management is probably never going to allow enough time for that to ever happen.

Indeed. This was a dig at said management, not the devs per-se. Just like the 1.1 wasn't ready bit.

1 hour ago, KocLobster said:

Don't let them know it's you; I'd expect you'd be banned.

No kidding, which, aside from it being a pointless exercise anyway, is why I haven't.

1 hour ago, KocLobster said:

Better yet, maybe find something more constructive?

Like? As I don't have the requisite level of access or source code, I can't fix this.

May 7, 2016

10 minutes ago, mcirish3 said:

^^knows patcher been broken for a year... still tries to use it.

Let me fix that for you: ^^knows patcher been broken for a year... ~~still tries to use it.~~ Spends more time investigating issue than Squad does, apparently. Is getting tired of Squad releasing obviously broken software.

4 minutes ago, mcirish3 said:

Perhaps e-mail squad tech support every day till they fix it.

Good idea. I'm thinking a script that runs the patcher continuously and emails on every failure though... that would be more like 1 mail per minute.

6 minutes ago, mcirish3 said:

same solution. DOn't use the patcher.

Not a solution. A workaround perhaps, but not a solution, especially not for those on slow connections.

Solution: Squad fixes patcher, or removes bait from launcher. Squad starts properly testing software before making available to customers.

May 7, 2016

2 hours ago, mcirish3 said:

By now everyone should know that the patcher is broken so regardless of you opinion DON'T USE IT, since you know it won't work.

So it's perfectly reasonable to put a giant "Update" button on the official launcher that does nothing but corrupt your install? Dunno about you, but this strikes me as more than a little unprofessional. Even more unprofessional than leaving an "Update" button in the launcher when it does nothing - which is what we had for the last year.
Like I said, there's nothing wrong with using rsync to update the game, it works just fine when done locally.

How Squad could fumble this one really boggles the mind. Leaving it in a state where it practically begs to be used, and with no warning that it will bork your install is either incompetence or outright laziness.

Squad: <places candy in front of child> "This is official Squad candy, go ahead, perfectly safe" What, exactly, do you expect to happen here?
It's only us cynical old codgers (who have seen Squad screw this up before) that will approach this with the requisite level of suspicion. For everyone else, it's just "Your patcher broke the game, WTH?"

I use rsync on a regular basis, not only do I use it to clone copies of KSP, I also use rsync to back up and restore complete operational servers, including terabytes of data. By comparison, patching the game should be easy. Give me access to the sync server and auth system and I will gladly fix this mess.

---

Again, as far as I can tell, there's nothing wrong with the patcher. It's the sync server that's dishing up the wrong files.

May 5, 2016

23 minutes ago, linuxgurugamer said:

Patcher DOES NOT WORK, you need to download the whole game unless using Steam

IME, it worked for 1.1 -> 1.1.1, but it chokes on 1.1.1 -> 1.1.2, it's not transferring all the changed files, or the source is not actually 1.1.2.

Quote

I think the patcher was intended to be more of a torrent patcher than an rsync patcher

Snipped from patcher.log:

[INFO    ]: Detecting if OS-resident rsync is present...
[INFO    ]: rsync present in PATH, residing at: /usr/bin/rsync
...auth stuff...
[INFO    ]: Opening connection to kerbalspaceprogram.com:873 with transport RSYNC...
[DEBUG   ]: /usr/bin/rsync -zrav --progress -p rsync://[redacted]@kerbalspaceprogram.com:873/kerbalsp.production/KSP_linux/ "/home/steve/Games/KSP_linux"
...bog-standard rsync progress output...
[WARNING ]: rsync process has exited normally.  <-- Why is this a warning?
[INFO    ]: KSP was patched successfully, click the ok button to close this application.

Sure looks like rsync to me, but I could just be trippin.

---ed.
Invoking rsync locally (and adding checksum comparison, it's silly not to) like: "rsync -zravc --progress -p ./1.1.2/ ./1.1.1" works just fine, so rsync is likely not the problem, rather the files at kerbalspaceprogram.com/kerbalsp.production/KSP_linux/. Based on what the local run finds, (far more that needs syncing) the issue is on Squads server.

May 5, 2016

5 hours ago, Azimech said:

If they have the server capacity and software to automatically analyze, an automatic CTD log uploader might be an interesting concept.

Err, you're seriously suggesting this to an outfit that, apparently, can't figure out rsync? Good luck.

May 5, 2016

2 hours ago, LordFerret said:

15 minutes into a brand new sandbox game in v1.1.2 and I'm hit with this AGAIN in the VAB...

Never even made it to the launchpad.

I have no more words at this point.

Intermittent crashes here too. I do believe I have said my words on this. But I'll say it one more time for completeness: Progress fixing this: nil. Bug reports (with stack traces etc.): no comment from devs, besides the standard "Unity problem". Game still crashing randomly. Not impressed.

To quote a certain staff member: "It's on the tracker already but I think this one may need to be posted to the Unity forums as it seems to be an issue in the libmono bundled with Unity."

Seriously? since when is punting bug reports upstream the players job? We bought Kerbal Space Program, not Unity Tech Demo.

May 4, 2016

FWIW, the patcher borks Linux installs too (see startup error further up the thread). The patcher itself (and rsync) produce no log errors and the process completes "successfully". I don't know exactly what lives at rsync://kerbalspaceprogram.com:873/kerbalsp.production/KSP_linux/, but I'm fairly certain it's not a complete 1.1.2. This worked fine for 1.1.0 -> 1.1.1, perhaps somebody forgot to update the sync server...

A more minor issue is that it also removes the executable flag from KSP.x86_64. Did anyone actually test this thing before letting it out into the wild again? Sure doesn't look that way to me.

For those with slow connections (mine is slow-ish too), I feel your pain. That said, manually rsyncing an unpacked 1.1.1 -> 1.1.2 (which works fine) pulls about 400MB, so less savings with this patch than the last one. Still 50% smaller download though. Better could probably be achieved with binary deltas, though that's more work to set up than rsync.
Rsync is easy, come on Squad, if I can rsync patch 1.1.1 to 1.1.2 without breaking things so can you.

May 2, 2016

1 hour ago, basic.syntax said:

They had to put a band-aid on the wheel clipping bug, or craft would have exploded en masse.

If craft are exploding en-masse due to a physics engine bug, fix the physics engine bug, call in someone who can, or just don't release until it's sorted.

I'm actually not too disgusted by the hacky fix for explode-on-load clipping, but all the band-aid fixes so far have introduced new problems, and none of them address the real (and common to all the wheel related bugs AFAICT) cause.
The latest "autostrut" band-aid for bouncing and jittering is already shaping up to be a can-of-worms, particularly for mods like IR, and I'm not convinced this is better than the previous jello suspension "fix" TBH.

Gear and landing legs still react violently or explode if faced with a sudden change in terrain height (or a kerbal for that matter), softening the suspension won't fix this, strutting things won't fix this. Endless mucking with module parameters won't fix this either. It's an engine bug, stop buggering about and fix it properly. If that requires another Unity upgrade, so be it.

That's just wheels (and those were advertised as being "way better" than 1.0.x). What about the crashing? Or the graphical FUBARS in the VAB and elsewhere? (esp. on Mac) What about windowed mode being totally broken on GNU/Linux, to the point that its random window geometry shenanigans stalls my window manager? There are more.

The real kicker: What about the ~1300 open bugs on the tracker? This number is still increasing, and most of the serious ones are from the pre-release. What is the point of doing a pre-release at all, if you don't actually fix the bugs it reveals?

May 2, 2016

1 minute ago, evilwombat said:

It's a patcher problem.

Thanks.
I actually figured that one out some time ago - after the apparently untested patcher screwed up a second install in the same way.
[sarcasm]My point in posting that was to illustrate the awesomely smooth and bug-free experience KSP hotfixes offer.[/sarcasm]

May 2, 2016

The answer to the ongoing Unity3D SNAFU is rather simple, IMO.

If Unity bugs keep screwing up releases, bear this in mind and stop making promises you cannot keep or committing to release dates you cannot meet.
If you get shafted by Unity bugs at the 11th hour, come out and say it how it is: The engine version we targeted has a bunch of bugs we can't fix, we're going to have to stay in beta / delay release until it's sorted.
I won't complain, promise.

The thing is, your customers didn't purchase a Unity tech demo, they bought a released game - so often they either don't know (it's not advertised on the store, is it?) or don't care what game engine you are using or how buggy it is. And they shouldn't have to.
KSP is marketed as a standalone game, so all bugs are treated as KSP bugs. This is to be expected, and releasing with serious bugs just makes you look like a bunch of amateurs, no matter how valid your reasons are.
All the end-user sees is a buggy, unstable product, and this is exaggerated by the excessive hype over shiny new stuff that, come release day, doesn't work properly.

My gripes with 1.1 all come back to releasing a buggy build as the real deal. When a new major version is released with all the accompanying fanfare (and a half dozen exclamation marks) I fully expect to be able to start playing it immediately, without crashes or obvious bugs, and without convoluted workarounds.
Most certainly without rapid-fire, disruptive "hot fixes" that don't even address the underlying problems.

Just how many band-aids do you intend to stick on the physics / collision / wheels & legs issue anyway? Applying temporary hacks that don't fix the actual cause of the problem isn't a particularly productive use of time and resources IME.
The original problem will just crop up somewhere else, and I dunno about you, but I thoroughly dislike playing endless whack-a-mole whilst working to a deadline.

If anyone decides to build a similar game on an engine that isn't a giant-flaming-turd, I am going to take my custom over there. If OTOH Squad ever decides to do a release that isn't broken on day one - even if that means delaying said release by months to deal with engine bugs - I'll gladly wait around for it.

Right now, I'm going back to the apparently bug-free (not KSP, obviously) game I was playing before this "1.1 is out" false alarm. Wake me up when this one is fixed.

May 1, 2016

9 minutes ago, mcirish3 said:

Windows is the majority so ya, kinda.

If you advertise the product as being ready for release, it needs to work right. If you advertise the released product as running on MacOS X, it needs to work right on MacOS X. :rolleyes:

If it only runs properly (ish) on 2/3 supported platforms it's only 2/3 functional, and that's not ready for release in my book.

AFAICT this one is a Unity bug, which makes it "not Squads fault". It does not, however, make it "not Squads problem".

May 1, 2016

Just now, mcirish3 said:

Mac users are a small minority of KSP players, so they may ahve a legit grip but Linux? As a windows users I felt for the longest time that Linux users got all the attention.

KSP / Unity4 was a bit of an exception to this rule, primarily due to GNU/Linux being the only platform with a stable 64bit player. Now that Win64 is a thing, I expect it to go back to the norm.

May 1, 2016

1 minute ago, SOTMead said:

I was gonna say Pak'ma'ra, but that works too

Well, this certainly puts Mac owners culinary habits in a new light... :wink:

You're not alone, I've been running GNU/Linux for long enough to realise that any "Doesn't occur on Windows" issue is automatically a low priority one.

May 1, 2016

1 minute ago, mcirish3 said:

Dude, we told them this, at the time they did not listen, I am not sure the dev team even had a say in the matter, the business unit may have forced it...

Indeed, and this is why it irritates me so. Seems to me like whoever is pushing the release schedule has no idea what they're doing, or simply puts hype and profits before product quality.

5 minutes ago, mcirish3 said:

...nothing can be done about the past.

Except learn from it, and avoid making the same mistake twice. Or in this case, 3 times.

May 1, 2016

35 minutes ago, AdmiralTigerclaw said:

---snip---
long-winded "software is complicated" spiel
---snip---

Yeah, modern software is complicated, and the plumbing analogy is poor. This is still not a valid excuse for labelling software that doesn't work properly as release-worthy.

If any professional installs a new factory automation system / power grid / city-wide plumbing network / repairs your TV / upgrades your PC etc. etc. the customer is entierely justified in expecting it to work properly when it's called "ready for use", shrink-wrapped and delivered. If it doesn't, the customer is equally justified in demanding said professional come back and fix it, or call in someone who can.

Granted KSP has already done a "1.0" release, so they have no legal obligation to provide more bugfixes - but rewarding those who participated in early-access (with the implicit promise that they get a finished, stable, working game someday) by pushing out one broken update after another, post release, is a clear violation of Wheatons Law.
Seems to me game developers work to an entirely different quality standard than the rest of us pros.

If the current release had a big fat "beta testing version, see the bugtracker for ongoing issues" warning I would be quite happy, but it's labelled as release-ready, so I expect it to work properly. After all the hype over the new wheel system, it's a real let-down to find it's more broken than it ever was. Random crashes are simply unacceptable, in any released software.

May 1, 2016

12 minutes ago, Azimech said:

I had a bad feeling when the news came 1.1 was coming out of prerelease ... much too early.

My thoughts exactly. So far this is shaping up just like the 1.0 release mess: Release early, rush a bunch of hotfixes, go on holiday, return and push more patches.

My experience, with projects that don't release buggy builds unless clearly stated as a beta or RC, is that releases are ready when the serious bugs are addressed and no new ones are being reported. The open bug count on the tracker is still increasing, the game still crashes at random, and the landing legs are still bugged.
QC anyone?

If this continues, we might finally get a 1.1 release that works properly as a "stopgap" shortly before 1.2 enters experimentals... just like last time.

May 1, 2016

As if the continued crashes were not annoying enough, I can now confirm that at least one stock landing leg is still borked (jumps, explodes if walked into). In fact leg/surface collisions still appear to be borked in general. Bug reported, but I'm getting pretty fed-up with this TBH. This stuff is what the prerelease was for.

May 1, 2016

On modded games:

Remember the Win64 controversy?
Remember the mod support nightmare from users reporting unpredictable stock game-engine instability as "bugs"?
Now, imagine that it's not just one build that's unstable, it's like this on every platform...

Yes, mods will probably aggravate issues, but managed (mod) code simply shouldn't be able to crash the game this way.
If it's faulting with errors from glibc and a native stack trace, as it is on GNU/Linux, then it's NOT mods at fault - it's almost certainly a thread-safety or memory-management issue in Unity. I suspect this is the same bug as is causing those ntdll traces on Windows too.

Like any sensible person I have multiple installs. My stock install crashes, on average, just as often as a heavily modded one, with the same stack trace in the log.

I had stock 1.1.2 crash to desktop (double free or corruption (out)) within 5 minutes of starting it up for the first time. This has not improved since 1.1.0 at all.

Mod authors will likely still get the reports for these stock bugs though.

April 30, 2016

1 minute ago, Psycho_zs said:

I've got the same thing.

Fresh DL works for me, guess the patcher screwed something up. Why am I not surprised at this. :rolleyes:

April 30, 2016

Just now, Steel Dragon said:

Nope just had a BSOD from the VAB

Ditto, though without the blue bit. Linux build still randomly crashing to desktop.

April 30, 2016

Ok, just patched my (working) 1.1.1 up to 1.1.2, result:

./KSP.x86_64 
Set current directory to /home/steve/Games/KSP_linux-testing
Found path: /home/steve/Games/KSP_linux-testing/KSP.x86_64
Mono path[0] = '/home/steve/Games/KSP_linux-testing/KSP_Data/Managed'
Mono path[1] = '/home/steve/Games/KSP_linux-testing/KSP_Data/Mono'
Mono config path = '/home/steve/Games/KSP_linux-testing/KSP_Data/Mono/etc'
displaymanager : xrandr version warning. 1.4
client has 4 screens
displaymanager screen (0)(HDMI-0): 1920 x 1080
Using libudev for joystick management


Importing game controller configs
PlayerInitEngineNoGraphics settings: Could..... not preload global game manager #0   i=0
Failed to initialize player

On STDOUT, no game. Really guys? No log either.

April 30, 2016

15 minutes ago, Renegrade said:

I'm still getting some rather large phantom forces from stations with docked landers (this actually started in 1.1.1). My 1.0.5 testing seems to indicate this wasn't a thing back then.

Ahh, so it is landing legs causing this, I was wondering what was going on. I'll second the "not a thing in 1.0.5" too.

April 30, 2016

2 hours ago, KocLobster said:

Did 1.0 have as many critical bugs/crashes/CTDs when it was first released as 1.1 has? The CTDs I experience, especially in the VAB, make it literally impossible to play. I can't help but crash within 5 minutes of entering the VAB.

IME: Bugs yes, instability and crashing no.
Prior to 1.1, I had zero crashes, even pre-beta, at least as far back as 0.21. Now I can expect it to crash hard once every 1-2 hours.
If you're coming from 32bit out-of-memory crashes on Windows, 1.1 might be a stability improvement.
For me, coming from a perfectly stable 64bit (GNU/Linux) game, this is rather disappointing TBH.
Unity minor version upgrade is happening when?

April 20, 2016

18 minutes ago, CattyNebulart said:

I'm not a steamer, so no access to 1.1 before this, but I'm sorely disappointed with KSP not even starting, hitting several startup breaking bugs (3 of them!) before even being able to make a game. I was able to work around them with persistence and editing of config files, this is not something I expect most people to be able to do, and more to the point this is not something that should be acceptable. 3 critical game breaking bugs at startup, that is acceptable in pre-release not in the real release.

Very close to my own experience, though in my case the number of fails-to-start issues was (2). Workarounds employed and all is mostly well, but issues like these make for a less than optimal first impression, especially for such an anticipated release.

Largely positive reception, excepting the usual game-engine bugs.

March 28, 2016

Quote

The pre-release branch will be opt-in via Steam only, and won't be available via the KSP Store.

:mad:

Quote

given the frequency of builds, the size of those builds, and the necessity for everyone to be on the latest version for testing it proved to be impossible

Fix your damn "patcher" then - this is exactly what it's suited for. As it stands the KSP launcher/patcher is utterly pointless... and it's been that way for ~a year now.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Article Comments posted by steve_v