Jump to content

Beta Testing Volunteer


XLjedi

Recommended Posts

On ‎9‎/‎9‎/‎2019 at 11:13 PM, Cheif Operations Director said:

All I am detecting is a passive aggressive person right now who is trying to prove superiority at craft building or something, perhaps I am misreading the situation. Either way to quote myself again. 

 

7 hours ago, XLjedi said:

Well...  yeah, I know.  I have a tutorial that might help you to correctly setup your propellers.  Not sayin it's perfect, or you need to follow it, but you might find it interesting.

 

Perhaps I am misreading the situation again, who knows :rolleyes:

Link to comment
Share on other sites

17 hours ago, sturmhauke said:

Eh, I dunno about that. I was a tester on various versions of The Sims and Battle for Middle Earth II, and still played the crap out of those.

If you don't mind my asking...  what was the process like for being selected as a tester in your case?  Did you apply to a request  for testers near launch?

Link to comment
Share on other sites

2 hours ago, XLjedi said:

If you don't mind my asking...  what was the process like for being selected as a tester in your case?  Did you apply to a request  for testers near launch?

No, it was a regular, full time job. I worked on lots of stuff, whatever came through for testing, not just those. I applied through the company website (EA in this case).

Link to comment
Share on other sites

17 minutes ago, sturmhauke said:

No, it was a regular, full time job. I worked on lots of stuff, whatever came through for testing, not just those. I applied through the company website (EA in this case).

Ah... OK.   Did they have any voluntary testers?  ...or have you seen any cases like that?  

(aside from broad "early access" crowd funding schemes)

Link to comment
Share on other sites

5 minutes ago, XLjedi said:

Ah... OK.   Did they have any voluntary testers?  ...or have you seen any cases like that?  

(aside from broad "early access" crowd funding schemes)

They would sometimes do focus group testing, which is less about finding bugs and more about getting general impressions from the target demographic. But usually for that sort of thing you have to live near the company office, or the agency doing the focus group.

Public beta testing for online games is mostly about stress testing the servers, to try to find weak spots before it goes live. Established games like Overwatch will also use it for trying out game mechanics (new characters, balance patches, etc.) and getting feedback.

Link to comment
Share on other sites

@sturmhauke Seems to be a long-shot at best then... 

I do cringe when I see the flaming posts following any game release or update criticizing the devs for the perceived "lack of any sort of beta testing". 

Some things just seem so painfully obvious that I have found myself wondering, "Did you even try to play your own game?"  (not pointing a finger at KSP in particular here)

I do wish them well and hope for a successful (minimal bug) launch.  I can also see from their POV though, that maintaining an air of secrecy and excitement may very well outweigh a bug free launch.  ...and even if you do have beta testers, there will always be bugs that slip through.      

Edited by XLjedi
Link to comment
Share on other sites

3 minutes ago, XLjedi said:

@sturmhauke Seems to be a long-shot at best then... 

I do cringe when I see the flaming posts following any game release or update criticizing the devs for the perceived "lack of any sort of beta testing".

Yeah, game industry jobs are tough to get. And as a former QA tester, that attitude really grinds my gears. A lot of those criticisms are just blown out of proportion and turned into a hate train. And while there are sometimes actual buggy messes that get shipped when they shouldn't, that's ultimately a management decision. No self-respecting dev or tester likes stuff going out the door in that state, but they don't always have a choice.

Link to comment
Share on other sites

@sturmhauke

As for game industry jobs...  I've heard you can make literally hundreds of dollars working in the game industry!  LOL

I do envy the folks who can do that work and get paid a decent amount.  I personally, could not afford to do that type of work.  The competition is so high, and the work is... well...  it's fun, right?  So you have very talented folks who are willing to work for next to nothing.  I've got 2 kids in college right now, with a 3rd about to start.  So unless one of the publishers wants to hire me as their CFO, I don't see me being able to change jobs anytime soon.

I do have on my bucket list, maybe one day when I retire, to turn my attention once again to developing applications (or more likely games) to distribute on Steam or some other forum, just for the fun of it.

Edited by XLjedi
Link to comment
Share on other sites

41 minutes ago, XLjedi said:

The competition is so high, and the work is... well...  it's fun, right?  So you have very talented folks who are willing to work for next to nothing. 

That's possibly the worst thing about the game industry - it can be exciting and frustrating, fun and exhausting, rewarding and crushing, all at once. It's definitely intense.

Link to comment
Share on other sites

On 9/9/2019 at 6:39 PM, XLjedi said:

who is Star Helix?  did I miss a deleted post?

"Star Helix" is what a fan of The Expanse might absent-mindedly call Star Theory (developer of KSP2) by accident, I believe.  ;)

23 hours ago, sturmhauke said:

Game companies don't generally do external beta testing except for online-only games like MMOs, and even then it's usually pretty close to launch. This is so they can control the release of game information as much as possible. Even with NDAs, information can and does still leak.

Sure, though that also depends on a lot of variables including how "sensitive" the release is.  For example, KSP 1 does have external beta testing for a small group of external NDA'd volunteers (I hasten to add that it's closed and they have everyone they need at the moment, so please don't go hammering on their doors asking to get in, folks).  But what they're beta testing is stuff that's already been publicly announced to some degree (i.e. after a release has been announced, even if all the details of the release haven't been made public yet), such as point releases, so the information isn't super "sensitive" and therefore the company's risk is lower because a confidentiality breach wouldn't be as catastrophic.

Whereas I would imagine that for a brand-new release like KSP 2 where there's a lot more secrecy involved-- and a lot more at stake, given that it doesn't have an established market yet-- I would guess they'd be less likely to do that.  Just a guess, though, obviously there's no way to know unless they say.  ;)

23 hours ago, MechBFP said:

You should really only beta test games you have no intention of playing after. It truly kills the game for you. 

Depends.  The beta-testing for KSP 1 releases allows people to help improve the game (not just finding bugs, but providing usability feedback and such), which can be satisfying.

22 hours ago, sturmhauke said:

Eh, I dunno about that. I was a tester on various versions of The Sims and Battle for Middle Earth II, and still played the crap out of those.

^ This!

Certainly being a full time game tester as primary employment can be very draining and challenging-- it's really not "whee, I get paid to play video games!", as a fair number of folks seem to think.  But being a beta-testing volunteer takes a lot of the pressure off, in my experience.  It's pretty laid-back and low-stress.  (But it's also not the same thing as "whee, I get to play the game before everyone else"-- it's a different kind of thing and requires a particular set of personal motivations that are not simply "enjoy playing the game".)

 

2 hours ago, XLjedi said:

Did they have any voluntary testers?  ...or have you seen any cases like that?

KSP 1 has had it for quite some time.  But as I mention above, it's a small, closed group and they invite people when they think they need more, so please don't go hammering on their doors.  ;)

Link to comment
Share on other sites

2 hours ago, XLjedi said:

I do wish them well and hope for a successful (minimal bug) launch.  I can also see from their POV though, that maintaining an air of secrecy and excitement may very well outweigh a bug free launch.  ...and even if you do have beta testers, there will always be bugs that slip through.

Careful, there-- there are a couple of spots where I think you may be making some inaccurate (though understandable and common) assumptions about how things work.  In the following, please forgive me if I appear to be putting words in your mouth.

 

Apparent assumption #1:  "Having a beta program" = "fewer bugs on release"

Not the case, at least not necessarily.

What gives fewer bugs is testing.  There are different ways a company can test.  They can have their own dedicated QA people, i.e. full-time paid employees whose job it is to test the product.  Every company is going to have that; it's simply not an option to ship without your own testing, that would be a guaranteed train wreck.

A company may choose to also do beta testing outside the company's own staff.  This might be something small / restricted / NDA'd, like what KSP has been doing for the last couple years.  Or it might be something big and wide-open, like what KSP used to do back in the days of "Experimentals".  Or something in between.

The choice to do a beta like that isn't a no-brainer.  It's not simply a matter of "more people in beta means you'll ship with fewer bugs".  Because open betas aren't "free" to the company, even if the people participating aren't being paid.  Here's the tradeoff of doing an open beta:

  • Pro:  You get more eyeballs on the product, and you don't have to pay those eyeballs.  Also, typically these are players who are (hopefully) a good representative sample of what the actual players of the game are like, so it helps to "keep it real".
  • Con:  They're not professional QA testers.  Testing is a skill, requiring technical expertise.  It's an engineering discipline every bit as much as actual code-writing.  So the bug reports they generate aren't going to have the same quality as bug reports from dedicated testers; and a bug report from a beta participant is still going to need to be vetted and reproduced by an in-house staff tester.  And since the bug reports are likely to be of lower quality, it potentially could end up taking up more of the QA staff's time (to do the vetting) than if they'd just had the QA staff do the testing in the first place.  Also, the open beta people are going to tend to just meander freely about the game, instead of rigorously testing each section in a diligent and methodical fashion, which can sometimes be helpful (i.e. opportunity for serendipitously discovering things), but also means it's easier to have "holes" that nobody happens to look at.

So when a company decides not to do a public beta, it's not because they don't care about bugs, or that they're willing to ship with more bugs.  Having a beta does not, in itself, necessarily reduce bugs.  It's simply a tradeoff of "how do we want to find our bugs?  with professional but expensive staff, or with free but untrained volunteers?"  It's a tradeoff of "how do we want our QA staff to spend their time-- directly testing/reporting themselves, or wading through bug reports from untrained volunteers?"

It's very much not a no-brainer, and which way is "better" depends heavily on context.  It's a case-by-case thing, and has to be.

 

Apparent assumption #2:  Any bug that's found, will be fixed.  If you ship with bugs, it's because they weren't found.

Not the case, at least not always.

Certainly nobody wants to ship with bugs, and certainly there are indeed bugs that do in fact "slip through" (in the sense that nobody noticed them before release, and they come as a nasty surprise after shipping).

But it's also the case that some bugs are deliberately not fixed, for a variety of good reasons.  The two main reasons for deliberately not fixing a bug generally have to do with two things, cost and risk:

  • Cost:  Suppose a bug is a pretty minor edge case, but would be huge and expensive to fix in terms of engineering time.  You could have some minor cosmetic issue that doesn't bork gameplay, or some race condition that happens very rarely and can be worked around when it happens.  If fixing that bug would take weeks of work (and maybe require slipping a ship date, or neglecting other more important fixes)... better to just ship with it in there, and maybe mark it for fixing in a patch release later or something.
  • Risk:  Code is complicated and densely interconnected.  Any time you touch one thing, you take the risk of breaking something else.  Some bugs are low-risk to fix because they involve code that's fairly "standalone" and other stuff doesn't depend on too much.  On the other hand, some areas of code are more sensitive, and touching them at all can be very risky, because you can invalidate many weeks of testing that went into the current behavior and could have to re-test everything again and maybe cause other breakages elsewhere that you end up not catching before releasing.

It may help to think of it in terms of a medical analogy:  There are some medical conditions that you might deliberately choose not to treat, either because the cost of the procedure would be exorbitant relative to the benefit ("we can remove that inconspicuous mole for you, but it'll cost you $10,000 out of pocket"), or because it would introduce other risks that are dangerous ("we can fix that minor pain that occasionally annoys you and that you usually just take an ibuprofen for, but there's a 5% chance that the surgery will kill you").

 

Link to comment
Share on other sites

1 hour ago, Snark said:

Certainly being a full time game tester as primary employment can be very draining and challenging-- it's really not "whee, I get paid to play video games!", as a fair number of folks seem to think.

Well yeah. But in my case, I was both a full time QA tester and a game junkie. It also helped that both of those examples were high profile and in testing for a bit longer than usual, so we had a little more freedom to screw around and try to find weird edge cases. And also do 4 way free-for-all battles.

Link to comment
Share on other sites

@Snark  On assumption 1, I think it's a fair assumption.  ...or at least skewed more heavily to the side of less bugs, than no bugs or more bugs as a result.  I would consider your "not necessarily" to be inline with this.  Agreed, the probability is not 100%, but it ain't 50/50 either.

QA/QC will no doubt produce fewer bugs at launch.  That's a pretty fair assumption vs. nothing.  ...how you go about it is a different story of course.  I imagine a volunteer or very selective beta-test program would produce valuable feedback and squash a bug or two.  I concede however on how much value it might add and whether or not the value of such a thing outweighs the risk.  If it were me in their shoes...  I have to admit that I would probably say, no thanks.  We got this.

Assumption 2... no, don't ascribe that one to me. 

However, on the topic of "treatable" or "non-treatable" bugs.

I'll give a couple examples that I've come across...

If you put a ladder on a platform, you should be allowed to easily exit the ladder when you reach the top of the platform.  That is the kind of bug that I find to be very disappointing and it impacts my game play.  I build something with the expectation that a part (like a ladder) would function as a ladder and have a way to exit/enter when you reach a platform on the top.  Something happened in one of the 1.7.x updates that messed up ladders in this sense.  I need to post something in bug tracker for it.

An example of a harmless bug or something that is even fun to have would be part clipping having zero impact on engine thrust.  This is the kind of bug that actually was pretty nice to have and allows for a bit of extra creativity.  Folks even built craft designs around it... it bothered no one, did not effect game play and was easily avoided by those who preferred not to incorporate such things into their designs.  Then they decide to fix it months (years?) later and it destroys or disrupts favorite craft.  Not sure why we needed the Wheesly and Goliath engines fixed in this sense.  Now reverse thrust on at least the Wheesly doesn't work if something is clipped to the side of the engine.  They fixed what never needed to be fixed, and in the process introduced a bug that disables reverse thrust in some craft designs for no reason.  

Wheel interactions with the ground shouldn't cause your craft to be catapulted into a gravity-challenged low orbit, or come crashing down and causing damage to your craft...  after maybe spending an hour or two of RL time traveling to some far off place.   Stuff like that should be vetted and squashed before release and it may not be the tech-heads who find it.  It more likely will be discovered when you get a diversity of play styles testing the engine. 

The bugs introduced during the transition to 1.4 (new Unity engine) were so bad that I couldn't even leave the Kerbin SOI.  Craft that were docked as cargo in other craft couldn't be deployed without damaging stuff and/or blowing up.  I could not play the game anymore with my fleet of craft.  To risky to deploy anything without damaging it (and no way to fix it on site) so I just hung around Kerbin and only did sandbox stuff, pretty much all the way up to present... even left the game completely between December and August.  Had no real reason to play anymore.  1.7.3 came out and added rotors, some robotics, and the KAL-1000 so now I'm at least playing around on Kerbin again with helicopters.

 

Link to comment
Share on other sites

1 hour ago, sturmhauke said:

Well yeah. But in my case, I was both a full time QA tester and a game junkie. It also helped that both of those examples were high profile and in testing for a bit longer than usual, so we had a little more freedom to screw around and try to find weird edge cases. And also do 4 way free-for-all battles.

Oh, sure.  But as a professional, you also presumably had a reasonably realistic set of expectations, which makes all the difference.

I was thinking more about, for example, when I was having this conversation with my sons, back during their teenage years, and they were agog to find out that "game tester" was an actual job.  "WHAT?!  I can get paid to play video games?  That's a job?  Oh man, that's what I want to do!!!"  Er, well, no, son, that's not what it actually is, and it's a whole lot more work and less fun than you appear to think it sounds.  ;)

1 hour ago, XLjedi said:

However, on the topic of "treatable" or "non-treatable" bugs.

I'll give a couple examples that I've come across...

Sure, fair 'nuff.  There are scads of examples to be had.  :)

The point is that any decision about fixing a particular bug needs to be based on three things:

  1. How bad is it?
  2. How expensive would it be to fix?
  3. How risky would it be to fix?

(And occasionally other considerations, like "is it kinda moot because we're about to completely replace that entire section of code anyway," but I digress.)

As a player, you only have visibility into #1.  How expensive or risky a bug is, will generally have very little correlation to how bad it is.  You could have a trivial "oops, I put a 'not equals' in a spot where it should have said 'equals'" that completely borks the game but is a painless one-line fix with essentially zero risk.  Or, you could have a bug that looks minor and cosmetic but is actually symptomatic of something very deep and highly metastasized in the code base, so that fixing it would be a ginormous and/or dangerous thing to do.

#2 and #3 absolutely affect players... but in ways that are invisible to them.  They're visible only to the developers.

That's why the game-play experience with bugs is so often frustrating to players.  All we can see is how the bug affects us, without any visibility whatsoever into cost and risk and the like.  So when we run into a really annoying bug, it's extremely tempting to blame the company:  "Gosh, those bozos, how could they not have spotted this?  Do they not even play their own game?"  And when a bug is reported, and it doesn't get fixed for a really long time, it's extremely tempting to blame the company, too:  "Gosh, those jerks, they must not care about the players at all!"

Which is unfortunate-- because often there's a perfectly reasonable explanation for the situation and the developers are actually making all the right decisions (for the players, even if they don't know it).  Unfortunately for the devs, those reasons aren't visible to the players, so the devs just have to endure getting yelled at by people who don't realize they don't know the whole story.  And those reasons are often things that the devs actually can't talk about publicly for various reasons... which means they have to just live with getting yelled at for crimes they haven't actually committed.  It sucks.  However, it goes with the job, alas.

(And, yes, sometimes there are companies that are incompetent, or cavalier towards players.  But that tends to be the exception more than the rule, in my experience.)

So I'm not saying players shouldn't complain about bugs.  If they paid money for a product, and it doesn't work right, in a way that significantly affects their enjoyment, then of course they have every right to be unhappy about that, perhaps even angry.  Just... for anyone reading this, please do remember that developers are people too, and these are folks who work really hard and are doing their best.  So when phrasing the complaints, try to keep some perspective when setting the tone.

Link to comment
Share on other sites

43 minutes ago, Snark said:

Oh, sure.  But as a professional, you also presumably had a reasonably realistic set of expectations, which makes all the difference.

...How expensive or risky a bug is, will generally have very little correlation to how bad it is.  You could have a trivial "oops, I put a 'not equals' in a spot where it should have said 'equals'" that completely borks the game but is a painless one-line fix with essentially zero risk.  Or, you could have a bug that looks minor and cosmetic but is actually symptomatic of something very deep and highly metastasized in the code base, so that fixing it would be a ginormous and/or dangerous thing to do.

All true. I'll also add that there is unfortunately often a divide between QA and dev teams. QA says, "yo, we found these bugs and gave you detailed steps to reproduce them, why aren't you fixing them?" Dev turns around and says, "That one is a bug in this third-party library that we can't patch or replace right now, that one relies on code that is used in 50 different places, that one is a Heisenberg's bug that acts differently when inspected, that one's not really a bug because you guys haven't set up your environment correctly, that one is just you not understanding what you're looking at..."

Not that this is how people should behave, mind you, but also remember that game studio employees tend to be young and under a lot of pressure.

Link to comment
Share on other sites

35 minutes ago, sturmhauke said:

I'll also add that there is unfortunately often a divide between QA and dev teams.

Well, certainly there's a distinction, but I tend to view most of it as simply different disciplines coming at a problem from different directions, and not necessarily "unfortunate" per se.  To tak some of the examples you give,

35 minutes ago, sturmhauke said:

That one is a bug in this third-party library that we can't patch or replace right now

Not a "divide", and not "unfortunate".  Third-party library bugs are a real thing, and there may be valid technical reasons why it isn't possible or advisable to switch the library.  So, assuming that the devs know their job, that's the right decision.

35 minutes ago, sturmhauke said:

that one relies on code that is used in 50 different places

...Which would increase the cost and/or risk of changing, so again, not "unfortunate", simply the right technical call (again, assuming that the folks involved know how to do their jobs).

35 minutes ago, sturmhauke said:

that one is a Heisenberg's bug that acts differently when inspected

Ugh.  Heisenbugs are the worst.  It means that the cost of diagnosing the bug and nailing it down goes way up, which means it therefore needs to be prioritized against other work and may very well lose out.  Again, not "unfortunate", just the right call if circumstances warrant.

35 minutes ago, sturmhauke said:

that one's not really a bug because you guys haven't set up your environment correctly, that one is just you not understanding what you're looking at...

Now these actually can be a source of friction-- easily happens for any two groups of people that come at a problem from different directions.  It may be that the tester actually set up an environment wrong or isn't understanding correctly-- or, conversely, the tester may have got it right and the dev is being unfairly dismissive.  Totally with you on that one.  :)

35 minutes ago, sturmhauke said:

Not that this is how people should behave, mind you, but also remember that game studio employees tend to be young and under a lot of pressure.

Agreed, though I think it's broader than that.  I think it's a universal constant that everyone is always under a lot of pressure.  And this isn't just a young-people thing, nor is it just a game-people thing.  It's simply a people thing.  I've been working in the software industry at a variety of companies (never gaming, thus far) for a very long time.  I've worked with fresh college hires, and with grizzled veterans.  And these kinds of things happen everywhere, in all age groups, in all types of companies.

I'll say that in organizations I've been in where there were dedicated testers (again, this is the software-industry-at-large, not gaming per se), in general I've observed a very friendly, collegial relationship between devs and testers-- it's an atmosphere of mutual respect, because each one does stuff that the other one can't, and each one helps the other.

Link to comment
Share on other sites

28 minutes ago, Snark said:

I'll say that in organizations I've been in where there were dedicated testers (again, this is the software-industry-at-large, not gaming per se), in general I've observed a very friendly, collegial relationship between devs and testers-- it's an atmosphere of mutual respect, because each one does stuff that the other one can't, and each one helps the other.

What I was trying to express was that at some shops, there is an atmosphere of mutual disrespect. Yes, the two groups can and should have different approaches to resolving technical problems. But if the software is a wagon, sometimes they end up pushing the wagon back and forth and sideways, or even just stand around yelling at each other while it rolls off a cliff, instead of lining up behind it and pushing it forward.

Link to comment
Share on other sites

Considering that there seems to be a few hundred people who would be willing to strip naked, cover their bodies in mustard, and run laps around the Star Theory office for a chance to get their hands on KSP2 early, I'm absolutely certain that no one from the company is trolling the forums for volunteers. In fact no game company ever trolls forums for alpha or beta testers, if they need them they will provide a link somewhere so you can apply. And if they're even vaguely popular they get 10 or 1000 applications for every tester needed, and if you think they have the time to look at something like what ships someone has created, you don't understand the limits of game dev resources.

I OTOH won't even buy it when it's released, because it's almost certain to be broken in various ways that will require save-breaking fixes. I'm perfectly happy to let other people beat their heads against those issues for me. Once it begins to settle down and the modders have started making progress, then I'll start looking into a purchase.

Link to comment
Share on other sites

8 minutes ago, vossiewulf said:

I OTOH won't even buy it when it's released, because it's almost certain to be broken in various ways that will require save-breaking fixes. I'm perfectly happy to let other people beat their heads against those issues for me. Once it begins to settle down and the modders have started making progress, then I'll start looking into a purchase.

I doubt I'll really be playing it too far beyond sandbox at launch...  Of course, I'll start a career just to see what it's like, but I'm more interested in seeing the craft file format and structure and to begin tinkering with whatever mod/dev tools are available.  Probably have to spend the first month or two rebuilding all my craft if no craft file port feature is offered.  Which would not surprise me at all.

There are not too many games that I would buy at launch nowadays.  Don't know if I could actually name a single one in the last decade...  But for KSP, I've gotten enough hours of playtime out of it that I will step out of character and support it from day one.

Link to comment
Share on other sites

48 minutes ago, XLjedi said:

But for KSP, I've gotten enough hours of playtime out of it that I will step out of character and support it from day one.

That's a good way to express your support, and if I felt like I could purchase it on day one without starting to play it, I would. But I'm the OG computer gamer, I wrote my first game about 40 years ago now on an Apple II with a tape drive, and have been through so many games mostly broken on release that I'm really good now with waiting a few weeks or months for other people to get it all fixed up for me.

Link to comment
Share on other sites

11 hours ago, sturmhauke said:

All true. I'll also add that there is unfortunately often a divide between QA and dev teams. QA says, "yo, we found these bugs and gave you detailed steps to reproduce them, why aren't you fixing them?" Dev turns around and says, "That one is a bug in this third-party library that we can't patch or replace right now, that one relies on code that is used in 50 different places, that one is a Heisenberg's bug that acts differently when inspected, that one's not really a bug because you guys haven't set up your environment correctly, that one is just you not understanding what you're looking at..."

Not that this is how people should behave, mind you, but also remember that game studio employees tend to be young and under a lot of pressure.

As a long time project manager for several software project I can say that you'll always get different views from Designers, Devs, QA, Marketing, Sales and other selected nutjobs.

My job is to take those different views and make decisions based on all the gathered data.

-- "We will call you Cygnus, the god of balance you shall be." -- Rush, Hemispheres

 

Edited by Curveball Anders
Link to comment
Share on other sites

Been there, done that, got the T shirt and the hat. Would do it for KSP2 if I could. But if you have never done anything like this before , you better be prepared for the dedication required and the time involved, it is not all fun and games. My experience has been that most find out how hard and time consuming it really is and what little reward you get and they fade into obscurity. Be careful what you wish for.

Link to comment
Share on other sites

×
×
  • Create New...