Request for improved build queue

[wayneb64]

The CQUI version was removed when the Vanilla game added it's own version but it doesn't work right. It won't let you queue a Harbor AND a Lighthouse and every time you capture a city you have to keep coming back and adding damaged buildings to the queue rather than all at once. Really annoying to me as I take a LOT of cities.

[Sharky444]

I concur. The original CQUI queue was awesome. The game-inbuild queue sucks.

[wayneb64]

Is the any chance this feature request can get some love? I realize this is probably not an easy upgrade but it's probably about the most annoying thing left to fix in the base UI.

[Rawrmonkeys]

This is such an important QoL feature, that I'm surprised no one has bothered to do it yet. I'm going to do a bit of a brain dump and will come back to this once I have a better understanding of modding in Civ VI (I've never made a video game mod before).

Firstly, I see there is an integrations folder. The PQ folder seems to be empty, so does that mean that it is been removed from the project? Last time I checked the mod description on Steam, it said that it still had it.

Looking at https://github.com/kblease/ProductionQueue and comparing ProductionPanel.lua, there is a 5000 line difference (along with other files). That is pretty crazy, but my HOPE is that that is mostly from writing the queue from scratch, so tweaking the in-game production queue will be much easier (hopefully as simple as overriding existing functions).

---

Design

---

So from a functionality perspective, what we need are

• Events for requesting add, remove, change order in the production queue
• The ability to change the selectability of an item (in the production panel)
• The ability to add an item (to the production panel)
• The ability to find all visible items in the production panel
• The ability to find all selectable items in the production panel
• The ability to find all queued items for a city
• The ability to change the order of queued items
• The ability to find buildings/units based on their requirements (and if anything extra has to be done to support unique buildings/units, wonders, and city projects)

Event Logic

---

on adding a building/district to the production queue:

• adjust the production panel accordingly
  • get list of all dependencies
    • if in production panel, evaluate if it now passes the requirements to be buildable and if it does, make selectable (non-obvious requirements would be like district placement for wonders)
    • if not in production panel and all other requirements are met (i.e. tech), add to the panel
    • does anything other than a district add new items to the panel? If not, then 'all other requirements' would not include building requirements. As in having the banking tech and adding commercial hub to the queue will add market, banking to the panel, but only market is selectable (also the commercial hub project will get added).
    • if other stuff than districts can add new items, then logic probably needs to be conditionally separated for districts and other stuff.

when removing an item from the queue

• check the queue for any dependent items and remove them
• adjust the production panel accordingly
  • this is going to do the opposite of what is described for adding to the panel, but it's going to have to do some sort of recursion or loop to properly handle multiple levels
  • a complicated example:
    • production queue of holy site, shrine, temple, mahabodhi temple and we remove the holy site
    • we probably want to start from the end. For our removed item, recursively find all dependent items that are in the queue and need adjustments. In this case, we would have an ordering of { mahabodhi temple, temple, shrine, holy site }. Now iterate through this.
      • remove mahabodhi from the queue (remove label if that enhancement is done)
      • remove temple from the queue. Apostle can no longer be bought, something like mahabodhi temple is no longer selectable, the religious building is no longer selectable
      • remove shrine from the queue. Missionary can no longer be bought, temple is no longer selectable (and any wonders that require a shrine aren't selectable either).
      • remove holy site from the queue. Missionary, Apostle, all holy site buildings, holy site project are removed from the panel (and adjust wonder selectability like before).

when moving an item around in the queue

• check the queue for any required items and whether those items need to be moved too
  • move all requirements with your selected item
  • moving forward example:
    • scout, scout, holy site, warrior, shrine -> holy site, shrine, scout, scout, warrior when moving shrine to the 1st item
  • moving backward example:
    • scout, holy site, shrine, warrior, scout -> scout, warrior, holy site, shrine, scout when swapping holy site with warrior

More stuff to think about

---

• with the described logic, will this automatically support restoring of damaged districts/buildings?
• IIRC, you get locked into the production cost of a district once you place it on the map. When you queue a district, you have to select a tile, but the vanilla queue won't place it on the map unless you put it as the 1st item. It also doesn't adjust anything (doesn't account for district limit or if that tile is occupied by another queued district). Ideally, you should be able to put it on the map just from adding it to the end of the queue, but as long as you are still locked into the production cost, I guess it would be ok (I'm guessing we aren't though).
• on a related note, there's no incentive to actually placing wonder buildings on the map until they've been put as the 1st item in the queue. Placing a label on the selected tile and removing the label once the building has been placed would be a neat QoL feature though. Additionally, a corner case that should be tested is moving a wonder to the 1st item in queue while it has dependencies that are also in queue (proposed design would be to move dependencies in front of it, but need to make sure we don't physically place the wonder on the map).

[Rawrmonkeys]

Updating the production panel

After digging through ProductionPanel.lua, it looks like there is a refresh function that is responsible for recreating all the state information. This involves creating the list (table) of what will show in the production panel and whether or not it will show as buildable. There is a function for the build queue 'canProduce' that is used both for controlling if the item is added to the list and whether it is added as buildable. Unfortunately, this function doesn't seem to be exposed. We can check all occurrences of that function and add in an 'or' conditional for whether or not the build requirements get met if you take into account the production queue. We should also take a look at the results table that is returned by 'canProduce' in case it gives stuff like missing building ids that would be easy to find in the production queue.

The complications for this are

1. We don't know exactly what 'canProduce' does. It is used both with 2 and 3 parameters, so it's behavior is situational.
2. There is also tons of duplicated code for this logic across districts, buildings, units, and projects.

So as long as adding/removing buildings to/from the queue triggers a refresh, we will properly update the production panel.

Managing the build queue

ProductionHelper.lua has RemoveQueueItem, SwapQueueItem, and MoveQueueItem that are hooked into stuff like mouse events. Those functions currently just take in indexes. We will situationally need to perform multiple operations on a single call, so we could pass in the build queue as the last parameter or handle that logic in a separate function that we define in ProductionPanel.

Remaining questions

Still not sure how we determine requirements from a building. Like how do we get the relationship of Shrine <-> Temple. I'm guessing that is defined in the simpler modding areas. Just not sure how to access from lua.

[Rawrmonkeys]

Extracting the failure reason

If something can't be built, the results object from 'canProduce' is a list of failure reasons. These failure reasons are the strings that show as a tooltip when hovering over a building. As in, there are no ids or relational crap that can be looked up somewhere. We will likely have to deduce failure types through something like a "contains" call (for displaying the tooltip, there is a locale lookup that happens afterward. Idk if that means this string will always be English or not. If it isn't, then cross language support will be a bit difficult...).

Buildings seem to have a prereq building list, but I don't think it has any value since we need to be comparing against what is in the build queue and a building with multiple prereqs will still need to isolate which prereq building is the one mentioned in the fail text.

Accessing items from the queue

ProductionHelper and ProductionManager each have a function for refreshing the queue. This iterates through the queue and builds a table of queue instances. Both call ProductionHelper's CreateQueueInstance function, which shows how to extract the item information (like building name). The active item in production is skipped in this queue instance stuff, but there is already a getter in the BuildQueue object to get that.

We will need to know the contents of the BuildQueue during the 'getData' function, but also on BuildQueue order manipulation events. I'm not sure how realistic it is to manage this separately from the underlying BuildQueue. As a first pass at least, we should just recreate the queue in every relevant function call (getData, RemoveQueueItem, SwapQueueItem, MoveQueueItem). The queue operation functions can add an extra parameter to know if it's part of a batch operation or not.

• i.e. scout, holy site, shrine moving shrine first would be a batch operation to get holy site, shrine, scout. You can build BuildQueue and figure out the operation list in the initial swap call and the rest of the calls won't need to do it. MoveQueueItem is never used in the code, should check what it does (if it moves to a spot and pushes everything after back 1, then that would be very useful).

[Rawrmonkeys]

The fail reason isn't adequate for determining if we should show/enable a building because it will only show the district failure reason if it is missing both the district and building. The building holds references to it's requirements, so I've taken the approach of evaluating those and looking at the queue in addition to the districts/buildings owned by the city. I think the failure reasons are still a valuable way of weeding stuff out though, so we won't override anything unless the building has a failure reason.

To test: unique buildings, religious buildings, mutually exclusive buildings

When adding a district to the build queue, there is already a panel refresh (assuming the same for building).

I've got the 1st building to show up in the list and show as enabled when adding a district to the build queue. Unfortunately, clicking the building seems to do nothing. Having the district as the active production target also causes it to leave the list (by design), but this now results in the newly shown buildings displaying under another district (so we should get rid of the behavior that removes it).

On the bright side, newly added buildings don't show as purchase-able.

To test: when queueing more districts than the city can build, make sure that any buildings with that district as a requirement are also removed from the queue (I think they will if the queue actions are implemented properly).

I'm thinking of making a repo for this. Like the old production queue, this should be a feature that exists standalone and can be integrated into CQUI. Will link the repo when I set it up (never made a repo before, so fingers crossed I use the right settings...).

[Rawrmonkeys]

So the reason the newly enabled buildings don't do anything when clicked is that the operation request doesn't seem to go through. There doesn't seem to be any feedback for that and this isn't exposed in lua, so there is nothing we can do about it.

CityManager.RequestOperation(city, CityOperationTypes.BUILD, tParameters);

I tried calling on BuildQueue:CreateBuilding, but that doesn't seem to work either.

We do have control over the display portion of the build queue though. The only way I see this working is if we track everything ourselves and make the display based off our queue instead of the underlying one. This will be a nightmare, but is theoretically doable. Will have to check if these queue's are used at all. ProductionPanel has RefreshQueue, ProductionHelper has RefreshProductionQueue. Both have similar behavior, so I think both need to produce the modified queue...

BuildQueue is mostly getter functions. BuildQueue:Create functions seem to only be used by the tuner, BuildQueue:GetAt seems to only be used by the 2 refresh functions, so it's looking like we only have to worry about UI when it comes to our managed queue vs the underlying one.

[Rawrmonkeys]

Looks like adding stuff to the display of the build queue does work. Doing stuff on the RefreshQueue functions doesn't seem to be enough to keep the multi-queue synched with it though.