Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

An actual update!!!

Slapshot1188Slapshot1188 Member LegendaryPosts: 17,695

 

 

 


Old Today, 12:24

  #1 (permalink)


Henrik Nystrom vbmenu_register("postmenu_871662", true);


Administrator


 

Henrik Nystrom's Avatar


 


Join Date: Apr 2008




Rep Power: 24 Henrik Nystrom has much to be proud ofHenrik Nystrom has much to be proud ofHenrik Nystrom has much to be proud ofHenrik Nystrom has much to be proud ofHenrik Nystrom has much to be proud ofHenrik Nystrom has much to be proud ofHenrik Nystrom has much to be proud ofHenrik Nystrom has much to be proud of


 




post A short update 2010-05-26




We have been doing extensive in house testing with a QA team to get our release features a lot more stable before we patch them to the live test server.



We are working on our patching system to make the distribution a lot easier which we also will go live with very soon.



We are planning to go live with the next patch tomorrow or on this Friday; you will then be able to access most features except housing, guilds and thievery. New feedback on weapon & armor damage/durability/stam/speed balance is most welcome.





A small clarification on the desync issue we had before that’s still confusing a few people on the forums.

As I described before the desync issue we had before was because we lacked the proper software in our old network structure to track packages send from server to clients, hence creating desync for random players it was not a game feature causing it but the network structure lacked the proper tracking software. With the tracking software in place this cannot happen anymore. The game features have been gradually turned on, stress testing the server.


__________________

CEO, Founder & Game designer


Henrik Nystrom is offline Add to Henrik Nystrom's Reputation vbrep_register("871662")Report Post

Reply With Quote Multi-Quote This Message Quick reply to this message

 

June 9th is coming...  tick.. tock...tick.. tock...

 

All time classic  MY NEW FAVORITE POST!  (Keep laying those bricks)

"I should point out that no other company has shipped out a beta on a disc before this." - Official Mortal Online Lead Community Moderator

Proudly wearing the Harbinger badge since Dec 23, 2017. 

Coined the phrase "Role-Playing a Development Team" January 2018

"Oddly Slap is the main reason I stay in these forums." - Mystichaze April 9th 2018

«1

Comments

  • HerculesSASHerculesSAS Member Posts: 1,272

    It's a laughable statement, almost entirely. The "tracking software" is a joke -- the system Unreal/Atlas uses employs UDP packets -- meaning you CAN'T TRACK THEM. TCP has a wrapper around it that actually signals for a "connection", and will send back a success. In online gaming, you can't wait for every TCP packet and as such, they use UDP for speed.

     

    How do you track a packet that can't be tracked?

     

    This is getting so ridiculously funny due to the insane amount of lies Henrik tells, I really don't even know whether to laugh or cry. Maybe I'll laugh so hard, I'll cry.

  • YamotaYamota Member UncommonPosts: 6,593

    Yeah I am starting to belive that indy devs are nothing but con artists. Several videos has been posted on youtube showing that the desync issue is still there so that is clearly a lie that it is "fixed".

  • HerculesSASHerculesSAS Member Posts: 1,272

    Originally posted by Yamota

    Yeah I am starting to belive that indy devs are nothing but con artists. Several videos has been posted on youtube showing that the desync issue is still there so that is clearly a lie that it is "fixed".

    At this point that's a lie worth telling -- because it looks like they *have* to launch now, and coupling them with the ripoff they are trying to pull with the auto-subscriptions for the pre-orders, and now saying they can "track" UDP packets (rofl) it's been one entire huge mountain of lies after another.

     

    I am amazed that they have made it this far, but it won't last a lot longer. In hindsight though, I have to give Aventurine a lot of credit because their game works and they actually managed to complete the vast majority of it. It was wholly playable during beta and if you got in after launch. SV's got zero features turned on two weeks to launch, and they will be enabling EVERYTHING (except housing, thieving, and guilds -- you know, the BIG features) a week prior to launch.

     

    I am even more amazed at the folks who continue to support them, despite demonstrable lies and unethical behavior. And after MO goes belly up, I would love for those folks to come forward and explain how they got duped.

  • ThorpeyroxThorpeyrox Member Posts: 125

    Well after they had 'fixed' the desync (supposingly) I could fight four other people at the same time and none of us would experience desync at all therefore I can conclude I have no desync. If you're getting 'desync' it's probably your computer and it's probably lag.

    You have to remember the desync wasn't fixed immediately with the patch which is probably why you're confused.

  • Slapshot1188Slapshot1188 Member LegendaryPosts: 17,695

    Originally posted by Thorpeyrox

    Well after they had 'fixed' the desync (supposingly) I could fight four other people at the same time and none of us would experience desync at all therefore I can conclude I have no desync. If you're getting 'desync' it's probably your computer and it's probably lag.

    You have to remember the desync wasn't fixed immediately with the patch which is probably why you're confused.

     5 people were actually on the screen at the same time without desync !?!?!? 

     

    Sorry.. this is supposed to be a Massively multiplayer game.  I don't think 5 people on screen is really proof of anything.  Don't worry though.. we are under 2 weeks form launch now.  All will be clear shortly.  One way or another.

    All time classic  MY NEW FAVORITE POST!  (Keep laying those bricks)

    "I should point out that no other company has shipped out a beta on a disc before this." - Official Mortal Online Lead Community Moderator

    Proudly wearing the Harbinger badge since Dec 23, 2017. 

    Coined the phrase "Role-Playing a Development Team" January 2018

    "Oddly Slap is the main reason I stay in these forums." - Mystichaze April 9th 2018

  • ThorpeyroxThorpeyrox Member Posts: 125

    Originally posted by Slapshot1188

    Originally posted by Thorpeyrox

    Well after they had 'fixed' the desync (supposingly) I could fight four other people at the same time and none of us would experience desync at all therefore I can conclude I have no desync. If you're getting 'desync' it's probably your computer and it's probably lag.

    You have to remember the desync wasn't fixed immediately with the patch which is probably why you're confused.

     5 people were actually on the screen at the same time without desync !?!?!? 

     

    Sorry.. this is supposed to be a Massively multiplayer game.  I don't think 5 people on screen is really proof of anything.  Don't worry though.. we are under 2 weeks form launch now.  All will be clear shortly.  One way or another.

    2 people fighting or 12 people fighting before and chances were there would be atleast some desync, I don't think it matters to how many people are on the screen for desync. Surely only lag is affected by the number of people there and desync will always be there due to some form of packet loss? I'm no expert but that sounds like common sense to me.

  • HerculesSASHerculesSAS Member Posts: 1,272

    Originally posted by Thorpeyrox

    Originally posted by Slapshot1188


    Originally posted by Thorpeyrox

    Well after they had 'fixed' the desync (supposingly) I could fight four other people at the same time and none of us would experience desync at all therefore I can conclude I have no desync. If you're getting 'desync' it's probably your computer and it's probably lag.

    You have to remember the desync wasn't fixed immediately with the patch which is probably why you're confused.

     5 people were actually on the screen at the same time without desync !?!?!? 

     

    Sorry.. this is supposed to be a Massively multiplayer game.  I don't think 5 people on screen is really proof of anything.  Don't worry though.. we are under 2 weeks form launch now.  All will be clear shortly.  One way or another.

    2 people fighting or 12 people fighting before and chances were there would be atleast some desync, I don't think it matters to how many people are on the screen for desync. Surely only lag is affected by the number of people there and desync will always be there due to some form of packet loss? I'm no expert but that sounds like common sense to me.

    Of course it matters how many people are on screen. Every single thing another player does has to be transmitted to YOUR client. So the more people you see, the more data you have to receive. If there are 10 hitboxes per character or whatever, they have to transmit that TOO.

     

    Again -- the point I've made repeatedly is that this isn't a problem necessarily with the engine, but in the design of the game itself. If you have experience in this arena (and I don't, but I can come up with some stuff through related experience), then you can figure some stuff out at the forefront before you go out and design the game. They started out with the premise of having their lead programmer be an Unreal modder -- and his experience there is even limited. And from that, they tried to make a game that encompasses heavy packet transfer, complex systems, complex combat, and at this point, have clearly failed on every front. The game is basically unplayable with the desync that *still* exists, people on the board are ALL calling for ANOTHER delay, and the CEO lies continually to unwitting or unknowning customers about the status of the project and to top it all off -- is trying to steal money unbeknownst to the pre-order customers.

     

    This is the first time I've said it -- but this game is fully, and totally, a sham.

  • ThorpeyroxThorpeyrox Member Posts: 125

    Now to back up your empty claims;

    1.) Show me absolute proof the desync is still there

    2.) Show me proof that the board members are wanting another delay

  • GrayGhost79GrayGhost79 Member UncommonPosts: 4,775

    Originally posted by Thorpeyrox

    Now to back up your empty claims;

    1.) Show me absolute proof the desync is still there

    2.) Show me proof that the board members are wanting another delay

     He is talking about those on the forums and you can see those wanting a delay by simply visiting the boards. Go look now I was just reading a random thread that was talking about another delay and many hoping for and expecting one since many systems/mechanics will be turned back on a week prior to launch meaning not much time to test and even see if everythings fixed as SV claims.

     

    As far as the desync issue's no idea, recent video I saw that was posted on the 10th looked as if there were still desync issues but considering I'm not playing I couldn't tell you for certain.

  • CoolaidCoolaid Member UncommonPosts: 70

    I'm thinking positive, might as well they already have my money.  If not I can go back to Darkfall.  No big deal its only 40 bucks. 

  • HerculesSASHerculesSAS Member Posts: 1,272

    Originally posted by Thorpeyrox

    Now to back up your empty claims;

    1.) Show me absolute proof the desync is still there

    2.) Show me proof that the board members are wanting another delay

    As for number one, I shouldn't have to prove to you the existence of something that developers say is gone. They should prove it to us. And they have not yet, given the sheer number of complaints in the forums, and the features are entirely turned off. Not to mention -- nobody's playing the game.

     

    As for number two.... By "board" members I meant forum members. And that's easily observable if you just visit the forums and read people's responses to their launch date.

  • merieke82merieke82 Member Posts: 165

    Not that desync hasn't been thoroughly discussed, let me take another stab at clarifying it and why different people are getting different results.

     

    Some people hear the word desync and think rocket pigs, others think of abilities not firing, or your weapon being sheathed but still being in combat mode, or a variety of other things. I consider the items I mentioned to be part of the "desync" issue and they are theoretically caused by packets being lost or ignored on the server. The client itself is of course part of the equation but the client doesn't cause the desync ... the client will stay up to date with whatever the server sends it ... so long as it comes back in a timely fashion.

     

    Desync becomes increasingly more common the higher your lag is because it gives the player a larger window to send more inputs and have them get ignored. When an invalid or no response is received the client still goes about its business assuming that the action was successful. Subsequent actions that require server side authentication then become hosed because the server sees you differently than your client does. During my beta testing I could actually force desync to be caused or avoid it entirely by simply watching the inputs I sent ... and if I did not get feedback from a given input if I simply waited for the server to respond (even if it took 2 minutes) then I could avoid desync.

     

    That being said, I believe the primary cause of the desync issue is server side packet management which should now be improved with the use of the new networking tools. I don't claim that SV has fixed it because I don't have closed beta access, but it makes sense to me that as they are working on the issue that unexpected results are still occurring client side.

     

    At 10:00 Joe A may have had no desync problems but at 12:00 the same day Joe B may have seen some. I don't think the packet management is largely based on client side patches, features, or the number of players on your screen (that actually gave me a good chuckle). I think this explains the mixed results that everyone is reporting. What the player is doing, or how many players are around is not significantly impacting whether the desync occurs.

     

    Desync has been around a long time and I'm not going to the play the game of saying whether its really fixed or will be fixed. This is what desync is, at least from the perspective of programmer who has absolutely no MO source code to back up his claims.

     

    In my humble opinion if I was programming this code and we were this close to launch I would start thinking about coding a forcePlayerSync() function that runs every 30 seconds to fix anyone who has gotten out of sync. It would be a jarring experience to the player if/when it occurred but would be a tolerable,temporary bandaid if the root of the desync issue still exists.

  • randomtrandomt Member UncommonPosts: 1,220

    Coming from a networking background, I can pretty safely say that this statement does not inspire any kind of confidence in the viability of their software.

    Tracking software, or lack of it, has no effect on network sync, or rather, having to track each packet would add overheard and would make the problem worse.

    Perhaps the meaning of his statement was lost in translation though, being that they are swedish and all that..

  • HerculesSASHerculesSAS Member Posts: 1,272

    Originally posted by randomt

    Coming from a networking background, I can pretty safely say that this statement does not inspire any kind of confidence in the viability of their software.

    Tracking software, or lack of it, has no effect on network sync, or rather, having to track each packet would add overheard and would make the problem worse.

    Perhaps the meaning of his statement was lost in translation though, being that they are swedish and all that..

     

    That's why I mentioned the UDP/TCP point earlier -- TCP is configured to be "tracked" by the packet form itself, and UDP is not. And since Unreal3/Atlas uses UDP (as most games do), I have to laugh at the notion they are tracking packets specifically designed *not* to be tracked.

  • HerculesSASHerculesSAS Member Posts: 1,272

    Originally posted by merieke82

    Not that desync hasn't been thoroughly discussed, let me take another stab at clarifying it and why different people are getting different results.

     

    Some people hear the word desync and think rocket pigs, others think of abilities not firing, or your weapon being sheathed but still being in combat mode, or a variety of other things. I consider the items I mentioned to be part of the "desync" issue and they are theoretically caused by packets being lost or ignored on the server. The client itself is of course part of the equation but the client doesn't cause the desync ... the client will stay up to date with whatever the server sends it ... so long as it comes back in a timely fashion.

     

    Desync becomes increasingly more common the higher your lag is because it gives the player a larger window to send more inputs and have them get ignored. When an invalid or no response is received the client still goes about its business assuming that the action was successful. Subsequent actions that require server side authentication then become hosed because the server sees you differently than your client does. During my beta testing I could actually force desync to be caused or avoid it entirely by simply watching the inputs I sent ... and if I did not get feedback from a given input if I simply waited for the server to respond (even if it took 2 minutes) then I could avoid desync.

     

    That being said, I believe the primary cause of the desync issue is server side packet management which should now be improved with the use of the new networking tools. I don't claim that SV has fixed it because I don't have closed beta access, but it makes sense to me that as they are working on the issue that unexpected results are still occurring client side.

     

    At 10:00 Joe A may have had no desync problems but at 12:00 the same day Joe B may have seen some. I don't think the packet management is largely based on client side patches, features, or the number of players on your screen (that actually gave me a good chuckle). I think this explains the mixed results that everyone is reporting. What the player is doing, or how many players are around is not significantly impacting whether the desync occurs.

     

    Desync has been around a long time and I'm not going to the play the game of saying whether its really fixed or will be fixed. This is what desync is, at least from the perspective of programmer who has absolutely no MO source code to back up his claims.

     

    In my humble opinion if I was programming this code and we were this close to launch I would start thinking about coding a forcePlayerSync() function that runs every 30 seconds to fix anyone who has gotten out of sync. It would be a jarring experience to the player if/when it occurred but would be a tolerable,temporary bandaid if the root of the desync issue still exists.

    Understand this much -- StarVault is not doing the network coding. They have shown they *barely* have the ability to make your character move properly, and to calculate hits, and now the idea of them coding network packets? LOL

     

    They don't have to worry about the network solution because they bought the whole thing from Epic Games -- and as a result of their poor understanding of network packets and traffic, they have shown thus far, they have no ability to troubleshoot their problems and instead, "upgrade to the newest version". My personal guess is that they upgraded to try to get rid of their problems, and it didn't work (quite apparently from what the forums say). Upgrading a badly designed product does not make your product better designed. It's still a poor design at its core, and since they don't have the knowledge to shape and design the product properly, they are shipping you the newest version of what is basically a crappy project.

  • jokerthag2jokerthag2 Member Posts: 37

    im just waiting.. dont see why you guys are on such a crusade. dont know why you cant believe it wasnt the feature but it wasnt

  • merieke82merieke82 Member Posts: 165

    Originally posted by HerculesSAS

    Originally posted by merieke82

    Not that desync hasn't been thoroughly discussed, let me take another stab at clarifying it and why different people are getting different results.

     

    Some people hear the word desync and think rocket pigs, others think of abilities not firing, or your weapon being sheathed but still being in combat mode, or a variety of other things. I consider the items I mentioned to be part of the "desync" issue and they are theoretically caused by packets being lost or ignored on the server. The client itself is of course part of the equation but the client doesn't cause the desync ... the client will stay up to date with whatever the server sends it ... so long as it comes back in a timely fashion.

     

    Desync becomes increasingly more common the higher your lag is because it gives the player a larger window to send more inputs and have them get ignored. When an invalid or no response is received the client still goes about its business assuming that the action was successful. Subsequent actions that require server side authentication then become hosed because the server sees you differently than your client does. During my beta testing I could actually force desync to be caused or avoid it entirely by simply watching the inputs I sent ... and if I did not get feedback from a given input if I simply waited for the server to respond (even if it took 2 minutes) then I could avoid desync.

     

    That being said, I believe the primary cause of the desync issue is server side packet management which should now be improved with the use of the new networking tools. I don't claim that SV has fixed it because I don't have closed beta access, but it makes sense to me that as they are working on the issue that unexpected results are still occurring client side.

     

    At 10:00 Joe A may have had no desync problems but at 12:00 the same day Joe B may have seen some. I don't think the packet management is largely based on client side patches, features, or the number of players on your screen (that actually gave me a good chuckle). I think this explains the mixed results that everyone is reporting. What the player is doing, or how many players are around is not significantly impacting whether the desync occurs.

     

    Desync has been around a long time and I'm not going to the play the game of saying whether its really fixed or will be fixed. This is what desync is, at least from the perspective of programmer who has absolutely no MO source code to back up his claims.

     

    In my humble opinion if I was programming this code and we were this close to launch I would start thinking about coding a forcePlayerSync() function that runs every 30 seconds to fix anyone who has gotten out of sync. It would be a jarring experience to the player if/when it occurred but would be a tolerable,temporary bandaid if the root of the desync issue still exists.

    Understand this much -- StarVault is not doing the network coding. They have shown they *barely* have the ability to make your character move properly, and to calculate hits, and now the idea of them coding network packets? LOL

     

    They don't have to worry about the network solution because they bought the whole thing from Epic Games -- and as a result of their poor understanding of network packets and traffic, they have shown thus far, they have no ability to troubleshoot their problems and instead, "upgrade to the newest version". My personal guess is that they upgraded to try to get rid of their problems, and it didn't work (quite apparently from what the forums say). Upgrading a badly designed product does not make your product better designed. It's still a poor design at its core, and since they don't have the knowledge to shape and design the product properly, they are shipping you the newest version of what is basically a crappy project.

     

    I am aware that SV has licensed the Unreal+Atlas engine/networking system. Even though this is the case there is still networking code that falls within the scope of SV programming. The atlas API would provide functions that send and receive data but SV would wrap these functions around their own code like swinging your sword.

     

    if (Left Mouse Button) {

      Begin Swing Animation

      AtlasFunctionSendSwordSwing()

      AtlasFunctionReceiveSwordHit()

    }

    if (SwordHit) update mob health, enable left mouse button again

     

    That's not really even close to what actually happens but you need to envision how SV code and Atlas code is interacting. The solution isn't all Atlas and it's not all SV.

     

    The purpose of "upgrading versions" wasn't because they thought the new version of Atlas would solve their problems. It was because the new version had better tools for troubleshooting networking issues. They upgraded the Unreal engine as well because it was a requirement to take the new version of Atlas. In my example the tools would better help them collect data (ie. packets) regarding what happens when that player swings his sword. Does the packet get sent from the client at the right time? Does the server read it and send a response? Does the client do what it's supposed to when it gets a response? Just because packets are flying around per Atlas doesn't mean everything should just work.

     

    Again, I'm not defending the ability of SV to program or the product they are providing. I just want to clear the air for people who read the forums and want to understand what is really going on.

     

    Upgrading to a new version of Unreal+Atlas was a perfectly sound, intelligent decision. It certainly doesn't mean that they will fix anything as a result of it though.

  • jokerthag2jokerthag2 Member Posts: 37

    Originally posted by HerculesSAS

    Originally posted by randomt

    Coming from a networking background, I can pretty safely say that this statement does not inspire any kind of confidence in the viability of their software.

    Tracking software, or lack of it, has no effect on network sync, or rather, having to track each packet would add overheard and would make the problem worse.

    Perhaps the meaning of his statement was lost in translation though, being that they are swedish and all that..

     

    That's why I mentioned the UDP/TCP point earlier -- TCP is configured to be "tracked" by the packet form itself, and UDP is not. And since Unreal3/Atlas uses UDP (as most games do), I have to laugh at the notion they are tracking packets specifically designed *not* to be tracked.

     funny thing is the udk supports tcp and udp so your lil notion just went out the window.

    here ill paste this

    Nov 9, 2009 ... Unreal Engine 3, Now Free for Non-Commercial Use: Go 3D Eye Candy! .... UDK supports UDP and TCP network communication

  • jokerthag2jokerthag2 Member Posts: 37

    Originally posted by merieke82

    Originally posted by HerculesSAS

    Originally posted by merieke82

    Not that desync hasn't been thoroughly discussed, let me take another stab at clarifying it and why different people are getting different results.

     

    Some people hear the word desync and think rocket pigs, others think of abilities not firing, or your weapon being sheathed but still being in combat mode, or a variety of other things. I consider the items I mentioned to be part of the "desync" issue and they are theoretically caused by packets being lost or ignored on the server. The client itself is of course part of the equation but the client doesn't cause the desync ... the client will stay up to date with whatever the server sends it ... so long as it comes back in a timely fashion.

     

    Desync becomes increasingly more common the higher your lag is because it gives the player a larger window to send more inputs and have them get ignored. When an invalid or no response is received the client still goes about its business assuming that the action was successful. Subsequent actions that require server side authentication then become hosed because the server sees you differently than your client does. During my beta testing I could actually force desync to be caused or avoid it entirely by simply watching the inputs I sent ... and if I did not get feedback from a given input if I simply waited for the server to respond (even if it took 2 minutes) then I could avoid desync.

     

    That being said, I believe the primary cause of the desync issue is server side packet management which should now be improved with the use of the new networking tools. I don't claim that SV has fixed it because I don't have closed beta access, but it makes sense to me that as they are working on the issue that unexpected results are still occurring client side.

     

    At 10:00 Joe A may have had no desync problems but at 12:00 the same day Joe B may have seen some. I don't think the packet management is largely based on client side patches, features, or the number of players on your screen (that actually gave me a good chuckle). I think this explains the mixed results that everyone is reporting. What the player is doing, or how many players are around is not significantly impacting whether the desync occurs.

     

    Desync has been around a long time and I'm not going to the play the game of saying whether its really fixed or will be fixed. This is what desync is, at least from the perspective of programmer who has absolutely no MO source code to back up his claims.

     

    In my humble opinion if I was programming this code and we were this close to launch I would start thinking about coding a forcePlayerSync() function that runs every 30 seconds to fix anyone who has gotten out of sync. It would be a jarring experience to the player if/when it occurred but would be a tolerable,temporary bandaid if the root of the desync issue still exists.

    Understand this much -- StarVault is not doing the network coding. They have shown they *barely* have the ability to make your character move properly, and to calculate hits, and now the idea of them coding network packets? LOL

     

    They don't have to worry about the network solution because they bought the whole thing from Epic Games -- and as a result of their poor understanding of network packets and traffic, they have shown thus far, they have no ability to troubleshoot their problems and instead, "upgrade to the newest version". My personal guess is that they upgraded to try to get rid of their problems, and it didn't work (quite apparently from what the forums say). Upgrading a badly designed product does not make your product better designed. It's still a poor design at its core, and since they don't have the knowledge to shape and design the product properly, they are shipping you the newest version of what is basically a crappy project.

     

    I am aware that SV has licensed the Unreal+Atlas engine/networking system. Even though this is the case there is still networking code that falls within the scope of SV programming. The atlas API would provide functions that send and receive data but SV would wrap these functions around their own code like swinging your sword.

     

    if (Left Mouse Button) {

      Begin Swing Animation

      AtlasFunctionSendSwordSwing()

      AtlasFunctionReceiveSwordHit()

    }

    if (SwordHit) update mob health, enable left mouse button again

     

    That's not really even close to what actually happens but you need to envision how SV code and Atlas code is interacting. The solution isn't all Atlas and it's not all SV.

     

    The purpose of "upgrading versions" wasn't because they thought the new version of Atlas would solve their problems. It was because the new version had better tools for troubleshooting networking issues. They upgraded the Unreal engine as well because it was a requirement to take the new version of Atlas. In my example the tools would better help them collect data (ie. packets) regarding what happens when that player swings his sword. Does the packet get sent from the client at the right time? Does the server read it and send a response? Does the client do what it's supposed to when it gets a response? Just because packets are flying around per Atlas doesn't mean everything should just work.

     

    Again, I'm not defending the ability of SV to program or the product they are providing. I just want to clear the air for people who read the forums and want to understand what is really going on.

     

    Upgrading to a new version of Unreal+Atlas was a perfectly sound, intelligent decision. It certainly doesn't mean that they will fix anything as a result of it though.

     good thing epic is helping them isnt it

  • merieke82merieke82 Member Posts: 165

    Originally posted by jokerthag2

    Originally posted by HerculesSAS


    Originally posted by randomt

    Coming from a networking background, I can pretty safely say that this statement does not inspire any kind of confidence in the viability of their software.

    Tracking software, or lack of it, has no effect on network sync, or rather, having to track each packet would add overheard and would make the problem worse.

    Perhaps the meaning of his statement was lost in translation though, being that they are swedish and all that..

     

    That's why I mentioned the UDP/TCP point earlier -- TCP is configured to be "tracked" by the packet form itself, and UDP is not. And since Unreal3/Atlas uses UDP (as most games do), I have to laugh at the notion they are tracking packets specifically designed *not* to be tracked.

     funny thing is the udk supports tcp and udp so your lil notion just went out the window.

    here ill paste this

    Nov 9, 2009 ... Unreal Engine 3, Now Free for Non-Commercial Use: Go 3D Eye Candy! .... UDK supports UDP and TCP network communication

     

    I think the confusion is that tracking doesn't mean tracking down where the user lives who sent the packet. It means monitoring what happens when the server receives a packet and what the server does with that data. It doesn't matter what protocol you're using. If data is sent to a server you can insert debugging steps and breakpoints within your code to monitor the life of that packet within your server.

     

    Honestly though, I would guess that the issue comes up after the packets are received and converted to internal system variables. I doubt they actually need to track the packets themselves.

  • AllSeeingGuyAllSeeingGuy Member Posts: 143

    Everyone here is making claims based on information they think they seen. Unless you actually experienced it yourself then I call BS on the desync still being around. I have been in game and I am still in game if I wish to log in. The desync is fixed from what I see on my end. The threads that are "all over" the forums about how desync isn't fixed is nothing but a stretched imagination by someone angry towards MO. There isn't any. Soon enough MO will be updating the forums to only allow subscribers to read them which is a great thing IMO. It keeps the trash away and others from trying to predict the failure of a game that clearly is making progress.

    A new update is on the way and the ones who actually own the game can test it out. If you don't own it or have access to it then your opinion pretty much expired when they closed the doors.

    If you want to bash a game going down in flames I suggest the Xsyon forums. There isn't an easier target.

  • jokerthag2jokerthag2 Member Posts: 37

    Originally posted by AllSeeingGuy

    Everyone here is making claims based on information they think they seen. Unless you actually experienced it yourself then I call BS on the desync still being around. I have been in game and I am still in game if I wish to log in. The desync is fixed from what I see on my end. The threads that are "all over" the forums about how desync isn't fixed is nothing but a stretched imagination by someone angry towards MO. There isn't any. Soon enough MO will be updating the forums to only allow subscribers to read them which is a great thing IMO. It keeps the trash away and others from trying to predict the failure of a game that clearly is making progress.

    A new update is on the way and the ones who actually own the game can test it out. If you don't own it or have access to it then your opinion pretty much expired when they closed the doors.

    If you want to bash a game going down in flames I suggest the Xsyon forums. There isn't an easier target.

     chill with the xsyon stuff. xsyon dev arleady said they will stay in beta or what ever he wants to call it lol) as long as it takes. dont see how thats going down in flames

  • HanoverZHanoverZ Member Posts: 1,239

    Originally posted by AllSeeingGuy

     Soon enough MO will be updating the forums to only allow subscribers to read them which is a great thing IMO. It keeps the trash away and others from trying to predict the failure of a game that clearly is making progress.

     

    Geeee.... They arent trying to hide anything. image   I can understand restricting posting, but to hide them?

    I win!!! LOL@U

  • EmperorBeldEmperorBeld Member Posts: 101

    Originally posted by HanoverZ

    Originally posted by AllSeeingGuy

     Soon enough MO will be updating the forums to only allow subscribers to read them which is a great thing IMO. It keeps the trash away and others from trying to predict the failure of a game that clearly is making progress.

     

    Geeee.... They arent trying to hide anything. image   I can understand restricting posting, but to hide them?

    If they were trying to hide anything.  Then, why have an open beta and open forums in the first place?imageimageimage

  • TorgrimTorgrim Member CommonPosts: 2,088

    Internet crusader is the coolest thing you can be image

    If it's not broken, you are not innovating.

Sign In or Register to comment.