This is actually not a bug. If you check out the documentation, the HurricaneData service provides access to the hurricane database (HURDAT2) from the NHC. This dataset currently only contains data up until 2020.

Both can be used for communication over the internet but messages are pushed to users and handled with a hat block whereas cloud variables require polling to see if they have changed.

They are both useful for slightly different situations. Multiplayer games would likely want to use messages for sending commands to each other (move, shoot, etc) and use cloud variables for storing high score lists, etc.

This is actually by design and is important when there are multiple types of projects accessing the same data. For example, a list of survey results could be stored in a cloud variables for everyone in a class to be able to access and analyze.

This is discussed in some detail here, too!

Yeah, that would be cool!

I believe the project size limit is the same as in Snap! but I would have to double check. The URL parameters work in NetsBlox too so if you run into it, you can take the same approach as Brian Harvey suggested.

Did you try using the reset password option?

Just saw this. Can you reproduce this? If so, how?

What browser are you using? There might be an option to "remember this choice for this site" or something like that.

Yep, the difference between cloud variables and cloud user variables is that the standard ones are global variables whereas the user variables are only accessible to a specific user. The "password" argument can be set the first time a variable is set and then it will be required for subsequent edits. Here are a couple examples of when you might want to use each type of cloud variable:

• Cloud variables w/ global scope:
  • High score list for a game
  • Recording responses to a poll or survey
  • Storing some text to share among others
• Cloud variables w/ user scope:
  • Saving data in an Alexa skill
  • Saving private data like a username or single user's game data

The key difference is that they occupy two different namespaces. If I make a regular cloud variable called "high score list", it will be accessible to any other user and project. If I don't set a password and another user decides to make a project using this variable name, then they will overwrite my variable (hence the importance of the password). Although this may sound like a bug, it makes cloud variables very flexible as they can be shared across users and different projects. If a password is used, then you can avoid this issue of an accidental overwrite by another user.

User-scoped cloud variables are only available to a specific user. We could all create our own variables with the same name without issue. One motivating use case for this is hiding data in public projects (such as an API key or password for accessing some web service directly via the HTTP block). Another example is the Alexa service. Intent handlers might want to record something (like a shopping list). If the project is shared, you don't want every user to share the same list as this would certainly be confusing! These variables don't need a password since each is unique to the current logged in user and cannot be overwritten by others.

Hopefully, this clears things up a little!

Yeah, the NetsBlox forums don't have as much activity as the Snap ones but they still seem to be useful :)

What kind of subtabs would you want for feature requests?

Tutorials and documentation is available here but I guess it might be nice to have a place for the community to contribute some, too.