It's funnier than that. Had the CryTek engineers played, let alone debugged it to any degree, they would have spotted it. But hey, maybe they're not the top notch CryTek engineers that CIG thought they were poaching.
The Star Citizen Thread v 4
- Thread starter Yaffle
- Start date
- Status
It's funnier than that. Had the CryTek engineers played, let alone debugged it to any degree, they would have spotted it. But hey, maybe they're not the top notch CryTek engineers that CIG thought they were poaching.
I was very impressed with DB's show of support of support for CIG's efforts.
But until they stop trying to weasel out of their refund obligations they'll get zero slack from me.
And I'm realistic enough to know that statement will have zero effect on them.
Welcome to the thread!
Nice post. At the moment I have paused with E : D, at least until Frontier sorts out the most glaring bugs with the Engineers update.
Just my tuppence-worth in what has been an entertaining thread.
IMO, a bug is a bug if a system does not behave as defined in the system architecture / design documents or, in those or similar documents absence (*), as any reasonable user would expect it to behave.
From the information given, it was definitely a bug in SC: no end-user would expect the ship to behave in the manner it did. It was undesired behaviour.
However, it gets more complex in the case of CE. If the behaviour was specified to be as such in documents available to CIG, then it is CIG's coders' fault. They should have read the darned documents (**). If the behaviour was not in the documents, then they can be excused and it is CE's 'bug' (i.e. undocumented behaviour) manifesting itself in CIG's code.
It's a little like the evils of sprintf(), malloc(), strcat() etc in the C language. When used incorrectly they can cause all sorts of bugs and security holes, yet they are not, as of themselves, buggy: they behave exactly as specified. It's just that the specification is by modern standards lax and too easy to misuse. Any bugs caused by their misuse are in the software, not the calls themselves. Fortunately most programmers should be well aware of the issues with these calls and use safer alternatives.
As ever, RTF documents.
(*) All too common.
(**) In their defence, this is sometimes easier said than done.
IMO, a bug is a bug if a system does not behave as defined in the system architecture / design documents or, in those or similar documents absence (*), as any reasonable user would expect it to behave.
From the information given, it was definitely a bug in SC: no end-user would expect the ship to behave in the manner it did. It was undesired behaviour.
However, it gets more complex in the case of CE. If the behaviour was specified to be as such in documents available to CIG, then it is CIG's coders' fault. They should have read the darned documents (**). If the behaviour was not in the documents, then they can be excused and it is CE's 'bug' (i.e. undocumented behaviour) manifesting itself in CIG's code.
It's a little like the evils of sprintf(), malloc(), strcat() etc in the C language. When used incorrectly they can cause all sorts of bugs and security holes, yet they are not, as of themselves, buggy: they behave exactly as specified. It's just that the specification is by modern standards lax and too easy to misuse. Any bugs caused by their misuse are in the software, not the calls themselves. Fortunately most programmers should be well aware of the issues with these calls and use safer alternatives.
As ever, RTF documents.
(*) All too common.
(**) In their defence, this is sometimes easier said than done.
Since you have chosen to be condescending, I will ignore the first part of your question - then promptly block you after this response.
As to the F42-GER office, you're pretty wrong.
They have been operating since Aug 2014 at a different location and wasn't formalized.
Here is video put out by CIG on April 10th, 2015
[video=youtube;yisaDxvBH9s]https://www.youtube.com/watch?v=yisaDxvBH9s[/video]
Here is the official press release (over three months later) put out by CIG on July 6th, 2015
https://robertsspaceindustries.com/...mes-Opens-New-Development-Office-In-Frankfurt
This not unlike when a group of people leave a company, setup a studio - or team - while working on something until it is all formalized.
- - - - - Additional Content Posted / Auto Merge - - - - -
They were already on-board at the time. Which was the astonishing part when we heard this news in the 104TD broadcast.
Last edited:
I sure hope that reaction was because of the endless stream of people having attacked you in the past/present, because there was nothing in my post that showed any such intent (and it wasn't meant either).
I do honestly believe you're overreacting.
I did get your point - to fair extent I also agree with you. Unfortunately you didn't get my point.
It's funny though - people outright rejecting opinions even if there's logic in them ...
Should I really preface everything I say with: "I hereby agree with an overwhelming part of SC's criticisms of overhyping & underdelivering"?
Would that give me more credibility here? Because if 'yes', then I should be good to go
Following on from this excellent post: perhaps it might be more constructive to think of how we would put the project to rights if we were put in charge. After burying our heads in our hands for a while (something most project managers do on their first day when they see the state of an existing project), what would we do? Only constructive ideas, no 'sack Sandi / Chris' negativity.
We don't know what's happening internally, but here's my stab:
*) Get the existing codebase working and as bug-free as possible. If new net-code is required, and that cannot be done in a reasonable (say three-month) time frame, reduce MP requirements on the existing codebase until it works. Tidy what you have, fix it, and turn it into a game. Only put minimal effort into features above and beyond what they currently have, unless the resources (i.e. staff) cannot be used on 1.0. For instance they may still have a few people working on PG, and artists / designers working on new assets. Make it good. Make it sexy.
*) A large source of complaints come from the flight model (see above). Decide if you wish to stay with what you have and, if not, open up discussions. Perhaps produce different alphas with different fm's to get user feedback.
*) Get most of the team to do a release a 1.0 code by year-end with no new major features; only what we see in 2.4 but done well.
*) People have spent good money on ships. They deserve them. Work out which ships you are doing, in which order, and tell people. Perhaps use the amount people have spent on the ships as a basis for the ordering. Make it so they can be added after 1.0. Publicise the order, even if it is in tranches of two or three ships.
*) Most of all, decide what can be done before September, do it, and then allow three months of testing and further bugfixing.
It seems to me they are spending too long in chasing new features, and not long enough sorting out the features they have. Construct a solid foundation in 1.0, then build up. I wonder if any other space-sim recently used this approach?
Anyone more knowledgeable have other ideas?
Wooah...then....we do have a double-trouble.....Actually now I am really curious did John Pritchett figure it out by itself(using only PC&whole Internet) after 3 days or maybe he is the one at CIG who speak just a bit of German language...so after 3rd day he figures that is maybe better to make a phone call to Frankfurt and ask...[wacko]
Last edited:
Hang on, didn't you say earlier about how the Cutter would have to be redesigned be cause the ship launched fighters won't fit?
I mean that statement being wrong, does that mean you're not a "true fan" (whatever the chuff that means) so not worth discussing with?
Last edited:
Yes those "game breaking" bugs, because SC is almost bug free right? LMAO if that was the real reason, oh boy was it a sad excuse.
Game breaking bug are falling through the floor of your ship, you avatar does weird stuff, your gun doesn't hit what you're shooting at and so on. I don't own SC (thank mighty GOD) but I do play it at a friend of mines house, just to see if i'm missing anything.
And nope, its the same messy pixel soup as it always was. wobbly controls, low frame rate, and so on and so forth.
So I'm really looking forward to see anything that actually works, and is fun to play. I'm a pretty open person, I'd even give CoD in Space a go in November.
Last edited:
Can I please be Derek?
All Star Citizen Truthers are you, Derek!
If you learn how to use flight assist off the NPC's wont be able to pick on you.
I read it agin, but iam now more certain. From what you serve, sc match all requirements to be called an alpha version.
Perhaps I misinterpreted this? "I can't lie - a part of me thinks your negative opinion of the project gives you the other perspective, under which it may as well be called a feature."
Reading that tells me that you are of the opinion that I cannot be relied upon to be unbiased. Which means that any attempt at engaging you - or anyone who feels that way - is a waste of my time. That's the point that I was making. It may not have been your intent, but if you read it again, I think it should be clear how it could be misconstrued.
To be clear: I have absolutely no doubt in my mind that the project is , and that CIG - and all its entities - will collapse before they ever release anything resembling a product promised - let alone an MVP. And seeing as they know it, yet continue to take money from backers, is the most abhorrent thing imaginable. That's the extent of my negativity.
We all have our biases. Mine, despite the fact that I have been under constant attack since my first blog which called out the follies and litany of lies about this project, have more to do with the project, than it does with anything else. e.g. I blame croberts and his brother eroberts for all of this, while still holding other minions like Ben and Lando accountable - not for doing their jobs - but for misleading the community about the state of the project.
And for those who have forgotten how I even got involved in this, here is the TL;DR version that's 100% factual.
Last edited:
I missed this one earlier - I'd just like to point out that I am in fact the person with the least knowledge on both games - by a long way - and you or no-one else can take that away from me!
As you were.
(I'm not really a poser though - I have terrible hair).
It's a good list and would certainly be a better solution to what there is now ... which is not much of a solution.
However just to note on 1) : Scaling back the code of a system is not really an option sometimes. You design your system to support a given number of users and that user requirement will guide the complexity of that system. Once you start implementing it, it will be difficult to just cut it off on one end and simplify it. It can happen, there are design patterns that can do it, but it's always a mess, hard to get it working the right way and generally hell to maintain...
Nah it'll be a new ship, the Maximus Imperiator Squadrus 7000 - artists impression below:
[/joke]
Nope, looks to me like you have the general idea right.
Yes, I do believe that your multiple crusades against SC (justified or not) can leave you biased. Is it that strange? Is that 'me' attacking 'you'?
Isn't it just human? Even you agree:
We are talking about bias in the project right here. Not anything else.
Anyway we derailed really badly here. I'll respectfully withdraw now. Have a good day!
Surely before you do anything technical/practical you need to actually figure out what game you're trying to make and what game you can reasonably expect to make with the resources at your disposal.
And you definitely need to send CR on another holiday or at the very least put him in a straight jacket to stop all that bloody handwaving interfering with the people trying to do the work.
And you definitely need to send CR on another holiday or at the very least put him in a straight jacket to stop all that bloody handwaving interfering with the people trying to do the work.
I'm in no doubt that you Mr. DS know the business, and how stuff work regarding game design. I know nothing about game design at all, I do know a lot about project management as this is my job, and looking at the SC project made me realize in mid 2014 that something was horrible wrong. I then started to ask for a refund, I received that October 2015, a full refund.
What I don't understand is, if there are evidence surfacing regarding misuse of funding, manipulation of backer numbers and so on. If there are substantial facts behind, the question would be, when will project SC reach point of no return? And a follow up question would be, if there is evidence of such acts, are they reported to the US authorities? Because there are people out there who didn't receive a refund, and they are still asking for a refund, some of them would probably like to know what options they have to get the money back, they pledged to a company who didn't deliver the product they said they will deliver, at the time they said they would deliver it.
Again I don't know if basic consumer law apply here, I'm just guessing wildly here.
- Status