View unanswered posts | View active topics It is currently Thu Mar 28, 2024 8:46 pm



Reply to topic  [ 96 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
 Design Error 
Author Message

Joined: Thu Jul 14, 2011 12:24 am
Posts: 331
Reply with quote
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 .

_________________
Image


Thu Feb 27, 2014 7:34 pm
Profile
User avatar

Joined: Sat Jul 02, 2011 6:52 pm
Posts: 1663
Location: where the dead ships dwell
Reply with quote
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?

_________________
ImageImage


Thu Feb 27, 2014 9:53 pm
Profile
User avatar

Joined: Sun Jan 13, 2013 8:04 pm
Posts: 1063
Reply with quote
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... :roll:

_________________
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
Profile
User avatar

Joined: Wed Nov 16, 2011 1:42 am
Posts: 1148
Reply with quote
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... :roll:


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.

_________________
Image
Image


Thu Feb 27, 2014 11:06 pm
Profile

Joined: Thu Jul 14, 2011 12:24 am
Posts: 331
Reply with quote
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 .

_________________
Image


Fri Feb 28, 2014 1:16 am
Profile
User avatar

Joined: Sat Jul 02, 2011 6:52 pm
Posts: 1663
Location: where the dead ships dwell
Reply with quote
umbongo wrote:
Pretty defensive of this glitch... :roll:

Pretty desirous of discrediting me without addressing my criticisms... :roll:

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.

_________________
ImageImage


Fri Feb 28, 2014 2:10 am
Profile
User avatar

Joined: Wed Nov 16, 2011 1:42 am
Posts: 1148
Reply with quote
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.

_________________
Image
Image


Fri Feb 28, 2014 2:19 am
Profile

Joined: Thu Jul 14, 2011 12:24 am
Posts: 331
Reply with quote
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 .

_________________
Image


Fri Feb 28, 2014 2:43 am
Profile

Joined: Sun Oct 14, 2012 6:08 pm
Posts: 190
Reply with quote
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
Profile
User avatar

Joined: Sat Jul 02, 2011 6:52 pm
Posts: 1663
Location: where the dead ships dwell
Reply with quote
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.

_________________
ImageImage


Sun Mar 02, 2014 1:04 am
Profile

Joined: Sun Mar 18, 2012 4:49 pm
Posts: 687
Reply with quote
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

_________________
https://www.facebook.com/cen.dant.9


Thu Mar 06, 2014 12:36 am
Profile WWW

Joined: Mon Dec 19, 2011 2:30 am
Posts: 60
Reply with quote
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.

:mrgreen:


Thu Mar 06, 2014 5:29 am
Profile

Joined: Tue Nov 23, 2010 2:41 am
Posts: 1069
Reply with quote
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.

:mrgreen:

that's probably the best and most honest post in the forums in a long time.

I tend to agree fwiw.

_________________
Image


Thu Mar 06, 2014 11:11 pm
Profile

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
Reply with quote
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.
ImageImage


Fri Mar 07, 2014 7:13 am
Profile
User avatar

Joined: Thu Nov 24, 2011 12:40 am
Posts: 2812
Location: Just go north, and keep on going.
Reply with quote
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

_________________
Image
Image
A Necromancer Design


Senatus et Populusque Imminente


Fri Mar 07, 2014 6:31 pm
Profile
User avatar

Joined: Sat Jul 14, 2012 8:35 am
Posts: 1301
Reply with quote
Any chance for an Update Dan?


Wed Apr 09, 2014 2:16 am
Profile
User avatar

Joined: Sat Jul 02, 2011 6:52 pm
Posts: 1663
Location: where the dead ships dwell
Reply with quote
Hallucinations wrote:
Any chance for an Update Dan?

Well, we got Lepus, some new legion missions, seems like he's working on enough stuff.

_________________
ImageImage


Wed Apr 09, 2014 1:49 pm
Profile

Joined: Fri Jan 24, 2014 3:31 am
Posts: 277
Reply with quote
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
Profile

Joined: Sun Jun 19, 2011 6:24 pm
Posts: 2810
Location: UK
Reply with quote
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
Profile
User avatar

Joined: Sat Jul 14, 2012 8:35 am
Posts: 1301
Reply with quote
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
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 96 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

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

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.