quote:

Everyone says get a refund

MedicineHut posted:

According to Ben Parry, CIG dev that loves to speculate in CIG's behalf over at the Frontier forums instead of posting at the RSI forums, there was nothing really to be merged. The base CryEngine code that Star Engine developed on is basically the same base Lumberyard code Star Citizen is supposedly now using. To all effects all a couple of CIG devs did in one day or two (Ben and Chris Roberts dixit) was basically copy / pasting all the CIG additions (64b positioning, procedural tech etc) over.

You obviously have no loving idea about game development.

Der Shovel posted:

Seriously. Even migrating from one version of the SAME ENGINE (not two different and separate forks of the same engine) can be a loving nightmare where half your poo poo randomly breaks. Talk to anyone who uses Unity regularly about Unity version changes and watch them sweat. And note, this is a product where it's been designed to make this process as painless as possible and ensure that versions 4.1 and 4.2 are as compatible as possible, not two separate bunches of coders going in different directions and adding poo poo as they see fit.

I agree with both your points as well. If StarEngine actually featured any significant amount of custom code porting it over to Lumberyard is going to be a significant undertaking. So they're lying one way or another!

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.

D_Smart posted:

Dude, keep this sort of poo poo off the thread? I know they are goading you to do it. Still don't post this poo poo.


wot!?

1) He first posted he was in "sunny CA"

2) Shortly after he changed it to "Portland", but not before someone already nabbed the excerpt

3) Someone recently noticed that when he first appeared (Mar 2016), in this post, he had his cat pics. Then, less later (June 2016), he removed (archive) them. And, you know, dumb fucks sharing images online, tend to forget all the XIF data in them, and which some sites tend not to strip.

I dindu nuffin'

radd posted:

In other news, Elite:Dangerous delivers the Constellation with P52 snub fighter before CIG, even though it was never within the original scope of E:D.

http://i.imgur.com/GRHxG0t.gifv

Tijuana Bibliophile posted:

void commandoButtonPress(commando Commando(commando.active, string buttonPressed))
{
server.sync();
if (buttonPressed = "medkitbutton") { Commando.runanim(usemedkit) }
server.sync(); //uuhh don't remove this guys
delay(300);
//sooo let's fix those broken references???
if ( ! Commando.animrunning)
{
commandoButtonPress(commando.next) // check for faulty execution, correct
}
else { buttonPressed = ""}
server.sync();
delay(300);
delay(400); //a bit more needed for the krauts I guess
server.sync();
server.sync(); //gotcha
}

Klyith posted:

TT, the guys that do the lego games, are still around and doing multiple lego games every year. It wasn't owned or run by Erin Roberts, he was just an upper level guy there.


Oh man if we got some more of this but with dinosaurs?!

Tippis posted:

Oh, right. That's another bit of troublesome tech that megamap could render void if they applied it correctly.

Yes, 64bit is necessary if you want to track tons of details at large distances but only if the objects you're tracking are spread over a static coordinate system. You need to know that, when one player is at [4k, -16km, 2km], another player at [-1km, +12km, 0km] isn't spazzing out due to low distance granularity when both are so far from [0,0,0] (rendering is less of an issue here — that's converted to and done at 32bit regardless because that's what your GFX card is using). Everyone exists within the same coordinate system, and everyone needs to maintain reasonable precision not to skip around too much.

But… if you really embraced the megamap concept, then that would only ever have to happen on the server side, and you'd have other means of working around that 64bit issue anyway. All world-level position tracking is done there, and nowhere else, so it's only on the server that you need any kind of high precision. Locally, it wouldn't be a problem to just use 32bit because the player is always at [0,0,0] and anything that's really far off will be… well… far off so they wont' skip around anyway. A ±1m imprecision in location won't matter because the other guy is 20km away and can hardly be seen anyway — he's a static pixel no matter how ridiculously imprecise that placement is. And from his perspective, he is at [0,0,0] and you are 20km away.


Well, sure, that may be what it ends up as — we're talking about the concept as it has been described by Tracy.

Chev posted:

Forgetting whatever they said about megamap for a moment, one of the ways described in planetary rendering literature and the one most used works with a dual system: on one hand you have 64 bit coordinates for each object (which gives necessary precision for handling everything at the planetary scale), on the other hand on each frame you choose a point of reference (usually the camera), compute the position of every object relative to that point and store it in 32 bit. This means you'll have all your coordinates in familiar 32 bit coordinates for rendering. The loss of precision due to going from 64 to 32 bits won't be noticed because it'll be for objects that are far from the camera so they won't be close enough that you'd notice jittering. There's special provision for objects that are too big (more than 13 kilometers) where you have to handle them in parts (the more extreme version being to do that operation on each vertex, probably happens for stuff like orbit overlays usually), and that's purely the graphical side, but to integrate existing physics engine you'd do a similar process (group a number of objects in a zone no bigger than what the physics engine can handle, convert them all to a local 32 bit coordinate system, do physics, convert back to universal 64 bits, repeat for all object clusters. Kerbal works that way for example).

Tijuana Bibliophile posted:

Happy for you commando

How much of Roberts' dreams did you manage to claw back?

Tijuana Bibliophile posted:

You'll get a Switch and half a ps4 for that stack of jpegs

Ol Cactus Dick posted:

If they are starting parts of it in late 2017 then

1. It ain't coming out this summer MoMA

2. 2019 may be a possibility but probably not.

Hav posted:

{{{hug}}}

DapperDon posted:

I laughed my rear end off at the level of shilling effort that went into this apology post.

Mirificus posted:

MeLKoR posted:

Have you watched Westworld? Chris did.

quote:

This Valentine’s Day, we’ve got love and rockets! What better time to introduce that special someone to the wonders of Star Citizen? To that end, we’ve created a special offer that focuses on ships that let you take on the galaxy together. From the stylish 85x runabout (perfect for a romantic evening watching the traffic at Port Olisar) to the massive Starfarer Gemini tanker (room for the whole family… and then some!), we have multi-crew ships for every occasion — plus special discounts on two-packs!

Not quite ready to commit? We’re also giving you (and your loved ones) the opportunity to try Star Citizen for free! Just click HERE, use the code SHARETHELOVE and you’ll receive access to a multi-crew Constellation Andromeda to test fly through Sunday, February 20th. Ready to bring a friend to Arena Commander, Star Marine, Crusader and beyond? A limited number of discount starter packages are also available below. Sale runs through February 28, 2017 or while supplies last.

quote:

Thinking about getting serious? Nothing says ‘I care’ like the rugged Aegis Vanguard deep space fighter, a favorite among long range mercenary pilots and well-armed explorers alike. With firepower and the ability to get you and your co-pilot out of the most dangerous situations, the twin-boom Vanguard design is a favorite from Earth to the frontier.

By popular request, we are also making available the Battlefield Upgrade Kits (BUKs) for the Vanguard line, which allow captains to swap between variants on a single chassis. Please note that these upgrades are not available in the current alpha build of Star Citizen; their functionality will be added in a future patch.

Ol Cactus Dick posted:

How many Star Citizen dollars do I get for 1 real dollar?


drat the ship prices will never stop making me lol

Quavers posted:

Elite's 2.3 beta has started, but no multi-crew yet. Stupidly huge patch notes warning...

AP posted:

https://www.twitch.tv/videos/125631497?t=2h27m45s

Beer4TheBeerGod posted:

Alternatively they could have a forgiveness sale. Anyone with a refunded account can buy a new package and have their account and backer rewards restored.*

*$66.99 Penance Fee Applies

AP posted:

https://twitter.com/AboutElizabethM/status/839171292985163777

No Mods No Masters posted:

the disease is spreading

https://twitter.com/bobvids/status/842564053704888320