Profile picture
, 34 tweets, 8 min read Read on Twitter
{thread} While I haven't been paying much attention to Star Citizen since Dec when they released a financial statement proving me right again about their finances, a short para in the latest Crytek v CIG court filing has me thinking about a lie that's been in plain sight
Last week when CIG filed a motion for Crytek to post a bond for costs, I wrote a short thread about it, while not going too much into the details. Embedded in that filing is an affidavit - not from Chris Roberts - but from his partner Ortwin.

That affidavit (below), though riddled with the usual colorful rhetoric that has come from CIG during this lawsuit, the "Switch To Lumberyard" section on p3 has some statements which weren't publicly known until that filing.

docdro.id/O2SsvLM
It states that :

1) Lumberyard license was signed on April 30th, 2016

2) they switched to that license (from the Crytek one)

3) they used the CryEngine code that's part of Lumberyard

imgur.com/pnSjTXV.jpg
While that may seem rather innocuous, I believe that it's going to prove to be very detrimental going forward. Why? Because the whole point of whether or not they switched to the Lumberyard engine (which is based on CryEngine 3.8) was a key issue in the 12/16/18 MtD ruling
In Dec 2016, following the "switch", I wrote a blog detailing why I believed that they really didn't fully "switch" to LY implementation; but rather they retained pre-existing CE code, while only switching from Google Compute to Amazon AWS

dereksmart.com/2016/12/star-c…
They didn't even get their story straight, making three of them which were not only inconsistent, but also contradictory.

1) 12/23/17 press release (which Ortwin refs in his affidavit)

robertsspaceindustries.com/comm-link/pres…
2) 12/23/17 newsletter following the release of Alpha 2.6 (first LY license version)

i.imgur.com/G7lHAVZ.jpg
3) 12/25/17 forum statement by Chris Roberts following the furor over the LY switch

forums.robertsspaceindustries.com/discussion/364…
Timeline:

04/30/2016 - LY license executed
08/25/2016 - Alpha 2.5 release
12/23/2016 - Alpha 2.6 (LY switch) release + LY switch announcement

Don't forget that throughout their LY evaluation from 2015 to the 2.6 release, they never disclosed any of it to backers. Not even once.
As I mentioned in my Dec 2017 blog, it's completely inconceivable for them to have actually stripped all their CE custom code, then merged in the heavily customized CE version in LY - in "a matter of days".

They lied. It's really that simple.
As any dev would attest to, going from one major code version in a third-party engine to another, is bad enough in and of itself; let alone going to a completely different branch that's already been heavily customized by a third-party.
So now, Ortwin has basically proven me right - once again - by now clearly stating that this, in effect, was more a "license" switch, than a "code/engine" switch.
The analogy that comes to mind is as follows. You have an engine license with a yearly support contract. Then MS buys the co and bundles it free with other core services. You no longer have to renew your previous license as you're now getting the same thing - for free.
But that doesn't mean you have to go back in and remove all the code written with your previous license. Nothing changes in code; only the paperwork (license).
However, what if between the time the co was bought by MS, they had a major release, which they release following the acquisition? You can either continue using your previous ver or allocate resources to doing the merge/port. The latter is a non-starter for a delayed project.
If you don't want to pay for another license, let alone yearly support contracts, what better way to do it, than to switch to the MS branch and not have to pay anything, while still using the version you *did* pay for and have a license to use?
And THAT is the core of the lawsuit regarding CIG use of CE for a second project, Squadron 42, and which would otherwise constitute a breach of the Crytek license which only allowed them to use it in one project: Star Citizen.
Ortwin's affidavit has now erased any doubt that this is precisely what they did. Which is EXACTLY what I said they had done.

All this in a bid to sidestep the issue of using CE for two games, instead one; while claiming SQ42 is part of SC, and so it's covered by the ONE license
And this statement now also contradicts previous statements file in the pleadings for their MtD in which they claimed that they switched engines, they had a right to do so, and that switch didn't require them to display the Crytek logo (now replaced with LY) in Star Citizen.
They've basically now created an even more tenuous situation because if during discovery Crytek finds that they were still using CE code that's present in their core version but not in the LY version, they have some explaining to do.
While it's difficult to explain in layman's terms what this means, let me try. Say CE revised a function in their core version, while LY completely removed it from theirs. That code (and all dependencies) shouldn't still be in Star Citizen.
Taking one look at the LY changelog, and seeing the massive revisions they've done to the base CE core which they licensed from Crytek, it's completely inconceivable that CIG switched completely, thus removing all traces of the previous CE core version.
Let me throw another spanner in the works. For YEARS now CIG had been LYING to backers about the state of SQ42. Then in Dec 2018, shortly after disclosing a $46M bailout investment from May 2018, they announce that it's now over 2 yrs away.
That game uses the same engine as SC and is only different in terms of it being single-player, and with a story line. But it's the game that represents the greatest liability in the lawsuit. So it would have to be ported completely to LY with *zero* traces of any unique CE code.
That merge/port, going by the diffs between the CE 3.8 engine and LY, is a massive effort. Even if that's not the issue, they would still be in some serious legal jeopardy if they lost that cause of action. Guess why?
The judge already DENIED the CIG MtD specifically related to their use of a CE engine for that game. They claimed that though they switched engines, their CE license still allowed them to use SQ42 anyway. The judge disagreed.

i.imgur.com/LBjig3J.png
So what are the odds that they are in the process of doing that pure port to LY, even as the lawsuit moves along? Or if not, what if they're just sitting on it in the interim?

Note that the trial date is set for 03/24/2020

docdroid.net/NRDf1Rh/schedu…
And in Dec 2018, they claimed that SQ42 would be released (lol!) in the first half of 2020.

Coincidence?

dereksmart.com/2018/12/star-c…
I can't wait to read the Crytek response to this cost bond motion because not only has CIG opened a whole new can of worms, they've now given Crytek even more ammo to use during discovery requests pertaining to source code revisions.

{end}
ps1: I should also point out that I had previously compared the SC binaries and proven beyond a shadow of doubt, that they were still using CE core. The biggest Red flag was their generous use of spinlocks (absent in LY) - which they later removed following my article on it
ps2: And even as I type this, there are STILL several code blocks in Star Citizen from their use of CE core, which are NO LONGER PRESENT in the LY engine code. Aside from being public, most devs have the source code to both of these engines, so it's a no-brainer to figure out.
p3: Imagine then how easy it would be for a third-party to forensically go through the code during discovery, and conclude that they didn't in fact switch to LY *engine*; thus putting them in breach of the GLA for using it with SQ42 - IF the jury rules in favor of Crytek.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Derek Smart
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!