That’s possible. For it to work you’d have to create a “dropdown block” and select the “dynamic” option in its settings. Then, you will be able to select a dataframe and the column from that dataframe you want to use as dropdown options.
By the way, every query automatically becomes a dataframe so you can use either a query result’s column or a raw Python dataframe.
As a side note, I’m putting together detailed product documentation this week too and I’ll make sure to include it there.
Social spaces work differently to patrol areas. 1 player won't occupy a full party worth of spots in a social space, it's possible you try to join your friend at a social space and get an error that the area is full.
Vault of Glass released merely weeks after launch, just like how Destiny 2's raid (Leviathan) did too. A lot of Destiny 2's complaints about end-game aren't about the quantity of content, it's the lack of incentive to play it; loot from the raid is underwhelming, loot in general doesn't offer anything to chase with fixed rolls and everything feeling much more homogenous (less perks on items and perks are less impactful), big design changes to PvP that massively affect the way games play out.
> Not having a real controller cripples this type of game.
I disagree, this type of game is perfect for a touch screen. All you need to do is tap anywhere you like on the screen, you get all the tactile feedback you need.
The problem with "memoize" is people always think I'm trying to say "memorize" with a speech impediment, especially because both words usually (kind of) make sense in the context.
Also, some spellcheckers will surreptitiously auto-"correct" memoization to "memorization" (as, e.g. Word, and I happen to know it does that because it did it in my Master's dissertation; luckily, just a footnote but probably made me look like an idiot trying to show off with terms I don't understand).
Can somebody please point out to me the obvious fact I am missing. Don't Apple design their security such that even they themselves can't crack it? Like storing hashed passwords, they don't want that kind of accountability. The media keeps suggesting that Apple won't do it, I thought it would be the case that Apple can't do it...
Apple did try to design encryption that it can't break. But they also want to be able to fix bugs. So they can update the OS on the phone even if it is locked.
So by writing a new update, they could remove some of the ancillary security features that reinforce short passcodes: the "wipe after 10 tries" feature, and the "progressively longer delay between tries" feature. Without these, a numeric (short) passcode can be brute-forced in a day or two. This is what the FBI has been trying to force them to do: write a new update to remove these features. That's what Apple has been refusing to do.
BTW, if you use a long alphanumeric passcode, then it wouldn't matter if Apple was forced to push this update. A 15 character passcode with upper case, lower case, numbers, and symbols would probably be safe from brute forcing no matter how fast someone tries. But most folks are not willing to remember or type in 15 characters on their phone.
Does anybody know how big the seed is for Diablo's RNG? I'm guessing it would have to be 1 value for the environment (to ensure saving/reloading into the same world) but would that 1 value determine all pseudo-randomness (AI aside) in the game (e.g. item drops and their stats).
The seed is a 32-bit signed integer [1]. Diablo 1 was using the Borland C/C++ pseudo-random number generator algorithm, with a multiplier of 0x15A4E35 and an increment of 1 [2,3]. A Go implementation of the PRNG used in Diablo 1 is located at [4].
So I guess there are 2^31-1 unique dungeons per level. Storing, rather than dynamically generating, these dungeons would require a huge amount of disk space. For each level, a 112x112 two-dimensional array of 32-bit integers is used to store the piece IDs which make up each tile (a tile consists of four pieces) [5], and a 40x40 two-dimensional array of 8-bit integers is used to store the tile IDs [6]. Thus, a total of 51776 bytes (roughly 50 KB) is required to store the contents of each generated dungeon.
In total, more than 100 TB would be required to store the contents of each unique procedurally generated dungeon per level. The game contains 17 levels, so to store each unique dungeon for each level, a storage capacity of about 1.7 PB would be required. This might be possible today, but was definitely a challenge back in 1996.
The way they talk about their Dynamic Random Level Generation suggests they probably already somewhat developed it (and probably other aspects of the game) as a proof of concept.
Yep, thanks, all fixed ! Surprising how many mistakes one can make in a simple sentence...although, as feeble justification -- I wrote that right after I read the article and was still thinking about some of the stuff. There was a bit of irony though in these corrections -- how we tend to focus on and willing choose to spend energy on the things that don't matter in the long run for things that make us feel good about ourselves.
Not just the long run! It looks like 'dang' already rewrote it to get rid of all of those words. But at least I'll sleep easier knowing that as a team we were able to fix the mistakes before it was erased. :)
Makes me think there's a very grey area between declarative programming languages and just plain data. If writing HTML is considered programming, does that make a draftsman drawing up building plans a programmer?
Does the dashboard feature support any dynamic field selectors (similar to "variables" in Grafana)?