Oh certainly it is. I don't have a great depth of crew, so I pick and choose. Yes, it takes a bit of time the first time around, but once I've done it I don't have to do it again. I just run the same shuttles. Over and over and over. In fact, it's the only real strategy available.
And I haven't attained a top 1000 rank in a Faction yet. However, 1500 and above several times which is my aim. If I don't look like I'm going to hit that (and I pretty much know by the end of the first day) I can relax and just send shuttles til I reach threshold.
Oh certainly it is. I don't have a great depth of crew, so I pick and choose. Yes, it takes a bit of time the first time around, but once I've done it I don't have to do it again. I just run the same shuttles. Over and over and over. In fact, it's the only real strategy available.
And I haven't attained a top 1000 rank in a Faction yet. However, 1500 and above several times which is my aim. If I don't look like I'm going to hit that (and I pretty much know by the end of the first day) I can relax and just send shuttles til I reach threshold.
That's definitely a good strategy for you then. Keep building up your crew and your performance will constantly improve until you get consistent top 1500 and top 1000 finishes.
Over 16 months as F2P, I've built up 240+ immortals and I can tell that the bonus 4*s are what will make the difference. Spending on 5*s probably helps as well, but those 'useless' 4*s like Commando Shran that you vaulted 6 months ago will eventually be very important at some point.
The reason why there is a significant (unnecessary) server load is because the algorithm for choosing missions is poor.
Currently, when there is an attempt to open a mission, the server first checks to see if all missions have been opened. If not then a mission is selected at random and the server checks to see if the mission exists in the players roster. If it does then the processes is repeated until a mission, chosen at random, is found that does not exist in the roster. The process can run hundreds of times before a suitable randomly selected mission is found.
The solution is to have a master list of randomly ordered missions that is parsed. This list is sequentially parsed to find the next mission that is not a duplicate. This means that the maximum number attempts to find a suitable mission is the same number as the number of missions. The first mission to be checked in the master list could be chosen at random and the master list could be periodically changed for variety.
The reason why there is a significant (unnecessary) server load is because the algorithm for choosing missions is poor.
Currently, when there is an attempt to open a mission, the server first checks to see if all missions have been opened. If not then a mission is selected at random and the server checks to see if the mission exists in the players roster. If it does then the processes is repeated until a mission, chosen at random, is found that does not exist in the roster. The process can run hundreds of times before a suitable randomly selected mission is found.
The solution is to have a master list of randomly ordered missions that is parsed. This list is sequentially parsed to find the next mission that is not a duplicate. This means that the maximum number attempts to find a suitable mission is the same number as the number of missions. The first mission to be checked in the master list could be chosen at random and the master list could be periodically changed for variety.
Point of interest: who reads the mission text, even in events? Just dole out the missions sequentially and I bet most people won’t notice and fewer still will care.
The reason why there is a significant (unnecessary) server load is because the algorithm for choosing missions is poor.
Currently, when there is an attempt to open a mission, the server first checks to see if all missions have been opened. If not then a mission is selected at random and the server checks to see if the mission exists in the players roster. If it does then the processes is repeated until a mission, chosen at random, is found that does not exist in the roster. The process can run hundreds of times before a suitable randomly selected mission is found.
The solution is to have a master list of randomly ordered missions that is parsed. This list is sequentially parsed to find the next mission that is not a duplicate. This means that the maximum number attempts to find a suitable mission is the same number as the number of missions. The first mission to be checked in the master list could be chosen at random and the master list could be periodically changed for variety.
So, I can prove that at least some of this isn't true.
In Chrome, run the app in Facebook and hit F12. This brings up the Chrome developer console.
You'll see a lot of stuff here, but, what we're interested in is the commands going back and forth, so go to the Network tab at the top.
In the application, open a shuttle mission.
In the network tab, you'll see an API call for "redeem_token" (to make things easier, you can type "redeem" into the filter in the top left so the other resource calls get filtered out).
Now, if your assertions were correct, you would see more and more requests as you opened more missions. However, I'm just seeing one request every time I open a mission. I opened up all the Augment missions and never got a duplicate request.
The ONE bit of truth in your message is that the server checks to see if all missions are opened. However, that is all wrapped in as part of the "redeem_token" call. This returns pretty quickly, so I'm pretty sure it queries their database for the opened missions and compares it to a max count. If that max has been reached, it doesn't even bother any sort of matching.
So, no, that isn't how it works. No developer at any ability level would ever create something like that. Please stop with your baseless speculation when you have no specific knowledge of the operation.
The reason why there is a significant (unnecessary) server load is because the algorithm for choosing missions is poor.
Currently, when there is an attempt to open a mission, the server first checks to see if all missions have been opened. If not then a mission is selected at random and the server checks to see if the mission exists in the players roster. If it does then the processes is repeated until a mission, chosen at random, is found that does not exist in the roster. The process can run hundreds of times before a suitable randomly selected mission is found.
The solution is to have a master list of randomly ordered missions that is parsed. This list is sequentially parsed to find the next mission that is not a duplicate. This means that the maximum number attempts to find a suitable mission is the same number as the number of missions. The first mission to be checked in the master list could be chosen at random and the master list could be periodically changed for variety.
So, I can prove that at least some of this isn't true.
In Chrome, run the app in Facebook and hit F12. This brings up the Chrome developer console.
You'll see a lot of stuff here, but, what we're interested in is the commands going back and forth, so go to the Network tab at the top.
In the application, open a shuttle mission.
In the network tab, you'll see an API call for "redeem_token" (to make things easier, you can type "redeem" into the filter in the top left so the other resource calls get filtered out).
Now, if your assertions were correct, you would see more and more requests as you opened more missions. However, I'm just seeing one request every time I open a mission. I opened up all the Augment missions and never got a duplicate request.
The ONE bit of truth in your message is that the server checks to see if all missions are opened. However, that is all wrapped in as part of the "redeem_token" call. This returns pretty quickly, so I'm pretty sure it queries their database for the opened missions and compares it to a max count. If that max has been reached, it doesn't even bother any sort of matching.
So, no, that isn't how it works. No developer at any ability level would ever create something like that. Please stop with your baseless speculation when you have no specific knowledge of the operation.
Not true. It is the redeem_token call that runs code on the server. It is the server that has the bad algorithm not the app. This, as you say, being all wrapped in as part of the "redeem_token" call. The issue regards, how long the server takes to complete the redeem_token call and hence the server load.
It is not baseless speculation it is expert speculation. You did not read my post thoroughly.
Randomly trying to get the next unused mission exponentially increases the time taken, to complete the request, as more missions have been opened. This is confirmed as it takes significantly longer to redeem the last token (get the last shuttle.) This is consistent with the methodology I have outlined as being the problem. If the algorithm was designed as I have suggested then the last mission would only take incrementally (and unnoticeably) longer to open. I.e the time taken to open the next mission, for each new mission, would be linear.
The reason why there is a significant (unnecessary) server load is because the algorithm for choosing missions is poor.
Currently, when there is an attempt to open a mission, the server first checks to see if all missions have been opened. If not then a mission is selected at random and the server checks to see if the mission exists in the players roster. If it does then the processes is repeated until a mission, chosen at random, is found that does not exist in the roster. The process can run hundreds of times before a suitable randomly selected mission is found.
The solution is to have a master list of randomly ordered missions that is parsed. This list is sequentially parsed to find the next mission that is not a duplicate. This means that the maximum number attempts to find a suitable mission is the same number as the number of missions. The first mission to be checked in the master list could be chosen at random and the master list could be periodically changed for variety.
So, I can prove that at least some of this isn't true.
In Chrome, run the app in Facebook and hit F12. This brings up the Chrome developer console.
You'll see a lot of stuff here, but, what we're interested in is the commands going back and forth, so go to the Network tab at the top.
In the application, open a shuttle mission.
In the network tab, you'll see an API call for "redeem_token" (to make things easier, you can type "redeem" into the filter in the top left so the other resource calls get filtered out).
Now, if your assertions were correct, you would see more and more requests as you opened more missions. However, I'm just seeing one request every time I open a mission. I opened up all the Augment missions and never got a duplicate request.
The ONE bit of truth in your message is that the server checks to see if all missions are opened. However, that is all wrapped in as part of the "redeem_token" call. This returns pretty quickly, so I'm pretty sure it queries their database for the opened missions and compares it to a max count. If that max has been reached, it doesn't even bother any sort of matching.
So, no, that isn't how it works. No developer at any ability level would ever create something like that. Please stop with your baseless speculation when you have no specific knowledge of the operation.
Not true. It is the redeem_token call that runs code on the server. It is the server that has the bad algorithm not the app. This, as you say, being all wrapped in as part of the "redeem_token" call. The issue regards, how long the server takes to complete the redeem_token call and hence the server load.
It is not baseless speculation it is expert speculation. You did not read my post thoroughly.
Randomly trying to get the next unused mission exponentially increases the time taken, to complete the request, as more missions have been opened. This is confirmed as it takes significantly longer to redeem the last token (get the last shuttle.) This is consistent with the methodology I have outlined as being the problem. If the algorithm was designed as I have suggested then the last mission would only take incrementally (and unnoticeably) longer to open. I.e the time taken to open the next mission, for each new mission, would be linear.
If it worked the way you suggest, then that time to return a mission would reset each time you started requesting missions from a different faction.
It does not. It continues to increase.
This is, more likely, due to the increased resources in displaying a large number of missions and duplicate requests for resources displaying each individual tile. Now, they certainly could do something about addressing how these resources are requested, but it has nothing to do with what you're suggesting.
I know this because I was asked to write a procedure that recorded stock levels. It was a stock take system where, on a daily basis 100 (if memory serves) parts numbers were selected at random to be manually counted. (There was a bias towards more expensive parts but that is not relevant here.)
The system worked well until there was a modification requested that all parts should be counted at least once a year. That meant that an additional bias was required to favour part numbers whose last count was further in the past but still be chosen at random.
This meant that choosing the last few part numbers took significantly longer to pick than previous ones. (This is the same issue as selecting the last shuttle in the mission list. It is significantly longer than selecting the second last mission.)
The solution was to create a list of part numbers that had not been selected in 11 months and randomly choose from that list then choose the rest of the part numbers as before.
Have to agree with Trista's comment on this - DB just needs to get better servers and stop making excuses for why they can't deliver on a product we pay for. I want all the missions or at least the variety of 3-4 slots if we aren't going to get 2 slots anymore. Get rid of all the 5 slots, no point in running them.
The reason why there is a significant (unnecessary) server load is because the algorithm for choosing missions is poor.
Currently, when there is an attempt to open a mission, the server first checks to see if all missions have been opened. If not then a mission is selected at random and the server checks to see if the mission exists in the players roster. If it does then the processes is repeated until a mission, chosen at random, is found that does not exist in the roster. The process can run hundreds of times before a suitable randomly selected mission is found.
The solution is to have a master list of randomly ordered missions that is parsed. This list is sequentially parsed to find the next mission that is not a duplicate. This means that the maximum number attempts to find a suitable mission is the same number as the number of missions. The first mission to be checked in the master list could be chosen at random and the master list could be periodically changed for variety.
So, I can prove that at least some of this isn't true.
In Chrome, run the app in Facebook and hit F12. This brings up the Chrome developer console.
You'll see a lot of stuff here, but, what we're interested in is the commands going back and forth, so go to the Network tab at the top.
In the application, open a shuttle mission.
In the network tab, you'll see an API call for "redeem_token" (to make things easier, you can type "redeem" into the filter in the top left so the other resource calls get filtered out).
Now, if your assertions were correct, you would see more and more requests as you opened more missions. However, I'm just seeing one request every time I open a mission. I opened up all the Augment missions and never got a duplicate request.
The ONE bit of truth in your message is that the server checks to see if all missions are opened. However, that is all wrapped in as part of the "redeem_token" call. This returns pretty quickly, so I'm pretty sure it queries their database for the opened missions and compares it to a max count. If that max has been reached, it doesn't even bother any sort of matching.
So, no, that isn't how it works. No developer at any ability level would ever create something like that. Please stop with your baseless speculation when you have no specific knowledge of the operation.
Not true. It is the redeem_token call that runs code on the server. It is the server that has the bad algorithm not the app. This, as you say, being all wrapped in as part of the "redeem_token" call. The issue regards, how long the server takes to complete the redeem_token call and hence the server load.
It is not baseless speculation it is expert speculation. You did not read my post thoroughly.
Randomly trying to get the next unused mission exponentially increases the time taken, to complete the request, as more missions have been opened. This is confirmed as it takes significantly longer to redeem the last token (get the last shuttle.) This is consistent with the methodology I have outlined as being the problem. If the algorithm was designed as I have suggested then the last mission would only take incrementally (and unnoticeably) longer to open. I.e the time taken to open the next mission, for each new mission, would be linear.
If it worked the way you suggest, then that time to return a mission would reset each time you started requesting missions from a different faction.
It does not. It continues to increase.
This is, more likely, due to the increased resources in displaying a large number of missions and duplicate requests for resources displaying each individual tile. Now, they certainly could do something about addressing how these resources are requested, but it has nothing to do with what you're suggesting.
If the issue was regarding transmitting resources then the effect would be linear and not exponential.
It does take less time to open the first mission in an unused faction cf the last opening in the previous faction.
To reduce the number of open missions thereby reducing server load, this because customers are cherry-picking the easiest missions, increase the rewards or success rate as the number of crew increases.
I always pick the first mission there is, five-seater or three-seater I don't care about. I wanna get done with the shuttles and go back to other things. Saves me lots of Merits and time. I have scored Top 50 in a faction event not so long ago with this strategy and I always do it like this. Top 200 to Top 500 is a regular for me now usually.
"Everything about the Jem'Hadar is lethal!" - Eris (ST-DS9 Episode 2x26 "The Jem'Hadar")
Comments
And I haven't attained a top 1000 rank in a Faction yet. However, 1500 and above several times which is my aim. If I don't look like I'm going to hit that (and I pretty much know by the end of the first day) I can relax and just send shuttles til I reach threshold.
Check out our website to find out more:
https://wiki.tenforwardloungers.com/
That's definitely a good strategy for you then. Keep building up your crew and your performance will constantly improve until you get consistent top 1500 and top 1000 finishes.
Over 16 months as F2P, I've built up 240+ immortals and I can tell that the bonus 4*s are what will make the difference. Spending on 5*s probably helps as well, but those 'useless' 4*s like Commando Shran that you vaulted 6 months ago will eventually be very important at some point.
Currently, when there is an attempt to open a mission, the server first checks to see if all missions have been opened. If not then a mission is selected at random and the server checks to see if the mission exists in the players roster. If it does then the processes is repeated until a mission, chosen at random, is found that does not exist in the roster. The process can run hundreds of times before a suitable randomly selected mission is found.
The solution is to have a master list of randomly ordered missions that is parsed. This list is sequentially parsed to find the next mission that is not a duplicate. This means that the maximum number attempts to find a suitable mission is the same number as the number of missions. The first mission to be checked in the master list could be chosen at random and the master list could be periodically changed for variety.
Point of interest: who reads the mission text, even in events? Just dole out the missions sequentially and I bet most people won’t notice and fewer still will care.
So, I can prove that at least some of this isn't true.
In Chrome, run the app in Facebook and hit F12. This brings up the Chrome developer console.
You'll see a lot of stuff here, but, what we're interested in is the commands going back and forth, so go to the Network tab at the top.
In the application, open a shuttle mission.
In the network tab, you'll see an API call for "redeem_token" (to make things easier, you can type "redeem" into the filter in the top left so the other resource calls get filtered out).
Now, if your assertions were correct, you would see more and more requests as you opened more missions. However, I'm just seeing one request every time I open a mission. I opened up all the Augment missions and never got a duplicate request.
The ONE bit of truth in your message is that the server checks to see if all missions are opened. However, that is all wrapped in as part of the "redeem_token" call. This returns pretty quickly, so I'm pretty sure it queries their database for the opened missions and compares it to a max count. If that max has been reached, it doesn't even bother any sort of matching.
So, no, that isn't how it works. No developer at any ability level would ever create something like that. Please stop with your baseless speculation when you have no specific knowledge of the operation.
Not true. It is the redeem_token call that runs code on the server. It is the server that has the bad algorithm not the app. This, as you say, being all wrapped in as part of the "redeem_token" call. The issue regards, how long the server takes to complete the redeem_token call and hence the server load.
It is not baseless speculation it is expert speculation. You did not read my post thoroughly.
Randomly trying to get the next unused mission exponentially increases the time taken, to complete the request, as more missions have been opened. This is confirmed as it takes significantly longer to redeem the last token (get the last shuttle.) This is consistent with the methodology I have outlined as being the problem. If the algorithm was designed as I have suggested then the last mission would only take incrementally (and unnoticeably) longer to open. I.e the time taken to open the next mission, for each new mission, would be linear.
If it worked the way you suggest, then that time to return a mission would reset each time you started requesting missions from a different faction.
It does not. It continues to increase.
This is, more likely, due to the increased resources in displaying a large number of missions and duplicate requests for resources displaying each individual tile. Now, they certainly could do something about addressing how these resources are requested, but it has nothing to do with what you're suggesting.
I know this because I was asked to write a procedure that recorded stock levels. It was a stock take system where, on a daily basis 100 (if memory serves) parts numbers were selected at random to be manually counted. (There was a bias towards more expensive parts but that is not relevant here.)
The system worked well until there was a modification requested that all parts should be counted at least once a year. That meant that an additional bias was required to favour part numbers whose last count was further in the past but still be chosen at random.
This meant that choosing the last few part numbers took significantly longer to pick than previous ones. (This is the same issue as selecting the last shuttle in the mission list. It is significantly longer than selecting the second last mission.)
The solution was to create a list of part numbers that had not been selected in 11 months and randomly choose from that list then choose the rest of the part numbers as before.
If the issue was regarding transmitting resources then the effect would be linear and not exponential.
It does take less time to open the first mission in an unused faction cf the last opening in the previous faction.
I always pick the first mission there is, five-seater or three-seater I don't care about. I wanna get done with the shuttles and go back to other things. Saves me lots of Merits and time. I have scored Top 50 in a faction event not so long ago with this strategy and I always do it like this. Top 200 to Top 500 is a regular for me now usually.