Author Topic: Star Citizen Dev Progress Watch  (Read 528351 times)

jwh1701

  • Guest
Re: Star Citizen Dev Progress Watch
« Reply #330 on: November 25, 2018, 04:39:42 PM »
Well 3.4 isn't looking too healthy at this point.

Definitely is not, but I love to spread rumors about waiting for certain patches as being the next great one.

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #331 on: November 26, 2018, 04:27:48 AM »
Well 3.4 isn't looking too healthy at this point.

I'm sure they'll get the 96% completed by Dec 23rd
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

Judge_dolly_OG

  • Sr. Member
  • ****
  • Posts: 261
Re: Star Citizen Dev Progress Watch
« Reply #332 on: November 26, 2018, 04:43:18 AM »
I'm sure they'll get the 96% completed by Dec 23rd

Easy to get it to 96% completed if you move it all out to the next release.

tapsforehead.jpg

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #333 on: November 29, 2018, 03:08:32 PM »
"So hey I figured out how to get through the No-Fly zone at Lorevill if anyone wants to grief the poo poo out of people.

Turns out the barrier is server-side. Disconnect your internet, fly through real quick to the little deck for the habitation area or the ship dealership, reconnect your internet. Do it fast enough and you won't get booted, and you'll legit be able to fly around the "City" part shooting people. Good times.
"

https://forums.somethingawful.com/showthread.php?threadid=3800238&pagenumber=5489&perpage=40#post490223219


The barrier isn't server-side. It's just an invisible wall with a shader.

Simply put, once the client disconnects, the server stops receiving input. Once that happens, the server knows nothing about the client. At the time the client breaches the no-fly-zone (which is just a transparent wall) via collision, the server (off-line) would have missed it. It's not different from glitching through any other level geometry, falling through the planet surface etc.

The no-fly-zones are part of the level. They are not server side because both the client and server ARE running the SAME level. That's how positioning works.

In some cases you don't even need to be disconnected from the server in order to breach the barrier, since it relies on collision detect - which can fail. If the collision response isn't fast enough before the server gets the input and responds, you can breach the world. CryEngine (and also Lumberyard) have had this problem since forever because the networking layer sux balls.
« Last Edit: November 29, 2018, 03:18:41 PM by dsmart »
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

jwh1701

  • Guest
Re: Star Citizen Dev Progress Watch
« Reply #334 on: November 29, 2018, 03:13:17 PM »
"So hey I figured out how to get through the No-Fly zone at Lorevill if anyone wants to grief the poo poo out of people.

Thx for the details on how its working, I always enjoy learning about how things work.
Not sure how ED works but there is a delay between anything you try or do vs what is detected and registered by the server by using the same method.
« Last Edit: November 29, 2018, 04:14:54 PM by jwh1701 »

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #335 on: November 29, 2018, 03:19:40 PM »
Not sure how ED works but there is a delay between anything you try or do vs what is detected and resisted by the server by using the same method.

That's because the server is fully authoritative. Meaning the client can't do anything without the server knowing about and approving it.
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

David-2

  • Full Member
  • ***
  • Posts: 152
Re: Star Citizen Dev Progress Watch
« Reply #336 on: November 29, 2018, 03:41:30 PM »
I thought disconnecting from the internet (and other IP manipulation) was such a well-known and widely available cheat method that games were architected/designed with that in mind from the beginning.  "Never trust the client," right?

And as far as collision detect goes why would CIG think that collision detect against their invisible wall would work any better than collision detection anywhere else in SC?

jham

  • Newbie
  • *
  • Posts: 35
Re: Star Citizen Dev Progress Watch
« Reply #337 on: November 29, 2018, 03:53:46 PM »
Although I haven't watched him do it, the Twitch streamer TheFew says he can get through the barrier by being some distance above it and then cutting engines to quickly fall through it. He has streams of him flying under the barrier.


He also "landed" on the train tracks to have fun with the train going through his ship.

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #338 on: November 29, 2018, 04:06:54 PM »
hey, who remembers when I said the same thing weeks ago?

"They're likely culling things based upon the view frustrum of the camera"

Well, read this developer FUD



A game developer and programmer of considerable experience and years in the industry has offered a commentary on the current state of the SC engine. He has given permission for it to be posted here. No it isn't Derek Smart - this is a European dev of some calibre.

Background - it was a surprise to a few folks in the industry that CIG took the decision to promote a free fly given the poor state of the builds on the PTU. A conversation took place around many of the deep technical issues that CIG's team have been unable to address, and a layman's commentary was requested around some specific 'glitches' that are present in the current build. So here it is in full.


Star Citizen Free Fly build, a developer's commentary:

DISCLAIMER
Most of these are going to be pure, wild, stabs in the dark - what I would start with if I had to debug them. But keep in mind that I have no idea what their codebase is like (besides clearly not ideal), so plenty of them are probably far off the mark.

Glitch type: random teleportation
 


I don't know what the is going on here. This is so amazingly broken, it could very well be caused by quite literally anything. So, this is going to be wild speculation: Animations often have movement associated with them. A good example of this is a walk animation cycle - animators can put in the forward momentum, so it's perfectly synced to the animation, and can be easily sped up or slowed down while still looking right. It's possible that there's a tiny bit of movement during the "fidelitiously drink from glass" animation. Or perhaps the glass is a physical entity with collision detection. And either way, it added movement to the commando, which caused the commando to clip inside some other collision object (such as the nearby bar), which then caused it to freak out and deposit them elsewhere. The second jump? Who knows. That's pure magic. It's probably a separate, but related, issue to the first jump, where rapidly changing environments in a way that was never supposed to happen caused another system to explode. It seems to have teleported the commando far away, perhaps to another side of the moon, since they're rotated horizontally.

Gitch type: clipping into stuff erases ships

https://clips.twitch.tv/BovineUglyBurritoBigBrother 

Another physics oddity. Since this is going to come up a lot, we need to go over the basics of physics in game development. Physics is a bunch of really complex math, and one of its primary tasks is resolving and providing response to collisions. When two objects overlap, the collision must be resolved by calculating how much each object is penetrating (har har) each other and in what direction. A response can then be provided in the form of deciding how to move those objects apart so that they are no longer colliding, and then applying force to them. This prevents objects from clipping through each other, and gives them that nice, warm and fuzzy physical-y feeling that you get when you throw a heavy ball at a tower of boxes and the boxes realistically tumble and fall in response to the ball's weight.

That's how it's supposed to work. In the 'verse, it is clearly not working as it is supposed to. What happens here is that the physics are failing at that resolve and response step. The objects are penetrating each other, but the physics engine can't figure out how to correctly resolve it. What usually happens in such a case is that one or both of the objects goes flying away at an extremely high velocity - we've all seen this happen in games like Skyrim. A cheap way of 'fixing' that problem (without actually fixing what is causing the underlying problem) is to simply detect when an object is suddenly given a super huge velocity, and deleting it. Poof, problem solved. Sort of. In this case, the chariot blinks out of existence, leaving the hapless commando trapped in limbo, because it was never designed to know what to do when the chariot he was piloting no longer exists and he did not have time to perform a fidelity immersion animation to return to a not-piloting-chariot state. This looks like what is happening here.

Glitch type: bind culling on objects that are visible for player

https://thumbs.gfycat.com/SomeSilkyBaiji-max-14mb.gif

Haha. Bad math. They're likely culling things based upon the view frustrum of the camera, but forgetting to keep it in sync when switching between camera views and environments. Lots of things can affect the camera's state like that, especially cramped environments - and I'm sure that they're forgetting to keep the version of the camera's position/rotation/view matrix updated properly before culling with it.

Glitch type: animation glitches

https://media.giphy.com/media/uiKYLa...xmhn/giphy.gif

Holy stimperor that's disturbing. And what happens when animation states go bad. The commando was presumably supposed to use a immersion mocap to exit the chariot, but instead, somehow got into the "nah, let's just walk forwards lol" state due to extremely good programming. But, his legs were all ready to be part of that fidelity animation... But then were told to do a bog-standard walk animation instead, so they did the best they could and split the difference. Basically, the code that handles animation was trying to go in two directions at once, like the creepy guy with each eye pointing in a different direction. The result was Fidelity™ to make the stimperor proud.

Glitch type: weapon fire curves when strafing



So they're adding the chariot's velocity to the projectile's velocity as it's fired. Makes it easier to lead shots when you're aiming, in the worst, brokenest possible way that immediately falls over when anyone who has touched a flight sim tries to play it. Revisit trig, this is stuff that is both simple enough that it should have been covered in a college course and stuff that has been solved so many times over that you could have found a complete solution in ten seconds of searching. I award you no points.

Glitch type: going too fast into planet breaks collision detection

https://giant.gfycat.com/JitteryImpe...gurbuzzard.mp4

He's clipping through the planet's ground before the collision detection has a chance to stop him. Their coordinate system was obviously not intended to function underground (sorry, anyone looking forward to hot subterrainian mining action), and promptly had a panic attack, breaking everything simultaniously. Only God knows what happened in the final few moments of that commando's short, painful life.

Glitch type: Tposing multiple characters in 1 spot

https://clips.twitch.tv/EmpathicAver...tmullinsLitFam

A t-pose happens when the animation data for the commando becomes corrupted, and it reverts to its default state. Some of the fidelity immersion animations that were supposed to happen likely get corrupted when they try to resolve collision with another commando occupying the same space, as described previously. Apparently they just turn off collision detection with the offending object in that case, since you can't very well delete a commando like you can a ship.

Glitch type: rubber banding on NPC



Rubber banding can happen in most any multiplayer game that uses network prediction - that is, predicting that if a commando is running to the left, he'll probably continue running to the left until the network tells him otherwise - and the networking starts slowing down so those new packets saying "hey wait, I'm actually going right now" don't come through until several seconds later, leading to the commando rubber banding back to its correct, not-based-off-of-old-predictions position. This is usually caused by a bad connection that's suddenly dropping a lot of packets or getting a far higher ping than usual. It can also be caused by terribly written netcode.

Glitch type: latency issues/manipulation



A combination of all of the above, plus the wonderful fact that their clients are fully trusted and you can freely hack the poor thing to smithereens, as has been discussed many times before. Zany hijinks ensue in the more lethal than COD e-sports sensation!

BONUS COMMENTARY:

As much as they like to claim that they're the Best Damn Space Simulator Ever, they're not. Like, at all. Nothing about the game is a simulation, it's a bunch of parlor tricks hacked together to create the illusion of a coherent world, which, as we've seen, is not doing a great job of hiding the fundamental, structural cracks behind the cheap curtains. It's not inherently a bad thing because almost every game is made just like this - cheap as much as humanly possible in order to give the best possible experience to the players, most of which will never be the wiser anyway.

AI is a great example of this because it's blatantly obvious that they have not designed the game to be an NPC simulation first, game second - which they need to in order for it to work as they claim for the reasons described above. Whatever AI they put in immediately gets released-state Radiant AI-esque handcrafted stuff pasted on top of it. Just look at how many iterations a single mission giver has been through. No amount of jackets is going to magically tip the switch and turn glorified handcrafted pathfinding waypoint lists into something that shatters the Turing test and ushers us into a brave new world of I, Robot existential crisis.
« Last Edit: November 29, 2018, 04:08:44 PM by dsmart »
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

jham

  • Newbie
  • *
  • Posts: 35
Re: Star Citizen Dev Progress Watch
« Reply #339 on: November 29, 2018, 05:26:12 PM »
Great analysis from that dev. However the 2nd item (Glitch type: clipping into stuff erases ships), might have happened because the player took too long to leave and the base stored his ship.

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #340 on: November 30, 2018, 04:17:35 PM »
Ben Parry is back!

https://forums.frontier.co.uk/showthread.php/435505-The-Star-Citizen-Thread-v9/?page=605

So he has now walked back everything he said about their use of "maps" during our arguments which prompted my writing these posts:

http://www.dereksmart.org/forums/reply/1812

http://www.dereksmart.com/forum/index.php?topic=9.msg289#msg289

I  am completely shocked.
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #341 on: December 01, 2018, 04:55:18 AM »


https://robertsspaceindustries.com/roadmap/board/1-Star-Citizen

:emot-lol: yeah, 3.4 is totally coming out this month
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

jwh1701

  • Guest
Re: Star Citizen Dev Progress Watch
« Reply #342 on: December 01, 2018, 03:42:53 PM »
https://robertsspaceindustries.com/roadmap/board/1-Star-Citizen

:emot-lol: yeah, 3.4 is totally coming out this month

Definitely not but I trust boredgamer and his unbiased SC intuition for December release.

"Welcome to some more Star Citizen looking at the new Roadmap and Focusing on Star Citizen Alpha 3.4 which will be release around the end of December, while it’s testing phase is expected to start by the end of November."


dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #343 on: December 01, 2018, 03:47:40 PM »
That's on fidelitiously networked train

https://gfycat.com/FearlessHealthyGalapagossealion
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

David-2

  • Full Member
  • ***
  • Posts: 152
Re: Star Citizen Dev Progress Watch
« Reply #344 on: December 01, 2018, 08:04:35 PM »
That's on fidelitiously networked train

CIG: So incompetent that even when they are putting the player on rails in an animation that is literally rails they can't even stay on the rails.

(BTW: Sure is a good thing they spent all that time and money getting to a "64-bit coordinate system".  That necessary ability to position an object to within an atom's width anywhere in their universe is definitely paying off...)
« Last Edit: December 01, 2018, 08:10:54 PM by David-2 »

 

SMF spam blocked by CleanTalk