Question on Production Queue Limit
Moderator: Oberlus
Question on Production Queue Limit
I am not sure why a while ago the limit of 100 items were put into the production queue. I have searched for a discussion but haven’t found it in the forum. I was just wondering if there is a way to override or raise this limit. If I build a galaxy with only a few stars, the limit isn’t a problem; but when I have over 100 stars, and I want to build something is most/all of these stars’ planets, the limit become a real headache; i.e. I have to manually track which stars I have built the item at and which I haven’t yet done so. Any suggestions on how to override this limit?
Re: Question on Production Queue Limit
The design direction is that there shouldn't be any items that you'd want to build on every one of your planets, I think. What are you building in this manner? Shipyards?
https://github.com/mmoderau
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Question on Production Queue Limit
I think queue length was limited mainly because of AIs putting hundreds of items on their queues, leading to very long turn processing time. The algorithm for estimating completion times for stuff on the queue takes O(N^2) time to run, where N is the number of items.
Re: Question on Production Queue Limit
I try to build a shipyard and then terraform each plant to the best state for the species on it. I also build outpost bases and/or colony bases plus an orbital dock on the first planet I occupy/capture to grab the remaining planets in the star system; plus building ships and such to keep expanding/fight monsters/etc. I can easily over-run the 100 limit. Is there a way to adjust it?
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Question on Production Queue Limit
Compile from source, undoing the linked change.sjolley wrote:I can easily over-run the 100 limit. Is there a way to adjust it?
Re: Question on Production Queue Limit
Would you be willing to identify the code module and the variable/constant that sets the limit? I would also like the variable used to set the number of stars in the galaxy. I will then set the limit to be a function of the size of the galaxy.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Question on Production Queue Limit
I did. See the linked commit.sjolley wrote:Would you be willing to identify the code module and the variable/constant that sets the limit?
The galaxy setup data sent from the client to server when starting a new game includes the number of systems to generate, but that isn't retained after the galaxy is created or sent back to the client with turn data. Consequently, there's no record of what it was or way to access it during gameplay.I would also like the variable used to set the number of stars in the galaxy.
Re: Question on Production Queue Limit
Thanks for the links.
I have gotten a successful compile with MSVS2010. Is there a script or other doucment that tells me how to move the correct .dll, .exe, ... files to their target directories so I can then run the new version I have complied?
Thanks again for all your help!
I have gotten a successful compile with MSVS2010. Is there a script or other doucment that tells me how to move the correct .dll, .exe, ... files to their target directories so I can then run the new version I have complied?
Thanks again for all your help!
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Question on Production Queue Limit
If you're using the SDK, they can be run from where they are built from the command line (cmd.exe). If you want to run using the green right-arrow run button you need to right click on the FreeOrion project, pick properties, go to the Configuration Properties -> Debugging section and change the working directory to $(TargetDir)sjolley wrote:Is there a script or other doucment that tells me how to move the correct .dll, .exe, ... files to their target directories so I can then run the new version I have complied?
- Attachments
-
- targetdir field in project properties
- TargetDir.png (72.37 KiB) Viewed 1303 times
Re: Question on Production Queue Limit
This sounds like the cause of a production queue problem I saw today -- I was building a lot of ships, and at some point well before my total PP allocation (usually around 65 items or so on the queue), then a bunch of items higher up on the queue, i.e. things that should be finished soon, would suddenly swap from whatever (I noticed it on items as low as 4 turns from completion, but that may be irrelevant) to showing "Never". To be clear -- later added items at the end of the queue, that should not have impacted the completion of items earlier in the queue, were blocking, or at least showing a blocking effect, on the earlier items. Thinking I needed to avoid that, I would remove some of the just-added items from the very end of the queue until my other items no longer showed as 'never', but that would sometimes require me to leave a third or half of my total PP unused.
Based on the above discussion, and review of the code, I'm now thinking that was more of just a display glitch due to the queue simulator timing out, and that most likely, each turn the actual progress that should have been made, would have been properly made, due to the call to SetProdQueueElementSpending prior to trying to simulate the queue.
It got into my head that the build queue completion times should be able to be calculated much more efficiently using a dynamic programming type approach, resource group by resource group, with
run time ~ O( n ) rather than O(n^2), so I went ahead and implemented that this weekend, I'll post the changed file down below in the programming section. With the regular boost timers, it's almost impossible to get the resolution to see any difference in individual simulation times (I think it gives min increments of 10 microseconds on my machine), but sometimes I could see that the regular algorithm had gotten bumped up to the 10 microsecond timing, whereas the DP one was always rated at zero. I looked at doing the more precise timers in boost/timer/timer but it overwrites boost::timer and so is incompatible with the rest of the current code.
With this change in algorithm, I also went ahead and increased the maximum items on the queue to 500, since the 100 limit was affecting me sometimes too.
Based on the above discussion, and review of the code, I'm now thinking that was more of just a display glitch due to the queue simulator timing out, and that most likely, each turn the actual progress that should have been made, would have been properly made, due to the call to SetProdQueueElementSpending prior to trying to simulate the queue.
It got into my head that the build queue completion times should be able to be calculated much more efficiently using a dynamic programming type approach, resource group by resource group, with
run time ~ O( n ) rather than O(n^2), so I went ahead and implemented that this weekend, I'll post the changed file down below in the programming section. With the regular boost timers, it's almost impossible to get the resolution to see any difference in individual simulation times (I think it gives min increments of 10 microseconds on my machine), but sometimes I could see that the regular algorithm had gotten bumped up to the 10 microsecond timing, whereas the DP one was always rated at zero. I looked at doing the more precise timers in boost/timer/timer but it overwrites boost::timer and so is incompatible with the rest of the current code.
With this change in algorithm, I also went ahead and increased the maximum items on the queue to 500, since the 100 limit was affecting me sometimes too.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0