Forums » Suggestions
Add an indicator that missions are loading
When loading new missions, display some kind of indicator in the mission board so that people know there will be more missions listed if they wait a bit.
+1
Not knowing any details about how the new mission update system works, this might be more difficult than it seems on the surface. Sure, we know that when logging in the game takes it's time retrieving the missions, and it makes sense to be able to create a progress bar somewhere that fills up slowly as each mission or chunk of missions is received. But since this asynchronous mission update apparently continues even after the initial load, how then do you represent this?
display some kind of indicator in the mission board so that people know there will be more missions listed if they wait a bit.
OMFG Please!
OMFG Please!
+1
It doesn't need to be a loading bar. A spinning circle or blinking light would be fine. The important thing is simply knowing that it isn't finished yet. It doesn't even have to be perfectly accurate, since as far as I know, at any given moment new missions could be posted and show up the next time it checks. That's fine, the bulk of the loading has already been completed and any missions that have existed since the moment you logged in are gathered.
For example, let's hypothetically say there's an assortment of servers and databases the client has to check with when compiling the mission list. Let's say it checks with them all in a random async order, and continues checking with them vaguely periodically forever. When you enter the game, it would turn on the indicator and then start checking. It would maintain a list of all locations it needs to check, and would mark the appropriate entry in that list whenever it finished checking and updating from a location. It wouldn't turn the indicator off until all locations had been marked, even if some locations actually got checked several times before some of them got checked at all. By the time they have all been checked, it's possible that the first servers checked might now have more missions available if the hive just moved into a new sector or whatever, but that's fine.
If it only pulls the missions you qualify for, and something happens to significantly change your qualifications (going up a level, major standing change) it could reset the list of checked locations and activate the indicator again. It isn't a big deal if the indicator lights up for a while but it turns out there wasn't any change to available missions.
For example, let's hypothetically say there's an assortment of servers and databases the client has to check with when compiling the mission list. Let's say it checks with them all in a random async order, and continues checking with them vaguely periodically forever. When you enter the game, it would turn on the indicator and then start checking. It would maintain a list of all locations it needs to check, and would mark the appropriate entry in that list whenever it finished checking and updating from a location. It wouldn't turn the indicator off until all locations had been marked, even if some locations actually got checked several times before some of them got checked at all. By the time they have all been checked, it's possible that the first servers checked might now have more missions available if the hive just moved into a new sector or whatever, but that's fine.
If it only pulls the missions you qualify for, and something happens to significantly change your qualifications (going up a level, major standing change) it could reset the list of checked locations and activate the indicator again. It isn't a big deal if the indicator lights up for a while but it turns out there wasn't any change to available missions.
Let's say it checks with them all in a random async order, and continues checking with them vaguely periodically forever.
Except that, if I recall (although my recall is not perfect), it may not work like that. You're describing a polling-based mechanism, which is generally inefficient (every client has to check for updates constantly). I think we do more of a subscription-based mechanic, where the servers will send data to clients when they need it, and the client will not know it is about to receive new mission data until it begins receiving the data. Plus, each mission may be updated individually, instead of an "aggregate" that has a beginning and an end.
Beyond this, some of the more dynamic (Kourier) missions may be added and removed pretty frequently. So this "Updating Missions" light may flicker on quite a bit, but without people really noticing anything changing.
Anyway, we can look into it. Some kind of simple light or spinny thing, that's perhaps biased to not "stop spinning" until the client hasn't received any new mission data for several seconds.
Except that, if I recall (although my recall is not perfect), it may not work like that. You're describing a polling-based mechanism, which is generally inefficient (every client has to check for updates constantly). I think we do more of a subscription-based mechanic, where the servers will send data to clients when they need it, and the client will not know it is about to receive new mission data until it begins receiving the data. Plus, each mission may be updated individually, instead of an "aggregate" that has a beginning and an end.
Beyond this, some of the more dynamic (Kourier) missions may be added and removed pretty frequently. So this "Updating Missions" light may flicker on quite a bit, but without people really noticing anything changing.
Anyway, we can look into it. Some kind of simple light or spinny thing, that's perhaps biased to not "stop spinning" until the client hasn't received any new mission data for several seconds.
It used to be synchronous, right? Back when the missions-everywhere change was made and it took forever "Entering Universe."
If it's not resource-prohibitive, why not have the client query the server for a count of the missions available to your client? Then the client can total up how many it has and display "24/53 Missions. Loading <spinnything>" on the PDA. Every time the client gets mission info it can re-check that total.
That way what's visible to the user is always informative.
If it's not resource-prohibitive, why not have the client query the server for a count of the missions available to your client? Then the client can total up how many it has and display "24/53 Missions. Loading <spinnything>" on the PDA. Every time the client gets mission info it can re-check that total.
That way what's visible to the user is always informative.
Lots of things are possible, which ones are a good idea will remain to be seen. In general, avoiding protocol changes is a Good Thing. And we may well get to a point where the "total count" is pretty ephemeral.. so you may see 24/52 25/53 54/51 (albeit with bigger numbers) as things are added and removed.
But at least a light or spinner to say that things are still changing, could be done entirely client-side.
But at least a light or spinner to say that things are still changing, could be done entirely client-side.