Daily Dungeon Diver -- intelligent automation with NO-calendar-empowered prediction!
- Thread starter zarqon
- Start date
Bale
Minion
Another reason why 10 lines of code might be better than needing an external file for data.
zarqon
Well-known member
Funny, I see that as another reason not to allocate each map key/index individually in the script. Are the values conditional? No. Will the values need to be changed? No. It seems to me that these are ideal conditions for populating the map in one fell swoop with file_to_map().
At heart, this is just an issue of perspective. I tend to be pretty idealistic about coding and What Things Mean, but users are pragmatic -- they don't give a ratskin belt about how something is done, only whether or not it works and how easy it is to use. They would rather not click a few times to download an additional file. I would rather not define a map in-script piece-by-piece with static information, because a single ASH command exists to perform all of those many commands at once. This leads me to conclude that the code which Bale posted is doing unnecessary work, and is not how maps of static information are meant to be populated.
Pragmatically, Bale's user-centric solution saves the users some clicks when downloading and reduces the number of files by one, and is therefore better. Idealistically, my "Best Practices" approach populates a map using a single command designed for populating entire maps at once, rather than individual commands for each value (which is needless since none of the information needs to be filtered or decided), and is therefore better.
I tip my hat to you, pragmatic friend Bale. But I shall keep to my ideals (and even my perceived ideals).
If a constructor existed in ASH to define an entire map in the same line on which it was declared (as it does for records), this discussion would be moot.
At heart, this is just an issue of perspective. I tend to be pretty idealistic about coding and What Things Mean, but users are pragmatic -- they don't give a ratskin belt about how something is done, only whether or not it works and how easy it is to use. They would rather not click a few times to download an additional file. I would rather not define a map in-script piece-by-piece with static information, because a single ASH command exists to perform all of those many commands at once. This leads me to conclude that the code which Bale posted is doing unnecessary work, and is not how maps of static information are meant to be populated.
Pragmatically, Bale's user-centric solution saves the users some clicks when downloading and reduces the number of files by one, and is therefore better. Idealistically, my "Best Practices" approach populates a map using a single command designed for populating entire maps at once, rather than individual commands for each value (which is needless since none of the information needs to be filtered or decided), and is therefore better.
I tip my hat to you, pragmatic friend Bale. But I shall keep to my ideals (and even my perceived ideals).
If a constructor existed in ASH to define an entire map in the same line on which it was declared (as it does for records), this discussion would be moot.
Bale
Minion
That's fine. I don't find your approach to be offensive after all.
Though I consider one of the values of a datafile to be that you can download a new datafile if its values change or there are more options. That saves you from needing to modify the script to deal with a new restorative being added to the game. When the values don't change, then that advantage goes away.
Populating a map of merely 10 entires seems like a negligible speed difference compared to user friendliness. I understand the real issue is that it offends your sense of language efficiency. Your background as a linguist makes you feel like you would be wasting words and turning a simple concept into one that is obscured by excessive detail. That's two kinds of loss and no gain by such a standard.
Though I consider one of the values of a datafile to be that you can download a new datafile if its values change or there are more options. That saves you from needing to modify the script to deal with a new restorative being added to the game. When the values don't change, then that advantage goes away.
Populating a map of merely 10 entires seems like a negligible speed difference compared to user friendliness. I understand the real issue is that it offends your sense of language efficiency. Your background as a linguist makes you feel like you would be wasting words and turning a simple concept into one that is obscured by excessive detail. That's two kinds of loss and no gain by such a standard.
zarqon
Well-known member
You put it better than I did. That's it, on the knob.
I use this script whenever I go daily dungeoning. I only noticed just now (I'm not very attentive) that I'd been wasting a lot of adventures on it. I'd kept the default ddd_goal3 value of "potato sprout", since that was originally the right choice: get a potato if you don't already have one (for the first time ever or in Bad Moon), skip it if you already have one. Unfortunately, my past runs were all Avatar of Boris, where I neither have nor need any familiar. Oops.
Let this be a warning to those who use this script in Avatar of Boris (and maybe also Zombie Slayer; I haven't done any of those yet): change your ddd_goal3 to "none".
Let this be a warning to those who use this script in Avatar of Boris (and maybe also Zombie Slayer; I haven't done any of those yet): change your ddd_goal3 to "none".
zarqon
Well-known member
The funny thing is that just a few days ago I was running this script and thinking about how nice it was that this script always worked, without needing constant tweaks due to new content. And about how nice it was that they hadn't revamped the Daily Dungeon.
Well. It appears that since the dungeon is now random (we no longer need Noblisse Oblige's splendid help), the preparation is guesswork (general prep for all possibilities), the decisions are choiceadvs, and the zone is now an adventure.php area, this script is completely unnecessary and the choiceadv setting/preparation can be rolled into BBB.
So long, daily dungeon script! You were extremely helpful to me.
Well. It appears that since the dungeon is now random (we no longer need Noblisse Oblige's splendid help), the preparation is guesswork (general prep for all possibilities), the decisions are choiceadvs, and the zone is now an adventure.php area, this script is completely unnecessary and the choiceadv setting/preparation can be rolled into BBB.
So long, daily dungeon script! You were extremely helpful to me.