The resources in SHOUT_CASE are those passed from the universal ECS resource map in core, as opposed to the lower case values which are from the mod intended either as functional identifiers (i.e., `name`, `type`) or just text to display to the user (i.e., `flavor`, `description`).
> From reading "The Order of Things" and looking at logs, it seems like ids of the opponents cards are always sent to the client, and the fact that no CardInfo message has been sent is what keeps each client from knowing the opponents cards.
This would be a problem if/when there's a way to play a card (i.e. show it to the opponent) and then restore it to your deck. Because the opponent now knows what card that id represents, they can easily cheat with a modified client or by looking at messa
Adding this .properties allows game board to have a place to store each player's properties so that these properties can be shown on the game screen. These properties are properties like HEALTH, MANA, etc.
added section for storing properties about each player
A new section has been added. This section first has a div that uses ng-repeat to go through each player's info. Then, each div that is repeated in that ng-repeat creates a new ul for storing all the properties of the player, which also uses an ng-repeat.
refactored storePlayerInfo, now adds to $scope.playerInfos
Before, depending on whether the player info message was talking about this user or if it was talking about the opponent, the code would have a conditional to set all the correct properties of currentUser.game.<player type>.<etc>.
However, this had a lot of repeat code because the only difference between the code in the two conditionals was where it was storing the data. Now, instead of all that, the code will store the player type (
Yesterday I found myself struggling with creating an A * algorithm in Java, but this morning I finally figured it out, so I would love to hear what Code Review has to say about it!
The goal here is not performance since it was a learning exercise. I tried to make the code and algorithm as reada...
I got rid of all the other nonesense, like playerInfo and oppInfo. That information has no use being in currentUser because there is only one scene that uses it, and now that one scene stores the correct information locally.
now enterNewGame sets currentUser properties (the player's own index) differently.
Now that a lot of space for information was removed from currentUser, the function enterNewGame stores the playerIndex in a different spot in currentUser.
Before, to store information about each player, this code was using currentPlayer. However, this was a poor idea because there is no other scene that needs that information so there is no point in storing it there.
A few parts of this code has been rewritten to adjust to the new place for storing and reading the information.
when displaying properties, now ng-repeats through $scope.playerProperties
The reason for this is because the function storePlayerPropertes in the controller code, while it does store the information in playerInfos, it stores the information for each player in an array.
I added a comment because I am unsure if this is necessary.
@skiwi the whole world is going to end up with this stagefright thing... just heard about it today
but considering most people barely even know how to use their phones, they certainly don't know how to protect themselves
just checked my phone, and it is possible to disable the auto retrieval of MMS in my 3rd party messaging app, but when i go into the official Messages app, the options are all greyed out.. hopefully it only checks the settings of the active one.
There is a class that provides methods for server messages - "queueForMatchmaking" translates to a someClass.queueForMatchmaking() call - "attack 42 0" translates to a someClass.attack(42, 0) call
The client somehow can also manage state per connection, so maybe create AbstractClient where you can store a Player for example
I'm thinking handling the server messages like this will be quite easy
It's a real bonus to have seen most of these things once already
And it's funny to see how naive you really are if you hard-code something like WebSocket client to your application instead of providing an interface... The former wouldn't even allow for easy testing
The nice thing about developing is that you learn every day
lol
> Henry Ford once balked at paying $10,000 to General Electric for work done troubleshooting a generator, and asked for an itemized bill. The engineer who performed the work, Charles Steinmetz, sent this: "Making chalk mark on generator, $1. Knowing where to make mark, $9,999." Ford paid the bill.
TTGTTLR (TTG to the living room), tomorrow work, maybe Friday time to start on a prototype
Yesterday I found myself struggling with creating an A * algorithm in Java, but this morning I finally figured it out, so I would love to hear what Code Review has to say about it!
The goal here is not performance since it was a learning exercise. I tried to make the code and algorithm as reada...
