Template talk:QuestDisplay

Using templates in parameters
Just a warning, when using templates as passed in parameters, it will make querying the cargo table harder. Passing just a comma separated list, then exploding it and putting the other template calls in QuestDisplay would make things easier. Specifically addressing FirstClearRewards/DropRewards/WeaponRewards/WyrmprintRewards/DailyDropReward/WeeklyDropReward. Fearsyth (talk) 22:51, 24 October 2018 (UTC)
 * The Rewards fields no longer store into the Quest Cargo tables but are in their own DropReward table now to better organize the data (via Template:DropReward). So the usage of templates passed inhere as parameters isn't an issue Cargo-wise. It actually makes querying easier due to the flexibility in how we can customize and maintain drop data now in its own separate table.


 * The issue with why we changed from the comma separated lists was that it was getting increasingly difficult to maintain several fields of comma-separated values just to explode and parse. In order to render the item icons, for example, a separate field needed to be stored of the types of the items (Material, Currency, etc.) due to how the Icon template works. There have also been requests to store min/max/avg of items per run as well, and that would require even more fields of comma-separated values to pair.


 * So in the previous method, we have several fields for one type of reward to keep track of, and also had to avoid input mistakes by paying close attention to all the indices of the comma-separated lists while exploding as well. And that's only for one of the reward types. Also on the off chance that we get more than X amount of rewards to explode, we have to go back and add new code. The template just felt like it was getting very crowded with so many explodes and chain of if statements in it for all the drop rewards and also felt very inflexible in dealing with a dynamic number of drops. While it does work, I didn't feel it was the best plan moving forward, hence why I decided to create a new Cargo table and template for drop rewards. In my opinion, the new template allows for much greater flexibility in maintaining and customizing how we want to display and store drop data.


 * To address your concerns about Cargo querying complexity though, here's a comparison if I wanted to query for daily drops for example (Code may not be exact syntactically since I didn't look up column names, but close enough that I hope you get the idea that I don't think querying with the new way would be difficult).

Previous:

New:

An additional benefit of the new method is (eventually) you can query for the # of certain materials. For example, if I wanted to query for # of Bronze Whetstones Shadow IO/Expert gives me, the previous method is a bit difficult since you'll have to explode the query output, explode it to find the index of Bronze Whetstone, and then explode the comma-separated list of amount of drops as well and get the value at the proper index.

With the new template, we can just directly query:


 * If you have any additional questions or concerns with the new template though, I'd be happy to discuss with you further to see if there's any other improvements that could be made. If it's more convenient, I also pinged you from Discord if you want a real-time discussion as well. Elaeagnifolia (talk) 02:00, 25 October 2018 (UTC)

DropQuantity field type
We discovered that certain quests like Agito and HDTs with weekly drop rewards were not being stored to the table. This was because the declared type of the  field was "Integer" but we were actually passing in Wikitext, resulting in an inability to store. This was fixed in https://dragalialost.gamepedia.com/Template:QuestDisplay?diff=112360&oldid=111854 by setting the fields to Wikitext type instead, as the most straightforward solution.

Though, because having a quantity field be a non-integer is a little weird, we also considered the alternative of switching all the calls to passing in a plain integer instead and updating QuestDisplay to then pass that integer to the Chest icon rendering template instead of the other way around. This is still on the table but not an urgent change. -eave 04:28, 12 November 2020 (UTC)