Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
spacetoaster
Feb 10, 2014

This guy seems to be very well adjusted.

Adbot
ADBOT LOVES YOU

Sabreseven
Feb 27, 2016

The Titanic posted:

I'm gonna guess this is a photoshop, but I hope to find out in another page or two. I'm time traveling from the past into your present. Just takes a little while. :shobon:

I had to check, it's not actually a photoshop, it's on the site clear as day.

I wonder how they worked that figure out, it's in linear kilometres and not 'squared' or even 'cubed', yet how do they make such a claim when they know full well 99.9 of those 100 are full of empty space and nothing to find?

I'm leaning towards thinking "false advertising".

1 x sextillion km = 1,000,000,000,000,000,000,000km = no way they made an in game map 100x larger than that.

Sabreseven fucked around with this message at 05:56 on Dec 29, 2016

Beer4TheBeerGod
Aug 23, 2004
Exciting Lemon

spacetoaster posted:

This guy seems to be very well adjusted.



Isn't that an alt for Al Bester or whatever his name was? Some kind of B5 weeaboo equivalent?

Beer4TheBeerGod
Aug 23, 2004
Exciting Lemon

Sabreseven posted:

I had to check, it's not actually a photoshop, it's on the site clear as day.

I wonder how they worked that figure out, it's in linear kilometres and not 'squared' or even 'cubed', yet how do they make such a claim when they know full well 99.9 of those 100 are full of empty space and nothing to find?

I'm leaning towards thinking "false advertising".

I'm leaning towards "Chris Roberts heard the word sextillion and wouldn't stop giggling and referencing it until someone was forced to put that in."

The Titanic
Sep 15, 2016

Unsinkable

ripptide posted:

You give them far too much credit methinks. The common backer line is that the Goons wanted to take over the direction the game was moving in, and when they were defeated by the godly forces of SC, the goons picked up their collective balls (sorry Titanic) and left, to attempt to ruin the game from the outside.


You couldn't make this poo poo up if you tried.

No harm done. Balls are optional features. :shobon:

But your point is still good! The constant ongoing battle of vilifying goons/Derek/anybody who chooses to say Star Citizen may not happen- is a never ending well of humor.

Though I'm hoping at some point the backers will slowly realize the failure to develop games is coming from inside the house. At some point some genius is going to realize, in a sudden fit of ego of course, that they determined that goons can't possibly be ruining the game because none of them (possibly?) actually work at CIG.

More so, this smart genius will also realize that posting on a forum also isn't causing Star Citizen to be an endless cock up of problems and failures. They will determine that, only tentatively and with a six paragraph long "I'm a hardcore backer and firmly believe in CIG, but..." sort of post, the problem may lie with the fact CIG is utterly incompetent and can only produce traces of existing artwork, mod-level gameplay, and pretty nice graphics. Unfortunately though there's only so much fun you can squeeze out of 3DMark before you get a bit bored of its feature list.

Looking forward to these moments! :allears:

Samizdata
May 14, 2007

The Titanic posted:

Ooh, the main character is going to be a non-white guy? That would be really funny given I bet >90% of the backers are pasty white men dreaming of being Firefly captains, or the guy from Battlestar or Han Solo. Basically Video Game Avatar #3566433 specifically designed to look almost exactly like Nathan Drake from Uncharted (sorry if I'm mis remembering that name).

I'd give CIG a high five for that. :3:


ripptide posted:

Hey, watch it with the "pasty white guy" comments, if you please, TIA.

Yeah, cut that doxxing RIGHT OUT, pal.

Sabreseven
Feb 27, 2016

Beer4TheBeerGod posted:

I'm leaning towards "Chris Roberts heard the word sextillion and wouldn't stop giggling and referencing it until someone was forced to put that in."

You might be right, but still, what a ridiculous thing for them to claim. I don't have the right words to convey the preposterousness or absurdety of it. :D

They should've picked a believable number at least and cubed (dammit) it to give an impression of a 3d space, it's pretty much the strangest thing I've seen posted on their front page lol.

Beer4TheBeerGod
Aug 23, 2004
Exciting Lemon

Sabreseven posted:

You might be right, but still, what a ridiculous thing for them to claim. I don't have the right words to convey the preposterousness or absurdety of it. :D

They should've picked a believable number at least and squared it to give an impression of a 3d space, it's pretty much the strangest thing I've seen posted on their front page lol.

I guess that's what happens when you don't finish your physics degree.

Samizdata
May 14, 2007

ewe2 posted:

I wasn't assuming anything about CIG, I was talking about the engine they're basing their code on. CIG can call their versions anything they want. The problem is their pretence that rebasing a fork on a later base was a simple matter. Simpler if they threw out the modifications that caused conflicts with the later development, or if they simply started again from LY. The latter is looking pretty good.

I have been trying to convince some of the Reddit crowd it is far more difficult than they seem to think and that they understand nothing of game development.

(Never developed a game myself, but I have worked on several classes of business software.)

The Titanic
Sep 15, 2016

Unsinkable

Rad Russian posted:

After making excuses for not delivering anything for 4 years now, it's become second nature to them. Hilarious to watch. Someone should make a list of top 100 CIG excuses. The one from last year: "oh sorry we forgot to mention, one of developers broke his arm last week so we're delaying the release of today's patch indefinitely" has to be in the top 5 all-time for sure.

I don't think you can top an entire YouTube video dedicated to "how hard we try! :'(" because they did that too. I expected one for the Christmas thing too but I guess they didn't have another ready fast enough.

Sabreseven
Feb 27, 2016

Beer4TheBeerGod posted:

I guess that's what happens when you don't finish your physics degree.

I'm begining to entertain the idea that he never got past first grade maths or learned anything past "A,B,C.." to be honest, I'll even hazard a guess that he drops his jeans to the floor and holds his sweater waist up to his chest when he goes peepee. :)

https://www.youtube.com/watch?v=xV3zy-mCsOc

Sabreseven fucked around with this message at 06:10 on Dec 29, 2016

Samizdata
May 14, 2007

The Titanic posted:

No harm done. Balls are optional features. :shobon:

But your point is still good! The constant ongoing battle of vilifying goons/Derek/anybody who chooses to say Star Citizen may not happen- is a never ending well of humor.

Though I'm hoping at some point the backers will slowly realize the failure to develop games is coming from inside the house. At some point some genius is going to realize, in a sudden fit of ego of course, that they determined that goons can't possibly be ruining the game because none of them (possibly?) actually work at CIG.

More so, this smart genius will also realize that posting on a forum also isn't causing Star Citizen to be an endless cock up of problems and failures. They will determine that, only tentatively and with a six paragraph long "I'm a hardcore backer and firmly believe in CIG, but..." sort of post, the problem may lie with the fact CIG is utterly incompetent and can only produce traces of existing artwork, mod-level gameplay, and pretty nice graphics. Unfortunately though there's only so much fun you can squeeze out of 3DMark before you get a bit bored of its feature list.

Looking forward to these moments! :allears:

Now we just have to keep the Tactical Goon Squads striking deep into enemy territory (you know, beyond the Citizenry Line of Defense) motivated and in high morale, so as to keep the laughs coming. Also, tissue for brain transplants would be lovely, as one can feel their "little grey cells" shriveling up with each strike.

Samizdata fucked around with this message at 06:15 on Dec 29, 2016

The Titanic
Sep 15, 2016

Unsinkable

Young Freud posted:

Every time I see this, I'm reminded of Scott Manley's video about true orbital-speed physics in Kerbal Space Program, where he talks about trying to collide two objects together in KSP in an "insurance scam" challenge. In the challenge, KSP is calculating at about 30 "frames" per second, but the objects in motion are moving about 4 kilometers per second, or 133 meters per frame, which turns out to be too fast for KSP to register as a collision. They literally pass through one another. Manley used a mod to slow the physics down to 1/10th speed, extending the KSP's physics fps to something like 300 per "second", slowing down the collision to about 13m per frame, slow enough for the physics to register the collision. It explained a lot about how physics engines work and how you have to tweak things to get the physics to be "correct" for the game. I remembered when I played Second Life, guns would have to shoot meter long spears for the lovely physics engine register them as a projectile hit if you used somewhat realistic velocities.

That's my guess what's happening here, the missile is moving way too fast for the game engine to register the collision.


I'm coming to the conclusion that whatever modifications that CIG has added are smoke and mirrors and that their design process was so focused on revenue-generating screenshots and videos and ship sales or caught in Chris' creative revision cycle that they didn't bother to actually program the game. It's clear that they were going for visuals before gameplay, since it's easier to sell that poo poo. Everything should have been grey- or orange-boxed and we haven't seen nothing like that.

I believe this too. But the one snag I have is the 64-bit stuff they took apparent months to hack in. I'm not a video game engine writer, but making a switch like that seems, to me, that it needs to go all the way down to the core. Everything on top of it would then need to be fixed to support it as well. Out of all the stuff they talked about doing, I felt like converting a 32-bit engine to support 64-bit scales and sizes would be the most difficult "ground up" sort of thing. It's the kind of change where most people would say "gently caress it" and start writing a new engine from scratch so they didn't forget something or break something else reliant on the wrong number convention.

Am I wrong in this thought? 64-bit is really one thing you can't just sort of build an external dll to handle like some kind of magical mcguffin. If they did convert to 64-bit, that claim of 50% engine modification seems legitimate.

Of course this also means you can't just merge in stuff from another branch of the old engine because literally nothing is compatible outside of maybe error messages or something utterly pointless and disconnected from the actual engine handling.

As a small example, look at the fuss from the modding community over the 64-bit Skyrim Special Edition. And that's a game where it's basically the exact same game and tools. Some stuff works, but anything worth a drat needs to be rebuilt. It's not just a matter of clicking a "convert to 64-bits" check box.

So tell me guys and girls, an I wrong here? Is the conversion to 64-bit not as big a deal as I believe it to be for a game engine?

Raskolnikov
Nov 25, 2003


For some reason it reminded me of this:

https://www.youtube.com/watch?v=C9v-UVSy_vo&t=110s

The Titanic
Sep 15, 2016

Unsinkable

ripptide posted:

Hey, watch it with the "pasty white guy" comments, if you please, TIA.

As a pasty white girl who is more vampire than human due to a lack of sunlight exposure, I say it lovingly and with care. It is ok friend, I am not exactly the great outdoors' best friend here to shame anybody. :shobon:

Truga
May 4, 2014
Lipstick Apathy
lol pasty
more like rusty

Sabreseven
Feb 27, 2016

The Titanic posted:

I believe this too. But the one snag I have is the 64-bit stuff they took apparent months to hack in. I'm not a video game engine writer, but making a switch like that seems, to me, that it needs to go all the way down to the core. Everything on top of it would then need to be fixed to support it as well. Out of all the stuff they talked about doing, I felt like converting a 32-bit engine to support 64-bit scales and sizes would be the most difficult "ground up" sort of thing. It's the kind of change where most people would say "gently caress it" and start writing a new engine from scratch so they didn't forget something or break something else reliant on the wrong number convention.

Am I wrong in this thought? 64-bit is really one thing you can't just sort of build an external dll to handle like some kind of magical mcguffin. If they did convert to 64-bit, that claim of 50% engine modification seems legitimate.

Of course this also means you can't just merge in stuff from another branch of the old engine because literally nothing is compatible outside of maybe error messages or something utterly pointless and disconnected from the actual engine handling.

As a small example, look at the fuss from the modding community over the 64-bit Skyrim Special Edition. And that's a game where it's basically the exact same game and tools. Some stuff works, but anything worth a drat needs to be rebuilt. It's not just a matter of clicking a "convert to 64-bits" check box.

So tell me guys and girls, an I wrong here? Is the conversion to 64-bit not as big a deal as I believe it to be for a game engine?

Just to add something, Lumberyard does not mention 64 bit precision anywhere in it's documentation and I can find no mentions of it at all. Might just be that I can't find it or that it is burried, but I'd find it hard to believe Amazon devs would have had any prior use for it. :shrug:

I don't know what that means, if anything, as I'm still on holiday and quite drunken.

The Titanic
Sep 15, 2016

Unsinkable

Sabreseven posted:

I had to check, it's not actually a photoshop, it's on the site clear as day.

I wonder how they worked that figure out, it's in linear kilometres and not 'squared' or even 'cubed', yet how do they make such a claim when they know full well 99.9 of those 100 are full of empty space and nothing to find?

I'm leaning towards thinking "false advertising".

1 x sextillion km = 1,000,000,000,000,000,000,000km = no way they made an in game map 100x larger than that.

I'd be curious to know the math behind it.

Or if they chose the number purely because it has sex in it. There's a fun dirty underbelly to the whole Star Citizen mythos that CIG allows to exist, sort of indirectly nurtured it, and only really goes after it if it's too horrible and disgusting and people complain.

The whole Second Life thing is very real, and though CIG lacks the talent to build a Second Life clone, they still foster that twisted type of community.

The Titanic
Sep 15, 2016

Unsinkable

Truga posted:

lol pasty
more like rusty

I'm gonna tear myself in half over this one now. :sweatdrop:

ripptide
Jul 28, 2016

Sabreseven posted:

Just to add something, Lumberyard does not mention 64 bit precision anywhere in it's documentation and I can find no mentions of it at all. Might just be that I can't find it or that it is burried, but I'd find it hard to believe Amazon devs would have had any prior use for it. :shrug:

I don't know what that means, if anything, as I'm still on holiday and quite drunken.

Assuming they're telling the truth (a huge stretch IMHO), it doesn't really enter into it. Assuming Lumberyard is simply a 3.8 CE branch with modified networking and several features deprecated, then they'd just end up slapping whatever logic they used on their earlier 3.7 version of CE to make a "new" StarEngine, or take the bits out of Lumberyard they wanted, like networking, and wedge them into their Frankenengine. It doesn't sound like they're actually using the "core" of Lumberyard, and the claims seem to be that there is little if any great difference between CE 3.7 and CE 3.8, which is the part I find hard to believe. But it's all a shell game.

ewe2
Jul 1, 2009

Samizdata posted:

I have been trying to convince some of the Reddit crowd it is far more difficult than they seem to think and that they understand nothing of game development.

(Never developed a game myself, but I have worked on several classes of business software.)

Sorry in advance for this rant, I just wanted to make it clear as clear why there are problems with CIGs/Parrys "explanation". Please point out mistakes or confusions/omissions.

Just managing the pieces of a website in git can teach you a lot about how VCS actually works and not how Ben Parry wants you to believe, like just skipping main development line history. Good VCS patterns are about minimising merge conflict and small, manageable deltas, regardless of the size of the project.

Let me break it down into a hypothetical, the kind of hypothetical that the Reddit crowd hates because they'd have to apply braincells to it, and let's pretend we're using git because its an excellent distributed VCS that lets you decide how to manage your workflow:

You've got engine code, it's made up of different bits that different groups of developers can work on, and like a good game company you want to make modifications to make the greatest game ever and you want builds to work so you can demonstrate how things are going (you know, not like SC). There will be a bunch of stuff that doesn't use the engine at all, ignore that in this discussion, it would be added at the build branch stage to make a build work and then get added to the main branch. Here we're only concerned with bits that need the engine code.

Ideally we'll have a development branch, a build branch and a main branch. You're the guy coordinating this because your developers are all working on their bits of the engine and when they put in changes, you make sure all the different bits agree and you take a snapshot of the current development branch and call that the build branch (and add those bits I mentioned above), and if it builds, those changes make it into the main branch. Clear so far? You can give these snapshots whatever name/version you like as long as it makes sense to everyone.

Ok, so down the track your builds are going fine but meanwhile the engine developer has released a new version of the engine and you want to take advantage. So you grab the new engine code, and to be safe, you clone a new copy of the original engine code and you do a merge to see what the changes are and make a diff from that. You now literally have what changed between engine versions. Well, like you would expect with a new engine version, they've changed the API you use to access its code and they've restructured its different bits quite a bit, there are new bits, older bits have gone. You do the same technique as before, comparing your current main branch (NOT the development branch, guess why) to the code and oh dear there'll be merge conflicts everywhere, the engine is quite different. What to do?

At this point we are up to BEFORE the LY fork, at 3.8 whatever version. We can break the task down: some bits can be easily discarded, some bits will be added, but there'll be a chunk that will have to be integrated piece by piece preferably along structural lines and meanwhile you have to educate the developers who can't continue along the lines of continuous development/builds until these changes are made. You have to educate the developers on the changes to the API, you have to reassign developers to the bits that are changed/new, and you may have to take a deep breath and throw a lot of good code away simply because you don't have the time or resources to rebase everything. "Rebase" sounds simple but only works if your modifications are only in the parts of the new code that didn't change, and in the case of an engine only some of that will be true.

Ideally, you can give some developers the freedom to rebase their own development work on the new engine code, but in some cases you'll have to do the work yourself and get them to clone from that. And THEN it's back to making the builds work, having "rebased" on the new code and then you've got a main branch which is a fork off the engine code.

And THEN you have the LY fork. Take the above scenario and repeat, unless you're prepared to simply throw away all the previous work. Unless the LY fork is amazingly compatible which I do not believe for a second.

I want to point out that as far as I understand, game development is rarely this organized or as careful. An object hierarchy is fine for business software development but usually only gets as far as the UI and maybe file operations but everything else is written pedal to the metal good old functional programming and that is a dog to manage even with the help of a VCS. The whole point of object orientation was to make large projects even feasible but that breaks down with the way games work which do multiple things at the same time like a mini-OS, it's that complex.

So when Ben Parry tries to tell me that it was easy I'm just dumbfounded. Because he should know better. And this discussion is only applicable to if they did it as he claims, ripptide might be closer to the truth.

DancingShade
Jul 26, 2007

by Fluffdaddy

ewe2 posted:

Sorry in advance for this rant, I just wanted to make it clear as clear why there are problems with CIGs/Parrys "explanation". Please point out mistakes or confusions/omissions.

Just managing the pieces of a website in git can teach you a lot about how VCS actually works and not how Ben Parry wants you to believe, like just skipping main development line history. Good VCS patterns are about minimising merge conflict and small, manageable deltas, regardless of the size of the project.

Let me break it down into a hypothetical, the kind of hypothetical that the Reddit crowd hates because they'd have to apply braincells to it, and let's pretend we're using git because its an excellent distributed VCS that lets you decide how to manage your workflow:

You've got engine code, it's made up of different bits that different groups of developers can work on, and like a good game company you want to make modifications to make the greatest game ever and you want builds to work so you can demonstrate how things are going (you know, not like SC). There will be a bunch of stuff that doesn't use the engine at all, ignore that in this discussion, it would be added at the build branch stage to make a build work and then get added to the main branch. Here we're only concerned with bits that need the engine code.

Ideally we'll have a development branch, a build branch and a main branch. You're the guy coordinating this because your developers are all working on their bits of the engine and when they put in changes, you make sure all the different bits agree and you take a snapshot of the current development branch and call that the build branch (and add those bits I mentioned above), and if it builds, those changes make it into the main branch. Clear so far? You can give these snapshots whatever name/version you like as long as it makes sense to everyone.

Ok, so down the track your builds are going fine but meanwhile the engine developer has released a new version of the engine and you want to take advantage. So you grab the new engine code, and to be safe, you clone a new copy of the original engine code and you do a merge to see what the changes are and make a diff from that. You now literally have what changed between engine versions. Well, like you would expect with a new engine version, they've changed the API you use to access its code and they've restructured its different bits quite a bit, there are new bits, older bits have gone. You do the same technique as before, comparing your current main branch (NOT the development branch, guess why) to the code and oh dear there'll be merge conflicts everywhere, the engine is quite different. What to do?

At this point we are up to BEFORE the LY fork, at 3.8 whatever version. We can break the task down: some bits can be easily discarded, some bits will be added, but there'll be a chunk that will have to be integrated piece by piece preferably along structural lines and meanwhile you have to educate the developers who can't continue along the lines of continuous development/builds until these changes are made. You have to educate the developers on the changes to the API, you have to reassign developers to the bits that are changed/new, and you may have to take a deep breath and throw a lot of good code away simply because you don't have the time or resources to rebase everything. "Rebase" sounds simple but only works if your modifications are only in the parts of the new code that didn't change, and in the case of an engine only some of that will be true.

Ideally, you can give some developers the freedom to rebase their own development work on the new engine code, but in some cases you'll have to do the work yourself and get them to clone from that. And THEN it's back to making the builds work, having "rebased" on the new code and then you've got a main branch which is a fork off the engine code.

And THEN you have the LY fork. Take the above scenario and repeat, unless you're prepared to simply throw away all the previous work. Unless the LY fork is amazingly compatible which I do not believe for a second.

I want to point out that as far as I understand, game development is rarely this organized or as careful. An object hierarchy is fine for business software development but usually only gets as far as the UI and maybe file operations but everything else is written pedal to the metal good old functional programming and that is a dog to manage even with the help of a VCS. The whole point of object orientation was to make large projects even feasible but that breaks down with the way games work which do multiple things at the same time like a mini-OS, it's that complex.

So when Ben Parry tries to tell me that it was easy I'm just dumbfounded. Because he should know better. And this discussion is only applicable to if they did it as he claims, ripptide might be closer to the truth.

That's way too much word vomit thanks.

ewe2 posted:

I'm just dumbfounded

This is your summary.

DancingShade fucked around with this message at 07:37 on Dec 29, 2016

Tarquinn
Jul 3, 2007

I know I’ve made some very poor decisions recently, but I can give you
my complete assurance that my work will be back to normal.
Hell Gem

Beer4TheBeerGod posted:

Isn't that an alt for Al Bester or whatever his name was? Some kind of B5 weeaboo equivalent?

Yeah, I am pretty sure that is our old insane friend Bester. Good times. :unsmith:

Sabreseven
Feb 27, 2016

ripptide posted:

Assuming they're telling the truth (a huge stretch IMHO), it doesn't really enter into it. Assuming Lumberyard is simply a 3.8 CE branch with modified networking and several features deprecated, then they'd just end up slapping whatever logic they used on their earlier 3.7 version of CE to make a "new" StarEngine, or take the bits out of Lumberyard they wanted, like networking, and wedge them into their Frankenengine. It doesn't sound like they're actually using the "core" of Lumberyard, and the claims seem to be that there is little if any great difference between CE 3.7 and CE 3.8, which is the part I find hard to believe. But it's all a shell game.

I've got a feeling the whole thing will unravel during 2017 and if my gut feeling is correct, it's going to be all kinds of funny. :) One of my workmates described it as "Catching the clown loving the neighbours dog at their kids 5th Birthday party kind of funny". :shrug:

ewe2
Jul 1, 2009

DancingShade posted:

That's way too much word vomit thanks.

Ah, a Redditor. Baby steps, commando o9.

Bofast
Feb 21, 2011

Grimey Drawer

Erenthal posted:

No you see CIG already told us that the operating costs of the big most powerful ships will be so massive when it comes to fuel, ammo, crew, rations and so on that players will only use these ships when absolutely necessary and then only when in huge organisations.

Even if Star Citizen came out (it won't), it would be hilarious to see all those whales with their giant ships that they could not use because they could not scrape together the resources to afford the costs.

Young Freud
Nov 26, 2006

Bofast posted:

Even if Star Citizen came out (it won't), it would be hilarious to see all those whales with their giant ships that they could not use because they could not scrape together the resources to afford the costs.

Or be personable and communicable enough to gather and command a decent crew. It would be like every team-based FPS ever rolled into a single package.

AbstractNapper
Jun 5, 2011

I can help

ewe2 posted:

Sorry in advance for this rant, I just wanted to make it clear as clear why there are problems with CIGs/Parrys "explanation". Please point out mistakes or confusions/omissions.
(...)

So when Ben Parry tries to tell me that it was easy I'm just dumbfounded. Because he should know better. And this discussion is only applicable to if they did it as he claims, ripptide might be closer to the truth.
What Parry says, or what his latest iteration said (when I last read the Frontier forum thread, a few hours ago) is this:

They changed nothing with the switch. Their custom code remained intact.

How? They did not switch to LY proper. The LY fork is something still foreign to them and way off if they ever decide to merge with it.

What they did was "switch" to the 3.7 "history point" of LY, which is identical to CryEngine's 3.7 snapshot and is the point where StarEngine was forked out off. And they say "switch", but this amounts to a whole lot of nothing at this stage. Because it's pointless on its own (you literally do nothing --maybe a copy of a license and readme files-- and voila you've switched) and not an actual transition to anything different.

They had gained nothing out of the LY features, but maybe the license and the "right" to say they are on "LY" now... (which I don't think they can technically say that --but they can "sell" it as such apparently).

And they could do that sort of "switch" because, according to Ben, Amazon's license of the CryEngine is for source code that goes further back into the past of CryEngine than the 3.8.x point, where Amazon forked off and made their adjustments/ customizations. So it does include the 3.7 where they "switched".

What Parry's rough paint drawing shows is Star Engine remaining still forked off at the same point (no merging back with LY proper) and *essentially* in its own former branch, completely unaffected from the "switch". The only thing changing in the two drawings is the color of the "base" line which in the "before" is the CryEngine code, and in the after it is still the exact same CryEngine code (until LY's fork) now labeled "LumberYard legacy code or something".

Of course, It's unclear whether this circlejeck (possible but pointless) switch is what actually happened or what Barry thinks (or explained in his own mind to keep it sane) has happened. I sort of tend to believe him, because it matches the whole image of CIG being incompetent and selling this zero-sum switch as a new cooperation with Amazon that was "like for like" (no it wasn't).

AbstractNapper fucked around with this message at 08:25 on Dec 29, 2016

Chunjee
Oct 27, 2004

Maybe it's crazy to ask the guy but is there even one example feature that is possible on their secret sauce engine that Lumberyard can't do? 64-bit precision is nebulous in meaning considering there is no full sized planet you can circle, pointless.

Edge Blending? Parallax Occlusion Mapping? These are the only two things I could find mention of.

Mekchu
Apr 10, 2012

by Jeffrey of YOSPOS
In case anyone cared from the MWO crew, Living Legends has resumed development.

https://clanjadewolf.net/mwll/

Related to Star Citizen how? It's a CryEngine mod.

https://www.youtube.com/watch?v=HkQSFb0sWYU

Mekchu fucked around with this message at 08:58 on Dec 29, 2016

Runa
Feb 13, 2011

Unfunny Poster posted:

In case anyone cared from the MWO crew, Living Legends has resumed development.

https://clanjadewolf.net/mwll/

Related to Star Citizen how? It's a CryEngine mod.

https://www.youtube.com/watch?v=rX86XBr77_4

https://www.youtube.com/watch?v=HkQSFb0sWYU

What the fuuuuuuu

Mekchu
Apr 10, 2012

by Jeffrey of YOSPOS
I know right?

DancingShade
Jul 26, 2007

by Fluffdaddy

ewe2 posted:

Ah, a Redditor. Baby steps, commando o9.

lol as if I'd lower myself to make a reddit account.

Unlike some people here.

tooterfish
Jul 13, 2013

ewe2 posted:

Ah, a Redditor.
Stop loving swearing.

Skellybones
May 31, 2011




Fun Shoe

AbstractNapper posted:

What Parry says, or what his latest iteration said (when I last read the Frontier forum thread, a few hours ago) is this:

They changed nothing with the switch. Their custom code remained intact.

How? They did not switch to LY proper. The LY fork is something still foreign to them and way off if they ever decide to merge with it.

What they did was "switch" to the 3.7 "history point" of LY, which is identical to CryEngine's 3.7 snapshot and is the point where StarEngine was forked out off. And they say "switch", but this amounts to a whole lot of nothing at this stage. Because it's pointless on its own (you literally do nothing --maybe a copy of a license and readme files-- and voila you've switched) and not an actual transition to anything different.

They had gained nothing out of the LY features, but maybe the license and the "right" to say they are on "LY" now... (which I don't think they can technically say that --but they can "sell" it as such apparently).

And they could do that sort of "switch" because, according to Ben, Amazon's license of the CryEngine is for source code that goes further back into the past of CryEngine than the 3.8.x point, where Amazon forked off and made their adjustments/ customizations. So it does include the 3.7 where they "switched".

What Parry's rough paint drawing shows is Star Engine remaining still forked off at the same point (no merging back with LY proper) and *essentially* in its own former branch, completely unaffected from the "switch". The only thing changing in the two drawings is the color of the "base" line which in the "before" is the CryEngine code, and in the after it is still the exact same CryEngine code (until LY's fork) now labeled "LumberYard legacy code or something".

Of course, It's unclear whether this circlejeck (possible but pointless) switch is what actually happened or what Barry thinks (or explained in his own mind to keep it sane) has happened. I sort of tend to believe him, because it matches the whole image of CIG being incompetent and selling this zero-sum switch as a new cooperation with Amazon that was "like for like" (no it wasn't).

Using a Lumberyard version so old that it's actually the same version of Cryengine that Starengine forked off? That's just crazy enough to work!

tooterfish
Jul 13, 2013

Skellybones posted:

Using a Lumberyard version so old that it's actually the same version of Cryengine that Starengine forked off? That's just crazy enough to work!
And pointless enough to be plausible for CIG.

Tippis
Mar 21, 2008

It's yet another day in the wasteland.

Skellybones posted:

Using a Lumberyard version so old that it's actually the same version of Cryengine that Starengine forked off? That's just crazy enough to work!

It's certainly “crazy”. It's also meaningless, and as such explains why they managed to do it in 1–2 days and why they're making such a big deal out of it. CIG has made a business out of delivering nothing — it's only fitting that their big engine upgrades consists of doing absolutely nothing.

Qwertycoatl
Dec 31, 2008

AbstractNapper posted:

Of course, It's unclear whether this circlejeck (possible but pointless) switch is what actually happened or what Barry thinks (or explained in his own mind to keep it sane) has happened. I sort of tend to believe him, because it matches the whole image of CIG being incompetent and selling this zero-sum switch as a new cooperation with Amazon that was "like for like" (no it wasn't).
It's not exactly pointless - I think it makes sense to start off by doing that if they want to gradually merge the lumberyard features in. I can believe it being a couple of days work fighting tools and importing history, especially if their original 3.7 was some kind of packaged release that doesn't exactly match the source tree Amazon has.

The thing is though, that isn't "switching to lumberyard", that's "making the very first, easiest step in the long and difficult process of switching to lumberyard", so this can only be true if CIG are lying to exaggerate their progress

Raskolnikov
Nov 25, 2003

DancingShade posted:

lol as if I'd lower myself to make a reddit account.

Unlike some people here.

Could have fooled me. *tips fedora*

Adbot
ADBOT LOVES YOU

Zest
May 7, 2007

ACHIEVE HEAVEN THROUGH VIOLENCE

ewe2 posted:

Sorry in advance for this rant, I just wanted to make it clear as clear why there are problems with CIGs/Parrys "explanation". Please point out mistakes or confusions/omissions.

Just managing the pieces of a website in git can teach you a lot about how VCS actually works and not how Ben Parry wants you to believe, like just skipping main development line history. Good VCS patterns are about minimising merge conflict and small, manageable deltas, regardless of the size of the project.

Let me break it down into a hypothetical, the kind of hypothetical that the Reddit crowd hates because they'd have to apply braincells to it, and let's pretend we're using git because its an excellent distributed VCS that lets you decide how to manage your workflow:

You've got engine code, it's made up of different bits that different groups of developers can work on, and like a good game company you want to make modifications to make the greatest game ever and you want builds to work so you can demonstrate how things are going (you know, not like SC). There will be a bunch of stuff that doesn't use the engine at all, ignore that in this discussion, it would be added at the build branch stage to make a build work and then get added to the main branch. Here we're only concerned with bits that need the engine code.

Ideally we'll have a development branch, a build branch and a main branch. You're the guy coordinating this because your developers are all working on their bits of the engine and when they put in changes, you make sure all the different bits agree and you take a snapshot of the current development branch and call that the build branch (and add those bits I mentioned above), and if it builds, those changes make it into the main branch. Clear so far? You can give these snapshots whatever name/version you like as long as it makes sense to everyone.

Ok, so down the track your builds are going fine but meanwhile the engine developer has released a new version of the engine and you want to take advantage. So you grab the new engine code, and to be safe, you clone a new copy of the original engine code and you do a merge to see what the changes are and make a diff from that. You now literally have what changed between engine versions. Well, like you would expect with a new engine version, they've changed the API you use to access its code and they've restructured its different bits quite a bit, there are new bits, older bits have gone. You do the same technique as before, comparing your current main branch (NOT the development branch, guess why) to the code and oh dear there'll be merge conflicts everywhere, the engine is quite different. What to do?

At this point we are up to BEFORE the LY fork, at 3.8 whatever version. We can break the task down: some bits can be easily discarded, some bits will be added, but there'll be a chunk that will have to be integrated piece by piece preferably along structural lines and meanwhile you have to educate the developers who can't continue along the lines of continuous development/builds until these changes are made. You have to educate the developers on the changes to the API, you have to reassign developers to the bits that are changed/new, and you may have to take a deep breath and throw a lot of good code away simply because you don't have the time or resources to rebase everything. "Rebase" sounds simple but only works if your modifications are only in the parts of the new code that didn't change, and in the case of an engine only some of that will be true.

Ideally, you can give some developers the freedom to rebase their own development work on the new engine code, but in some cases you'll have to do the work yourself and get them to clone from that. And THEN it's back to making the builds work, having "rebased" on the new code and then you've got a main branch which is a fork off the engine code.

And THEN you have the LY fork. Take the above scenario and repeat, unless you're prepared to simply throw away all the previous work. Unless the LY fork is amazingly compatible which I do not believe for a second.

I want to point out that as far as I understand, game development is rarely this organized or as careful. An object hierarchy is fine for business software development but usually only gets as far as the UI and maybe file operations but everything else is written pedal to the metal good old functional programming and that is a dog to manage even with the help of a VCS. The whole point of object orientation was to make large projects even feasible but that breaks down with the way games work which do multiple things at the same time like a mini-OS, it's that complex.

So when Ben Parry tries to tell me that it was easy I'm just dumbfounded. Because he should know better. And this discussion is only applicable to if they did it as he claims, ripptide might be closer to the truth.

Honestly, thanks. This has really helped me to wrap my head around the clusterfuck that is VCS in gamedev environment (and CIG's horrific butchery of said concept).

E: clarity

Taxxe:

Ninkasi says hello

Zest fucked around with this message at 10:00 on Dec 29, 2016

  • 1
  • 2
  • 3
  • 4
  • 5