So, I have a new idea on how to implement build queues for the game.
We had 3 problems preventing it before :
1. No space to store the queue data.
This can be solved by a workaround.
Currently buildings are stored in form of an array with each element containing -1 for not built, 0 for replaced, 1 for built, and 2 for destroyed (rubble) buildings. If I were to say numbers 10+X means that building is in the Xth place in the queue, then we managed to store the queue. This however requires going through every single building related procedure, making sure they check "building status =0 or 1" for the building existing. Those that instead check for "building status not equal to -1 or 2" would need to be changed.
This means units can't be queued, but I think that's fine. You usually don't know in advance how many of those you'll want anyway - depends on how your wars are going. (and most often once a city starts producing units, it keeps doing that for a while)
2. Checking requirements for queuing.
The above workaround actually already solves this, if we make an exception and for the "buildings available for production" procedure only, and nowhere else, we consider buildings in the queue as already built (so replacing the "status =0 or 1" with "status isn't -1 or 2", the opposite of what we normally need to do), then building requirements would automatically work. We need to only do this for buildings, not units.
3. User interface
This one is tricky, but I think we can manage with the existing two buttons on the production screen.
"cancel" would no longer be a thing, instead it would have the function "clear queue".
"Ok" would have two functions. If a building is selected, it adds the building to the queue.
If nothing is selected, then it leaves the production screen, so to build a building without queueing, you'd need to press it twice.
And finally if a unit, housing, or trade goods are selected, it would produce those immediately, replacing whatever is currently produced, or pushing it into the building queue (if it was a building). The building queue would keep existing, but won't have an effect until production is switched away from these options.
We would however need a way to have "nothing" available for selection, maybe by clicking anywhere else that's not a building, unit or button.
Two other changes will also be necessary - conquering a city will need to clear the queue to ensure AI players never meet the queued buildings since we won't make the AI used the queues obviously but it might confuse them (since it's a building with an effectively invalid status code from the AI's perspective), and, when a building is destroyed, the entire queue needs to be scanned for anything that requires that building, and if one exists, the destroyed building has to be queued immediately to the front of the queue instead of the usual end of it. (alternately, the entire queue could be cleared but that defeats the purpose of queues being an easy way to deal with earthquakes and meteor storms.)
Oh and of course the most important, when the building completes, it'd need to start building the next in queue automatically instead of showing the usual "completed" window.
Do let me know if there are any flaws in my logic and this can't be done. If there aren't any, then space might still be an issue (we'd need to add a lot of new code, to at least 3 different places, but then it's worth a try.
We had 3 problems preventing it before :
1. No space to store the queue data.
This can be solved by a workaround.
Currently buildings are stored in form of an array with each element containing -1 for not built, 0 for replaced, 1 for built, and 2 for destroyed (rubble) buildings. If I were to say numbers 10+X means that building is in the Xth place in the queue, then we managed to store the queue. This however requires going through every single building related procedure, making sure they check "building status =0 or 1" for the building existing. Those that instead check for "building status not equal to -1 or 2" would need to be changed.
This means units can't be queued, but I think that's fine. You usually don't know in advance how many of those you'll want anyway - depends on how your wars are going. (and most often once a city starts producing units, it keeps doing that for a while)
2. Checking requirements for queuing.
The above workaround actually already solves this, if we make an exception and for the "buildings available for production" procedure only, and nowhere else, we consider buildings in the queue as already built (so replacing the "status =0 or 1" with "status isn't -1 or 2", the opposite of what we normally need to do), then building requirements would automatically work. We need to only do this for buildings, not units.
3. User interface
This one is tricky, but I think we can manage with the existing two buttons on the production screen.
"cancel" would no longer be a thing, instead it would have the function "clear queue".
"Ok" would have two functions. If a building is selected, it adds the building to the queue.
If nothing is selected, then it leaves the production screen, so to build a building without queueing, you'd need to press it twice.
And finally if a unit, housing, or trade goods are selected, it would produce those immediately, replacing whatever is currently produced, or pushing it into the building queue (if it was a building). The building queue would keep existing, but won't have an effect until production is switched away from these options.
We would however need a way to have "nothing" available for selection, maybe by clicking anywhere else that's not a building, unit or button.
Two other changes will also be necessary - conquering a city will need to clear the queue to ensure AI players never meet the queued buildings since we won't make the AI used the queues obviously but it might confuse them (since it's a building with an effectively invalid status code from the AI's perspective), and, when a building is destroyed, the entire queue needs to be scanned for anything that requires that building, and if one exists, the destroyed building has to be queued immediately to the front of the queue instead of the usual end of it. (alternately, the entire queue could be cleared but that defeats the purpose of queues being an easy way to deal with earthquakes and meteor storms.)
Oh and of course the most important, when the building completes, it'd need to start building the next in queue automatically instead of showing the usual "completed" window.
Do let me know if there are any flaws in my logic and this can't be done. If there aren't any, then space might still be an issue (we'd need to add a lot of new code, to at least 3 different places, but then it's worth a try.
