[erickho123]

WorldSelect#getWorld seems to return null unless it's been logged in game atleast once (limited testing, but i think once it has logged ingame once, it no longer returns null), but this causes things such as WorldSelect.setPreferedWorld on onstart to function properly

(Ignore title where i said it returns null unless it's in lobby)

 

[aidden]

@Cloud to ensure he sees this

 

[cloud]

The data is taken from the same source as the world selection list and thus is not available until Jagex decides to populate it.

 

[erickho123]

Doesn't the data stay the same? It would be beneficial if we could set a preferred world before logging in.

 

[cloud]

Doesn't the data stay the same? It would be beneficial if we could set a preferred world before logging in.

Jagex periodically adds new worlds, removes old ones, and changes the general assignments. They also frequently take them down for maintenance and other things and because of that we need to always have access to the latest worlds and their relevant information.

 

[arbiter]

By my understanding this is desired behavior and not a bug. Resolving.

 

[cloud]

By my understanding this is desired behavior and not a bug. Resolving.

I'm not entirely sure if I'd say this is entirely resolved or not. Optimally you would be able to get world data even if it's not currently loaded in rs client so that you can set it in onStart, however it would mean slightly changing our implementation.
What are your thoughts on
A. An hourly cron job that parses (or simply requests) a list of the currently available worlds and their attributes, and then stores them. We could then provide this list while syncing with our server, and use this list until the list from within the rs client is available.
B. Caching the list of worlds locally after the first time they become available, and using the cache until the list is available from within the rs client. This would work for every run after the first, however it wouldn't work for the first time and it would also make it so the list will be out of date if they haven't ran the client recently.

 

[aidden]

I'm not entirely sure if I'd say this is entirely resolved or not. Optimally you would be able to get world data even if it's not currently loaded in rs client so that you can set it in onStart, however it would mean slightly changing our implementation.
What are your thoughts on
A. An hourly cron job that parses (or simply requests) a list of the currently available worlds and their attributes, and then stores them. We could then provide this list while syncing with our server, and use this list until the list from within the rs client is available.
B. Caching the list of worlds locally after the first time they become available, and using the cache until the list is available from within the rs client. This would work for every run after the first, however it wouldn't work for the first time and it would also make it so the list will be out of date if they haven't ran the client recently.

I'd go for A @Arbiter

 

[erickho123]

I wouldn't say it is resolved either, A sounds good to me as well

 

[defeat3d]

I'm not entirely sure if I'd say this is entirely resolved or not. Optimally you would be able to get world data even if it's not currently loaded in rs client so that you can set it in onStart, however it would mean slightly changing our implementation.
What are your thoughts on
A. An hourly cron job that parses (or simply requests) a list of the currently available worlds and their attributes, and then stores them. We could then provide this list while syncing with our server, and use this list until the list from within the rs client is available.
B. Caching the list of worlds locally after the first time they become available, and using the cache until the list is available from within the rs client. This would work for every run after the first, however it wouldn't work for the first time and it would also make it so the list will be out of date if they haven't ran the client recently.

Option A would be nice.