-
Notifications
You must be signed in to change notification settings - Fork 5
Merge develop into master #137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Before, all the available servers were hardcoded into the select in the login form of the login page. This made adding new servers a bit more difficult, because an entire new element would have to be added each time, which only leads to copy paste coding. Now, all the servers are stored in $scope.servers, which is an object that is mapped [server name: server address]. Then, through use of ng-repeat, a new <option> is created for each server under the select.
Before, servers were stored in an object like this: [name: address]. Of course, this does not include enough information for the user. Is the server online? What about the users? How many of those are these? And the latency? I'm I going to be stuck trying to send a chat message?
Now, the servers are stored in an object like this:
name:
address
isOnline
userCount
latency
…ation At the top of the login page, there is now a table that holds 4 pieces of information for each server: the server name, whether the server is online or not, the amount of users on the server, and the latency of the user's connection to the server
The updateStats function so far initializes the API and gets a latency count by storing the time before the init call and getting the time after, and the code can easily find out if the server is online if the connection is made at all. This currently does not work and is being tested.
…o checking for "Other..." Now the code sort of works. It will only display information for stats.zomis.net, but the latency is blown out of proportion: I was reaching 2000+ ms. I think the reason for this is because the server is being queried to quickly, so by the time init's third parameter runs, it is using an old local `now` variable. Another issue: this will not recognize a local host server.
Instead of checking the server stats every 2 seconds, there is now a refresh button. There are still some bugs to be worked out, for example, if the server does not exist (local host), then the code dies. And, if the server does exist, the code may sit waiting for a response indefinitely, even though one may never be received. And, this refersh button allows for an easy attempt of a DoS on the server. Maybe this idea should be put off for a little while.
…one doesn't exist
This class is used to store information about each server for the server status table. It holds information like the user count, the latency, and whether or not the server is online.
…ardInfo, addressing #84
Before, when the ServerInfo object was being created for "Other", the name was set to null. However, the login code checks to see if it is equal to "other", so this was changed: null --> "other"
This has a bug: the HTML is not updated. Perhaps this has to do with the fact that this is async.
When this button is clicked, the server stats table is updated with the information about the servers.
This reverts commit 83012cf.
This reverts commit 5544c6c.
Now, the user can only hit the refresh button only every 3 seconds
…s with the local variables passed into it. Before, when this loop inside $scope.refreshServers was running, since API.init is async, the loop would finish instantly and the local `thisServer` would be the very last server in the list. Now, an anonymous function is passed to the init method that is given the current server when it is passed in so it does not change in that function's scope.
It is quite easy to attempt and crash a server just by smashing the "refresh" button. Right now, there is an interval setup to disable this button for a certain amount of time, but it still needs some work (aka: it doesn't work)
The two anonymous functions that were being passed to API.init have been removed. Now, the entire API.init call is encased in an anonymous function.
Deploy script
Before, when using setMessageListener, all the controllers would look about the same in that area: they would have a commandMap for all the types of messages they were looking for, or, they would just accept a single type of message. Then, inside the listener function body that was passed to setMessageListener, it would call the correct function in the commandMap and then use $scope.$apply to apply it. Now, the setMessageListener method will accept the commandMap as one of it's parameters (along with the scope) so there is none of this repetitiion across controllers.
More user friendly than 'MAX_MANA'.
Small fixes
* remotes/origin/errors: now displays api information in the browser console removed last console.log api is now a factory correctly injects debug replaced console.logs with debugs added debug dependency removed some nesting and unnecessary code removed "Client Error:" from error message fixed ErrorCreator.create call all sent and received messages can now be seen via the browser console chat errors messages now use ErrorCreator instead all the controllers now use CardshifterServerAPI.setMessageListener correctly changed how setMessageListener works added listening for ServerErrorMessage added ErrorCreator.creates where there were console.logs fixed up the error creator; it now works! a basic error creator service basic error message modal html includes and creates the errorCreator service only tries to display "from" in a chat message if it exists, cleaned up chat error grammar
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merge develop into master to include bug fixes and changes from Oct 2015.