View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0024544 | AI War 2 | GUI | Mar 12, 2021 10:46 pm | Mar 15, 2021 7:31 pm | |
| Reporter | Sigma7 | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | Beta 2.757 Super Mega Exciting Sidebar | ||||
| Fixed in Version | Beta 2.758 Threat Explanation | ||||
| Summary | 0024544: Resource starvation timer incorrect | ||||
| Description | The resource timer for metal starvation is hovering around 1 second for a long period of time. Expected result should be to say a few minutes instead. To make the bug more obvious, the gui should be adjusted, and maybe the change could be kept if there's no objections: * In UIs\InGamePassiveDisplay\Window_ResourceBar.cs - class tMetal, method HandleMouseover * Please have the popup track localFaction.LastFrame_TotalMetalFlowProjectedRequests and display it when there's metal starvation. * In game, this will show projected requests as being equal to outflow, when it clearly should be higher. The root cause is repairing vessels and building strikecraft doesn't seem to be populating that value. If I scrap the Station-Keeping Watchman frigates, those get tracked properly. This bit isn't user moddable. Attached save - see squad 3 (Strike Bragaltet) - | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
It's user moddable. It's all in External code. The problem is it's actually really hard to find all the information needed to give a reasonable assessment. I did something like that when making the fleet health screen, I just never bothered to redo it all to improve that text. |
|
|
I'm actually seeing the bug in ArcenAIW2Core.dll rather than external code. Class Faction, method ExecutePlannedMetalFlows. The output variable totalMetalFlowProjectedRequests receives total metal remaining at debug codes 1200 and 1600, but receives some metal per second at debugcode 2700 and 3100. Also, internal drone building doesn't seem to get tracked. |
|
|
And now I discovered it's overestimating self-construction or capturing neutrals. Each engineer is trying to demand the full price of a black widow golem, and thus I have to eventually supply 1 billion worth of metal when I know it's much less. As such, it looks like it's getting the data, but is simply miscalculating it. |
|
|
Internal drone building actually is free, IIRC. It has a metal cost for throughput, but doesn't actually charge you for it. Same for repairing shields. |
|
|
Thanks! * When you are in a Drain situation in metal, it now should give you a more accurate percentage of what you have remaining, as well as a more accurate timer of how long it will take to complete all of your current work. ** Previously, it was really just wrong in a variety of ways. *** Now it only counts each thing being built in a fleet once, no matter how many factories were helping it. Previously, 3-4 factories would cause it to to be 3-4x as high. *** However, now it also counts how long it will take to build the rest of the entire queue for a fleet item, if it's not disabled, so that might be 50 things rather than 1, 3, or 4. ** Anything that was self-building, or being assisted by engineers was already correctly calculated. ** Any drones being built were already correctly calculated, and same with rebuilding remains, in that those don't actually cost you any metal at all. Note that after something is rebuilt from remains, it has to be repaired, and THAT part has a cost, which is correctly tracked now. ** Anything being claimed is now correctly tracked, whereas before it was estimating vastly too much. If a golem that cost 1m metal had 5 things working on it, it would think you needed 5m metal. Way off. ** Engine repairs are free, and those are now properly ignored. The metal allocated for them is just for how fast they are repaired, but it was showing up as an actual amount you'd need to spend. Same thing for personal shields being repaired. That's also free. ** For hull health and bubble forcefield repair, it now tracks the remaining cost correctly, versus before it was only including a tiny fraction of what was needed, plus also multiplying that by the number of repairing engineers. That just had no connection to reality, really. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Mar 12, 2021 10:46 pm | Sigma7 | New Issue | |
| Mar 12, 2021 10:46 pm | Sigma7 | File Added: Autosave at 17m 0s.save | |
| Mar 13, 2021 12:04 am | BadgerBadger | Note Added: 0060760 | |
| Mar 13, 2021 9:48 am | Sigma7 | Note Added: 0060761 | |
| Mar 13, 2021 9:48 am | Sigma7 | Description Updated | |
| Mar 13, 2021 7:56 pm | Sigma7 | Note Added: 0060767 | |
| Mar 15, 2021 6:34 pm | Chris_McElligottPark | Note Added: 0060791 | |
| Mar 15, 2021 7:31 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Mar 15, 2021 7:31 pm | Chris_McElligottPark | Status | new => resolved |
| Mar 15, 2021 7:31 pm | Chris_McElligottPark | Resolution | open => fixed |
| Mar 15, 2021 7:31 pm | Chris_McElligottPark | Fixed in Version | => Beta 2.758 Threat Explanation |
| Mar 15, 2021 7:31 pm | Chris_McElligottPark | Note Added: 0060792 |
