What's new

What is Net-Code and how can we help fix it?

MadeOfMetal

Kenshi Srubtastic,Cyrax, Special Forces Mains
You really think NRS doesn't know about GGPO ?

We fucking talk about GGPO ever since MK9 or even before ...

They just use their own crappy netcode, less money spent, and they apply this shit onto every game they launch, swearing "it's awesome".

Don't be fooled : they want money, not quality.

Been there, done that. They evade shit as soon as you say "netcode" ...

It's like someone selling you a broken chair with a feet missing, over and over and over and over and over . . .
i get your frustration, but i feel we can keep trying to push this... obviously you are still in TYM so you haven't given up on mkx. all im trying to do is keep at it and throw together something that could be cheap and easy for them to implement, and show them how they could make, $$$$$ off of it;)
 

Carmine

PSN: CaptCarmine
From the varying reports I have heard about how some people have good connections and other people have horrible connections I would really like to see how the game servers chooses how to route the packets between the client and server, and where the main servers are in America and Europe, because I have had really good connections in some games and horrible connection in others
 

mercureXI

Punching bag that throws fans !
Maybe a petition might help. It got Tremor into the game. ;)
An open letter has been produced in here. We'll see if they'll care about it.

A petition has been done IN HERE for MK9 (netcode fix etc). They couldn't care any less.

Asking them to produce more DLC is hardly the same thing as asking them to get those fingers out of their asses and fix their NRS netcode that has been a pain for ages.

Good luck with a petition.

Ed Boon told me on tweeter he doesn't have any more toilet paper, might come in handy.
 

sub_on_dubs

Online Scrub Lord
"how can we help fix it ?"

IS this a FUCKING JOKE ?

WB has more than enough money to solve that crap.

They could have done a beta test before launching that pile of garbage too.

They just rushed the game out (and MEGA OVER GIGA rushed the PC port), so that they could be getting all the money while SFV is still being developped (yeah these guys WILL do a beta test, they seem to care about QUALITY ... shocker !).

We don't need to HELP fix it ...

What we need to do ... is stop buying Tremor shit and NRS products as long as MKX online isn't fixed.

Meaning no Injustice 2, nothing else.

Either they step up and fix a product that we already give them money for, or no need to advertise any more of the same crap : we don't care, we won't pay anymore ... it's been more than 3 games now ... stop the BS guys ! ! ! ! !

THIS
ENDS
HERE
It really is that easy. I've said the same thing many times. I'm done buying NRS games. If the online is garbage next time I will simply not buy it.

Everybody should follow suit if they want any changes made, but it won't happen, especially with the casual players, which is the majority of their fan base.
 

mercureXI

Punching bag that throws fans !
i get your frustration, but i feel we can keep trying to push this... obviously you are still in TYM so you haven't given up on mkx. all im trying to do is keep at it and throw together something that could be cheap and easy for them to implement, and show them how they could make, $$$$$ off of it;)
I'm still here because the MK community is, overall, great; and because I've grown up with MK in arcades, once you love MK, you can't go back.

But damn, about time we gather together and just decide to shame NRS as a group at every damn event they decide to advertise their shitty DLCs.

These guys will fuck up Injustice 2 too at this rate, and any other game after that.

Fans are the only ones to blame for letting NRS get away with so many failed games when it comes to online.

2015 standards are not "oh hurray, I can punish something that's -15 ... oh wait not quite yet ... but -everything is awesome !-"

Being positive and trying to help them : we are way past that.

MK9 petition proved they don't care about us being polite and constructive.

What they need : a community, as a whole, shaming them every time they show up their lying asses.

That and not buying anything NRS related as long as they let this shit go on.
 

buyacushun

Normalize grab immunity.
Rising thunder uses ggpo and is 2.5 d fighter just like mkx.
I won't hold that against NRS because I don't think anyone knew of rising thunder or GGPO3 before EVO. Plus I think GGPO only really works with 2d fighters. I don't However I don't doubt that the Cannon bros. would license the new system out like they did with GGPO. Those guys are extremely dedicated to Fighting Games.

good question... yes mkx is P2P but the process still involves servers... one thing to note would be the update to refresh the screen with the new data that has already been calculated and flagged. Updates come from the server. even though most of the communication is from player to player we know that the server is used in the process and someone is the host giving the info to the server to make the decision. what comes to mind is KOTH many players in one room. one of them is in contact with the server, if they have loss of packets or a d sync then everyone else will suffer from this.

does that answer your question? or did i do what i always do and not explain it properly?
That answered one question thanks. Is rollback equivalent to extrapolation?
 

GLoRToR

Positive Poster!
I make this thread in hopes that all of us can bond together to help devise a plan to rid MKX of lag between Clients and Servers if at all possible!

lets start with the Basics...







Netcode is a blanket term for anything that somehow relates to networking in online games; netcode is a term most commonly used by gamers when discussing synchronization issues between clients and servers. The actual elements of a game engine that can cause so-called "netcode issues" include, among other things, latency, lag compensation or the lack thereof, simulation errors, and network issues between the client and server that are completely out of the game's hands.

Potential causes of netcode issues:
  • Latency is an unavoidable fact of online games, caused by not only network latency, which is largely out of a game's control, but also latency inherent in the way game simulations are run. There are several lag compensation methods used to disguise, reduce, or cope with latency, however their feasibility varies by application.
  • Tickrate: A single update of a game simulation is known as a tick. The rate at which the simulation is run on a server is referred often to as the server's tickrate; this is essentially the server equivalent of a client's frame rate, absent any rendering system. Tickrate is limited by the length of time it takes to run the simulation, and is often intentionally limited further to reduce instability introduced by a fluctuating tickrate, and to reduce CPU and data transmission costs. A lower tickrate increases latency in the synchronization of the game simulation between the server and clients. Tickrate can vary from 60 ticks per seconds, to 30 ticks per seconds. A lower tickrate also naturally reduces the precision of the simulation, which itself might cause problems if taken too far, or if the client and server simulations are running at significantly different rates. Games may limit the number of times per second that updates are sent to a particular client, and/or are sent about particular objects in the game's world. Because of limitations in the amount of bandwidth available, and the CPU time that's taken by network communication, some games prioritize certain critical communication while limiting the frequency and priority of less important information. As with the tickrate, this effectively increases the synchronization latency. Game engines may also reduce the precision of some values sent over the network to help with bandwidth use; this lack of precision may in some instances be noticeable. Various simulation synchronization errors between machines can also fall under the "netcode issues" blanket. These may include bugs which cause the simulation to proceed differently on one machine than on another, or which cause some things to not be communicated when the user perceives that they ought to be. Traditionally, real-time strategy games have used lock-step peer-to-peer networking models where it is assumed the simulation will run exactly the same on all clients; if, however, one client falls out of step for any reason, the desynchronization may compound and be unrecoverable.
  • Transport layer protocol and communication code: A game's choice of transport layer protocol can also affect perceived networking issues. Should the game use TCP, networking will have a high overhead cost and increased latency. Should it use UDP, the game engine may need to implement its own networking code to handle error conditions and other things that are handled by TCP; this increases the engine's complexity and might itself lead to issues.
Solutions and lag compensation:
There are various methods for reducing or disguising delays, though many of these have their drawbacks and may not be applicable in all cases. If synchronization is not possible by the game itself, the clients themselves may be able to choose to play on servers in geographical proximity to themselves in order to reduce latencies, or the servers may simply opt to drop clients with high latencies in order to avoid having to deal with the resulting problems. However, these are hardly optimal solutions. Instead, games will often be designed with lag compensation in mind.



Many problems can be solved simply by allowing the clients to keep track of their own state and send absolute states to the server or directly to other clients. For example, the client can state exactly at what position it is or who they shot. This solution works and will all but eliminate most problems related to lag. Unfortunately, it also relies on the assumption that the client is honest. There is nothing that prevents a player from modifying the data they send, directly at the client or indirectly via a proxy, in order to ensure they will always hit their targets. In online games, the risk of cheating may make this solution unfeasible, and clients will be limited to sending relative states (i.e. which vector it moved or shot in).
Client-side:
As clients are normally not allowed to define the main game state, but rather receive it from the server, the main task of the client-side compensation is to render the virtual world as accurately as possible. As updates come with a delay and may even be dropped, it is sometimes necessary for the client to predict the flow of the game. Since the state is updated in discrete steps, the client must be able to estimate a movement based on available samples. Two basic methods can be used to accomplish this; extrapolation and interpolation.

Extrapolation is an attempt to estimate a future game state. As soon as a packet from the server is received, the position of an object is updated to the new position. Awaiting the next update, the next position is extrapolated based on the current position and the movement at the time of the update. Essentially, the client will assume that a moving object will continue in the same direction. When a new packet is received, the position may be corrected slightly.

Interpolation works by essentially buffering a game state and rendering the game state to the player with a slight, constant delay. When a packet from the server arrives, instead of updating the position of an object immediately, the client will start to interpolate the position, starting from the last known position. Over an interpolation interval, the object will be rendered moving smoothly between the two positions. Ideally this interval should exactly match the delay between packets, but due to loss and variable delay, this is rarely the case.

Both methods have advantages and drawbacks.

  • Interpolation ensures that objects will move between valid positions only and will produce good results with constant delay and no loss. Should dropped or out-of-order packets overflow the interpolation buffer the client will have to either freeze the object in position until a new packet arrives, or fall back on extrapolation instead. The downside of interpolation is that it causes the world to be rendered with additional latency, increasing the need for some form of lag compensation to be implemented.
  • The problem with extrapolating positions is fairly obvious: it is impossible to accurately predict the future. It will render movement correctly only if the movement is constant, but this will not always be the case. Players may change both speed and direction at random. This may result in a small amount of "warping" as new updates arrive and the estimated positions are corrected, and also cause problems for hit detection as players may be rendered in positions they are not actually in.
Often, in order to allow smooth gameplay, the client is allowed to do soft changes to the game state. While the server may ultimately keep track of ammunition, health, position etc., the client may be allowed to predict the new server-side game state based on the player's actions, such as allowing a player to start moving before the server has responded to the command. These changes will generally be accepted under normal conditions and make delay mostly transparent. Problems will arise only in the case of high delays or losses, when the clients predictions are very noticeably undone by the server. Sometimes, in the case of minor differences, the server may even allow "incorrect" changes to the state based on updates from the client.

Server-side:
Unlike clients, the server knows the exact current game state, and as such prediction is unnecessary. The main purpose of server-side lag compensation is instead to provide accurate effects of client actions. This is important because by the time a player's command has arrived time will have moved on, and the world will no longer be in the state that the player saw when issuing their command. A very explicit example of this is hit detection for weapons fired in first-person shooters, where margins are small and can potentially cause significant problems if not properly handled.


Design:

It is possible to reduce the perception of lag through game design. Techniques include playing client-side animations as if the action took place immediately, reducing/removing built-in timers on the host machine, and using camera transitions to hide warping.


Ideas: posted by others:




and i feel this could be the open beta solution what does everyone else think?

this could be similar to BF4's fix or League of Legends PBE

i think this in time could fix before the tournament scene is over... maybe make mkx playable for years, im interested what others think about flipping this to NRS?



now with all this said, What can we all do or suggest to NRS/WB to get this Netcode issue solved?

i say we should try an open beta environment or something along those lines, could work but may not solve all problems, maybe in time, i would really like MKX or MK11 to benefit from this before it's to late.


post your solution/idea below!


@WidowPuppy

@Temjiin
@KHAOTIC True Grave
@kabelfritz
@Bombardier777
@sub_on_dubs
@The Slaj Jazz
@Wetdoba
@LaidbackOne
@Houndovhell
@Marbledecker
@Eldriken
@Afk Skinny
@beepboop
@Death
@I GOT HANDS

tag anyone i forgot!
I've explained the exact same crap before. Glad to see somebody else sees it too. As for what we can do? Nothing.
- Even if there are network engineers, animators, or genius programmers among the ranks of TYM's players, they will not hire us.
- Even if they hire us, not to that position.
- Even if they hire us to that position, we will not be funded or approved of for development by the holders.
 

IKizzLE

BloodHound
Sigh, it's really time to get to the final stage of grief.....acceptance.
Nothing is going to change as long as people continue to buy their products and DLC.
And that's never going to change either. It sucks but it's the truth.
 

ChaosTheory

A fat woman came into the shoe store today...
I just tried to play online again after three weeks off. What a piece of shit. Welp! Time to go back to only playing MKX in practice mode while dinner is cooking. $500 well spent.
 

MadeOfMetal

Kenshi Srubtastic,Cyrax, Special Forces Mains
I won't hold that against NRS because I don't think anyone knew of rising thunder or GGPO3 before EVO. Plus I think GGPO only really works with 2d fighters. I don't However I don't doubt that the Cannon bros. would license the new system out like they did with GGPO. Those guys are extremely dedicated to Fighting Games.



That answered one question thanks. Is rollback equivalent to extrapolation?
i think its similar in the fact that it estimates, beyond the original observation range, the value of a variable on the basis of its relationship with another variable.
 

MadeOfMetal

Kenshi Srubtastic,Cyrax, Special Forces Mains
I won't hold that against NRS because I don't think anyone knew of rising thunder or GGPO3 before EVO. Plus I think GGPO only really works with 2d fighters. I don't However I don't doubt that the Cannon bros. would license the new system out like they did with GGPO. Those guys are extremely dedicated to Fighting Games.



That answered one question thanks. Is rollback equivalent to extrapolation?
i hope we could get NRS and Tony Cannon to maybe implement a 3d version for this instance!
 

buyacushun

Normalize grab immunity.
i hope we could get NRS and Tony Cannon to maybe implement a 3d version for this instance!
My statement meant that GGPO3 is new and is what's being used on their new 2.5d game. So it's possible no one had a chance to use it. But now I really hope they at least ask them for GGPO3 for Injustice 2 because I honestly don't trust NRS to make good online. If they say they worked on the netcode for injustice 2 that's an instant no buy. Unless I'm winning more tournaments than sonic fox. Only way I can see buying an NRS game to be a good purchase.

i think its similar in the fact that it estimates, beyond the original observation range, the value of a variable on the basis of its relationship with another variable.
Thanks. One more question, could you possibly tell me what parts of the OP pertain to GGxrd and Skullgirls based on what I've seen from using their online modes?
 

MadeOfMetal

Kenshi Srubtastic,Cyrax, Special Forces Mains
My statement meant that GGPO3 is new and is what's being used on their new 2.5d game. So it's possible no one had a chance to use it. But now I really hope they at least ask them for GGPO3 for Injustice 2 because I honestly don't trust NRS to make good online. If they say they worked on the netcode for injustice 2 that's an instant no buy. Unless I'm winning more tournaments than sonic fox. Only way I can see buying an NRS game to be a good purchase.
i say we find a way to Trace route and determine the Ping during input lag, record said results as video evidence, make a petition to implement GGOP3
 

trufenix

bye felicia
guys. ggpo is not a magic bullet. You can't just "put" rollback code in a game that's already been made. WB is apparently unwilling (or NRS is incapable) to re-design their now almost 10 year old engine to facilitate it.

We can only hope (as we did this time) that next time WB will change their mind and NRS will finally gut this bloat fish of an engine. But millions of sales and thousands of online matches are going to make that a hard sell.
 

WidowPuppy

Attack pekingese
What’s up everyone? With the first BETA for Street Fighter V fast approaching on July 23rd, we felt that this would be the perfect time to let you all know what you can expect when you log in and also answer some questions that fans have voiced as of late.

Continue on for further BETA details!

The first BETA kicks off on July 23rd (18:00 PT), July 24th (03:00 CEST/10:00 JST)) for 5 days and is exclusive to PS4 users.

The primary purpose of this BETA is to test the online net code, as this is something that Capcom is taking very seriously with Street Fighter V.

The data that we receive from this BETA will help us to improve the net code in the final product, so we thank you in advance for participating in the BETA.
 

trufenix

bye felicia
Honestly I think nrs hears us. It'd be nice to get a response, recognition at least
what exactly do you want them to say? What could they actually say that wouldn't be twisted and turned and called a lie three months from now when it turns out not everyone's dreams came true?
 

Skkra

PSN: Skkra
@trufenix is correct. They will not fix the mkx netcode. As ive mentioned several times, the netcode MUST be designed into the engine from the ground up. What we have is all we are getting.

As others have said, sans a new engine come the next NRS game, I cant imagine buying it. It'd be nice to see their engine use ggpo as so many other titles have.
 

BillStickers

Do not touch me again.
People need to understand, this game has 3D hitboxes.

Someone do a mockup JSON doc of the game state of a 2D hitboxes Fighter, then try the same with 3D hitboxes. You are going to easily end up with well over 5 times the size.
This statement is misinformed on a number of levels.
  1. A 3D point is simply an extra coordinate. [x, y] becomes [x, y, z].
  2. 3D hitboxes are vector-(i.e. mathematically) based, so in some ways they actually provide a benefit to 2d pixel data because a sphere at point [x,y,z] with radius r is much cheaper to work with than bitmap data, in which each pixel has 4 integer values associated with it (RGBA). If a given game is smart enough to use rectangles instead of pixels, even then a rectangle and a sphere have similar storage requirements.
  3. The real issue in NRS games is the use of massive amounts of engine/middleware bloat that are then ADDITIONALLY modified by NRS, creating a completely unmaintainable Franken-game where basically the ONLY requirement becomes "don't let the game run under 60 FPS," nevermind the fact that all platforms at this point should be able to maintain that without a hitch.
  4. The JSON might be 5 times that size, but pretty much everything in NRS games is based on offsets and raw hex, so the difference wouldn't be nearly as dramatic as you're suggesting. Even still, a possibility would be to simply flatten a low poly overlay as a proxy for the characters themselves and use that for collision detection.
 

WidowPuppy

Attack pekingese
This statement is misinformed on a number of levels.
  1. A 3D point is simply an extra coordinate. [x, y] becomes [x, y, z].
  2. 3D hitboxes are vector-(i.e. mathematically) based, so in some ways they actually provide a benefit to 2d pixel data because a sphere at point [x,y,z] with radius r is much cheaper to work with than bitmap data, in which each pixel has 4 integer values associated with it (RGBA). If a given game is smart enough to use rectangles instead of pixels, even then a rectangle and a sphere have similar storage requirements.
  3. The real issue in NRS games is the use of massive amounts of engine/middleware bloat that are then ADDITIONALLY modified by NRS, creating a completely unmaintainable Franken-game where basically the ONLY requirement becomes "don't let the game run under 60 FPS," nevermind the fact that all platforms at this point should be able to maintain that without a hitch.
  4. The JSON might be 5 times that size, but pretty much everything in NRS games is based on offsets and raw hex, so the difference wouldn't be nearly as dramatic as you're suggesting. Even still, a possibility would be to simply flatten a low poly overlay as a proxy for the characters themselves and use that for collision detection.
Someone who knows logic, nice.

The excuses people will try to come up with is beyond fathomable.