Author |
Message |
RexMundiAbu
Joined: Thu Jul 14, 2011 12:24 am Posts: 331
|
As someone who has never used multiple devices or tabs in pvp , npc or base combat , this will have no negative impact on how I play the game . And I also cannot see how it would be a bad thing - the game can be played very easily using just the one screen ( as I have for nearly 4 years ) lets get this issue fixed and move on to other stuff .
_________________
|
Thu Feb 27, 2014 7:34 pm |
|
|
ICBLF
Joined: Sat Jul 02, 2011 6:52 pm Posts: 1663 Location: where the dead ships dwell
|
RexMundiAbu wrote: As someone who has never used multiple devices or tabs in pvp , npc or base combat , this will have no negative impact on how I play the game . And I also cannot see how it would be a bad thing - the game can be played very easily using just the one screen ( as I have for nearly 4 years ) lets get this issue fixed and move on to other stuff . It's a coding change that involves increasing the complexity of both the client and server code on an application where there are already common reports of glitches and laaaaag. When you say it "will have no negative impact on how [you] play" and how you "cannot see how it would be a bad thing", are you factoring in how likely it is for new code (that greatly increases the complexity of every communication) to cause more glitches and greater lag?
_________________
|
Thu Feb 27, 2014 9:53 pm |
|
|
umbongo
Joined: Sun Jan 13, 2013 8:04 pm Posts: 1063
|
ICBLF wrote: RexMundiAbu wrote: As someone who has never used multiple devices or tabs in pvp , npc or base combat , this will have no negative impact on how I play the game . And I also cannot see how it would be a bad thing - the game can be played very easily using just the one screen ( as I have for nearly 4 years ) lets get this issue fixed and move on to other stuff . It's a coding change that involves increasing the complexity of both the client and server code on an application where there are already common reports of glitches and laaaaag. When you say it "will have no negative impact on how [you] play" and how you "cannot see how it would be a bad thing", are you factoring in how likely it is for new code (that greatly increases the complexity of every communication) to cause more glitches and greater lag? Pretty defensive of this glitch...
_________________ UmBongo, UmBongo, they drink it in the Congo....
I did some naughty things, and now they have put me in the Royal Asylum, based in Chesterton
Alumni of the Crimson Lances and Lords of Infinity
Rank 971, Strict SSB,Possibly the jazziest ship in the universe
|
Thu Feb 27, 2014 10:05 pm |
|
|
Fireblade
Joined: Wed Nov 16, 2011 1:42 am Posts: 1148
|
umbongo wrote: ICBLF wrote: RexMundiAbu wrote: As someone who has never used multiple devices or tabs in pvp , npc or base combat , this will have no negative impact on how I play the game . And I also cannot see how it would be a bad thing - the game can be played very easily using just the one screen ( as I have for nearly 4 years ) lets get this issue fixed and move on to other stuff . It's a coding change that involves increasing the complexity of both the client and server code on an application where there are already common reports of glitches and laaaaag. When you say it "will have no negative impact on how [you] play" and how you "cannot see how it would be a bad thing", are you factoring in how likely it is for new code (that greatly increases the complexity of every communication) to cause more glitches and greater lag? Pretty defensive of this glitch... I think mostly because the majority of people who are in favour don't understand how this will effect them. For the game to realise you are using more than 1 device it will have to generate a unique code for that session and then every time you click that code will need to be sent approved by the server and then your hit will go through. I don't think there is a solution to this without increasing lag for everybody as each click will require validating before going through. If Dan can find a way to do this without making the game lag sure go right ahead and patch it tomorrow I couldn't care less, But the reality of it is a patch will require more information to be sent every click more information for the servers to process and it will slow the game down for everybody and I think that probably would do more harm then good.
_________________
|
Thu Feb 27, 2014 11:06 pm |
|
|
RexMundiAbu
Joined: Thu Jul 14, 2011 12:24 am Posts: 331
|
While I would not want any ( more ) lag , I cannot say what probless this will cause as 1. it has not happened yet , and 2. I'm pretty rubbish with computers . ( which is why I cannot see it being a bad thing - as I havnt got a clue what problems the fix may or may not cause )
All I can say is the former fluffy one had a very tuff ship , and he got it by cheating - I do not want others to do this or continue doing what he did . If no-one right now is using these exploits then I still want the temptation removed and everyone on a level playing field .
_________________
|
Fri Feb 28, 2014 1:16 am |
|
|
ICBLF
Joined: Sat Jul 02, 2011 6:52 pm Posts: 1663 Location: where the dead ships dwell
|
umbongo wrote: Pretty defensive of this glitch... Pretty desirous of discrediting me without addressing my criticisms... RexMundiAbu wrote: While I would not want any ( more ) lag , I cannot say what probless this will cause as 1. it has not happened yet , and 2. I'm pretty rubbish with computers . ( which is why I cannot see it being a bad thing - as I havnt got a clue what problems the fix may or may not cause ) Which is a fair thing to say, can't ask that everyone be a web developer and understand the implications. Thanks at least for conceding that there may be another side to this.
_________________
|
Fri Feb 28, 2014 2:10 am |
|
|
Fireblade
Joined: Wed Nov 16, 2011 1:42 am Posts: 1148
|
RexMundiAbu wrote: While I would not want any ( more ) lag , I cannot say what probless this will cause as 1. it has not happened yet , and 2. I'm pretty rubbish with computers . ( which is why I cannot see it being a bad thing - as I havnt got a clue what problems the fix may or may not cause )
All I can say is the former fluffy one had a very tuff ship , and he got it by cheating - I do not want others to do this or continue doing what he did . If no-one right now is using these exploits then I still want the temptation removed and everyone on a level playing field . Saying fluffy built his ship cheating is like saying catching bill gates stealing $20 and saying that's how he built his fortune. Fluffy didn't build his ship by cheating he built it through npcing and trading he was banned because he pointed out this design flaw and rather than Dan put his hands up and say thank you for bringing this to my attention he banned him for it. On the issue of extra lag, put very simply what ever Dan implements to stop this is going to be attentional code being sent every time you click, the more code being sent per click the longer that click will take to complete. To be honest those who wants to cheat will find a way and that is the sad fact of it. while yes some of the exploits found where game breaking (spawning duplicate artifacts etc) I'm not really sure this is that much of a problem, or maybe a better way to put it i feel the solution is most likely going to be worse than the problem it's self.
_________________
|
Fri Feb 28, 2014 2:19 am |
|
|
RexMundiAbu
Joined: Thu Jul 14, 2011 12:24 am Posts: 331
|
Well hopefully Dan could tell us if there will be issuses from him fixing this ? Then let the playerbase decide if it is worth going ahead ? I don't know the best way but would like it fixed if possible and ifpractical to do so .
Please do not make out the former fluffy one was some sort of saint , or someone harshly treated by Dan . Didnt he admit to various not very legit things that he did ? I had many interactions with him myself and imo found him to be a very dodgy player . My thoughts on him was that he played very close to or over the edge and it was just a matter of time untill he was caught .
_________________
|
Fri Feb 28, 2014 2:43 am |
|
|
PurFikshun
Joined: Sun Oct 14, 2012 6:08 pm Posts: 190
|
ICBLF wrote: RexMundiAbu wrote: As someone who has never used multiple devices or tabs in pvp , npc or base combat , this will have no negative impact on how I play the game . And I also cannot see how it would be a bad thing - the game can be played very easily using just the one screen ( as I have for nearly 4 years ) lets get this issue fixed and move on to other stuff . It's a coding change that involves increasing the complexity of both the client and server code on an application where there are already common reports of glitches and laaaaag. When you say it "will have no negative impact on how [you] play" and how you "cannot see how it would be a bad thing", are you factoring in how likely it is for new code (that greatly increases the complexity of every communication) to cause more glitches and greater lag? On the other hand, the fix doesn't necessarily have to do any of the things you suggested. In RL, I'm a long term lead programmer/database administrator at a bank. One thing I never understood about this issue (and the old multi-badging base issue, etc.) was why any transaction (hit, raid, hack) was not "atomic". It's generally known that the cure for race conditions in any parallel or multi-threaded system is to put a lock on the shared resource before you attempt a "transaction" on it. When someone goes to make a withdrawl from their account, we lock, perform the operation, unlock. We don't waste time trying to prevent you from logging into your account on two different devices -- we just make sure that any withdrawls are processed serially so that your balance is reflected properly if you make an attempt to withdraw or transfer funds from the two sessions at the same time. The overhead involved in locking/unlocking is extremely low and locking/unlocking mechanisms are easily used, pre-built functionality in any major database system (Oracle, DB2, SQL Server, etc.), most open-source relational databases, and most popular programming languages. This solution would probably fix many of the little glitches (like overhitting popular NPCs to kill them) that are caused by allowing race conditions to occur. The crux of the problem is not the multiple devices, tabs, etc., it is the race conditions the game allows. Multiple tabs, devices, etc., could not cause multiple kills, raids or hacks if only one action could happen to a ship, base or NPC at a time. This is just a suggestion for another approach. The session management approach sounds like it may introduce issues many players are leary about and it doesn't solve all the potential problems in the game (like the possibility of multiple simultaneous disables by different players). I would at least investigate the record-locking approach since it would more or less guarantee that the problem, in all it's permutations, was permanently fixed. And this would all take place on the server -- no client code changes required. Management at the session state level is also a little more risky as hackers have long known various techniques for hijacking sessions and some of this knowledge is readily accessible. So any session state management approach would have to be carefully crafted to prevent the people who are mostly likely to be abusing the system now from just figuring out yet another work around.
|
Sat Mar 01, 2014 7:34 pm |
|
|
ICBLF
Joined: Sat Jul 02, 2011 6:52 pm Posts: 1663 Location: where the dead ships dwell
|
PurFikshun wrote: On the other hand, the fix doesn't necessarily have to do any of the things you suggested. In RL, I'm a long term lead programmer/database administrator at a bank. One thing I never understood about this issue (and the old multi-badging base issue, etc.) was why any transaction (hit, raid, hack) was not "atomic". It's generally known that the cure for race conditions in any parallel or multi-threaded system is to put a lock on the shared resource before you attempt a "transaction" on it. When someone goes to make a withdrawl from their account, we lock, perform the operation, unlock. We don't waste time trying to prevent you from logging into your account on two different devices -- we just make sure that any withdrawls are processed serially so that your balance is reflected properly if you make an attempt to withdraw or transfer funds from the two sessions at the same time.
The overhead involved in locking/unlocking is extremely low and locking/unlocking mechanisms are easily used, pre-built functionality in any major database system (Oracle, DB2, SQL Server, etc.), most open-source relational databases, and most popular programming languages. This solution would probably fix many of the little glitches (like overhitting popular NPCs to kill them) that are caused by allowing race conditions to occur. The crux of the problem is not the multiple devices, tabs, etc., it is the race conditions the game allows. Multiple tabs, devices, etc., could not cause multiple kills, raids or hacks if only one action could happen to a ship, base or NPC at a time.
This is just a suggestion for another approach. The session management approach sounds like it may introduce issues many players are leary about and it doesn't solve all the potential problems in the game (like the possibility of multiple simultaneous disables by different players). I would at least investigate the record-locking approach since it would more or less guarantee that the problem, in all it's permutations, was permanently fixed. And this would all take place on the server -- no client code changes required.
Management at the session state level is also a little more risky as hackers have long known various techniques for hijacking sessions and some of this knowledge is readily accessible. So any session state management approach would have to be carefully crafted to prevent the people who are mostly likely to be abusing the system now from just figuring out yet another work around. Quote for truth. This has essentially been my (and others) point for quite some time, even prior to this latest issue and proposed "single device" solution.
_________________
|
Sun Mar 02, 2014 1:04 am |
|
|
Cendant
Joined: Sun Mar 18, 2012 4:49 pm Posts: 687
|
PurFikshun wrote: I would at least investigate the record-locking approach since it would more or less guarantee that the problem, in all it's permutations, was permanently fixed. And this would all take place on the server -- no client code changes required.
Record locking would introduce far more lag than is existing currently. Even if you could limit it to a single record lock as opposed to for example a table lock. Imagine a base battle in the system as it currently is with the race condition. So many people are hitting that the system is requesting and updating the current value of the base's shields that sometimes the transactions (from read hull to calc damage and write new hull) of different players overlap. now take all of those overlapping transactions and line them up end-to-end so they no longer overlap and imagine what it will do to the responsiveness of people clicking. Record locking is a great solution to ensure data integrity, but it can have serious implications for performance in highly transactional systems
|
Thu Mar 06, 2014 12:36 am |
|
|
Ding1
Joined: Mon Dec 19, 2011 2:30 am Posts: 60
|
I would just like to state that after reading this thread, i am definitely dumber than everyone else who posted here. I dont understand any of what you guys are saying but it sure does sound intelligent.
|
Thu Mar 06, 2014 5:29 am |
|
|
Fear
Joined: Tue Nov 23, 2010 2:41 am Posts: 1069
|
Ding1 wrote: I would just like to state that after reading this thread, i am definitely dumber than everyone else who posted here. I dont understand any of what you guys are saying but it sure does sound intelligent. that's probably the best and most honest post in the forums in a long time. I tend to agree fwiw.
_________________
|
Thu Mar 06, 2014 11:11 pm |
|
|
PLURVIOUS
Joined: Fri Jan 06, 2012 3:10 am Posts: 1653 Location: Shredding NPCs and fantasizing about natural Dysons in this beefy UFO that I built in my basement
|
Cendant wrote: PurFikshun wrote: I would at least investigate the record-locking approach since it would more or less guarantee that the problem, in all it's permutations, was permanently fixed. And this would all take place on the server -- no client code changes required.
Record locking would introduce far more lag than is existing currently. Even if you could limit it to a single record lock as opposed to for example a table lock. Imagine a base battle in the system as it currently is with the race condition. So many people are hitting that the system is requesting and updating the current value of the base's shields that sometimes the transactions (from read hull to calc damage and write new hull) of different players overlap. now take all of those overlapping transactions and line them up end-to-end so they no longer overlap and imagine what it will do to the responsiveness of people clicking. Record locking is a great solution to ensure data integrity, but it can have serious implications for performance in highly transactional systems Other sites deal with concurrent access to far more data nd orders of magnitude more users without "lag". It really does boil down to either bad coding or inadequate server (or cloud infrastructure) I don't want to get into Dan-bashing or pissing matches of who know more about database performance. All i want to say is that projects of much greater scope than Galaxy Legion happen all the time without the type of lag we see here. It can, AND IS BEING, done all over the Internet. It shouldn't be hard to get better performance AND handle data race conditions properly. All the games, merchant processors, mail relays, auction sites, etc out there have got it to work. All of them except GL. I will offer 2 pieces of "technical" advice. 1. Use AWS instead of Rackspace,. 2. You don't need to resend the entire page with each click. A few bytes indicating what changed would suffice. Ok and a 3rd, start handling data race conditions.
_________________PLURVION: Immortal GP Jedi and Loyal Distinguished Minion to Ms. T.
|
Fri Mar 07, 2014 7:13 am |
|
|
Billik
Joined: Thu Nov 24, 2011 12:40 am Posts: 2812 Location: Just go north, and keep on going.
|
Cendant wrote: PurFikshun wrote: I would at least investigate the record-locking approach since it would more or less guarantee that the problem, in all it's permutations, was permanently fixed. And this would all take place on the server -- no client code changes required.
Record locking would introduce far more lag than is existing currently. Even if you could limit it to a single record lock as opposed to for example a table lock. Imagine a base battle in the system as it currently is with the race condition. So many people are hitting that the system is requesting and updating the current value of the base's shields that sometimes the transactions (from read hull to calc damage and write new hull) of different players overlap. now take all of those overlapping transactions and line them up end-to-end so they no longer overlap and imagine what it will do to the responsiveness of people clicking. Record locking is a great solution to ensure data integrity, but it can have serious implications for performance in highly transactional systems That was the past system iirc, caused all kinds of wonky stuff when the stars aligned and all the old powers went after the dysonians. I remember it caused a big crash when some onions cranked up their clickers, and considering we're all stronger than they were back then it would definitely be prone to some bad glitches
_________________A Necromancer Design Senatus et Populusque Imminente
|
Fri Mar 07, 2014 6:31 pm |
|
|
Hallucinations
Joined: Sat Jul 14, 2012 8:35 am Posts: 1301
|
Any chance for an Update Dan?
|
Wed Apr 09, 2014 2:16 am |
|
|
ICBLF
Joined: Sat Jul 02, 2011 6:52 pm Posts: 1663 Location: where the dead ships dwell
|
Hallucinations wrote: Any chance for an Update Dan? Well, we got Lepus, some new legion missions, seems like he's working on enough stuff.
_________________
|
Wed Apr 09, 2014 1:49 pm |
|
|
Arbiter
Joined: Fri Jan 24, 2014 3:31 am Posts: 277
|
ICBLF wrote: Hallucinations wrote: Any chance for an Update Dan? Well, we got Lepus, some new legion missions, seems like he's working on enough stuff. Yeah, but this is important, he's super serial.
_________________ "I guess love's a funny thing--the way it fades away without a warning. It doesn't ask to be excused, and when it's gone--oh, it's gone--it ain't ever coming back"
|
Wed Apr 09, 2014 1:57 pm |
|
|
kirkeastment
Joined: Sun Jun 19, 2011 6:24 pm Posts: 2810 Location: UK
|
Hallucinations wrote: Any chance for an Update Dan? You should probably just quit the game if this is keeping you awake at night This "fix" ain't coming ever... Either Dan doesn't know how to implement such a solution without making things 10x worse/lagtastic(or stopping mobile access altogether) or he see's that there aren't really all that many people even fussed about it anymore.
|
Wed Apr 09, 2014 1:58 pm |
|
|
Hallucinations
Joined: Sat Jul 14, 2012 8:35 am Posts: 1301
|
kirkeastment wrote: Hallucinations wrote: Any chance for an Update Dan? You should probably just quit the game if this is keeping you awake at night This "fix" ain't coming ever... Either Dan doesn't know how to implement such a solution without making things 10x worse/lagtastic(or stopping mobile access altogether) or he see's that there aren't really all that many people even fussed about it anymore. I'm not losing sleep over it or anything. I just want to know if Dan is still at least working on it - If so I might think about spending more money on GL. As it stands I only play GL to help the Infinity community, I'm currently semi-retired. My only goals are to help Infinity the best I can. Maybe I will focus on my own ship when this issue is fixed. For those of who don't understand my concern... Fine ill make what I was told public. Please note I can not confirm these allegations are true but if they are... well its game breaking. I was told the following by a player after finding out what Wolfy was up doing decided to test things out for himself before he quit. - He quit the game after finding out the state of this game. He told me that using the multi device glitch you can; - Get TWO badges for every ONE time manipulator you use. - Add TWO planet artifacts for every ONE you have. - Add TWO base artifacts for every ONE you have. - Harvest double the production points you could normally pull. I don't know if any of this is true, and I don't intent to find out myself. But if it is... Well you can understand my concern. Now you guys may finally understand why I feel this is a serious issue.
|
Wed Apr 09, 2014 10:37 pm |
|
|
|
Who is online |
Users browsing this forum: No registered users and 22 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum
|
|