https://imgur.com/a/qLF53mk
I think this is a bug. I cant load Research lab component, even though they should be available ?
The code prevents loading research labs if they are all in use for research projects. I don't remember whether I did this to copy Aurora or just to keep things simple.
I think there is a bug when fueling from a tanker to another tanker. It seems to not take fuel that will take the tanker below 10%. I don't think Aurora behave this way.
I tried reproducing this. I made two TG's each with a tanker at 10% fuel, then refuelled target fleet from one tanker to the other. After the transfer the tankers were correctly at 1% and 19%. If you can list a precise series of steps to produce the issue let me know.
LP numbering isn't entirely fixed. I have a vessel headed to LP4 for a jump to LP5, however the order in the TG window says LP3 jumping to LP4.
The description of fleet moves is generated when the order is first issued and then never changes. It should be OK for new orders.
Sometimes orders assigned by the geosurvey default order will get deleted in the wrong order when you use the "remove" button, getting deleted top-to-bottom instead of bottom-to-top.
Fixed. This uncovered a nasty bug that could have caused all kind of weird issues with default orders. Orders such as "survey next 5 bodies" were issuing all 5 orders numbered internally as 1,1,1,1,1 rather than 1,2,3,4,5.
Replacing a commander resets your search parameters, annoying for mass-replacement.
This should be fixed now, but have not verified.
When you click "add task" at the bottom of the shipyard window, the class list resets to the first class alphabetically, which is annoying for constructing [when multiple classes are available at one shipyard] or mass scrapping.
Fixed. Also updated a few dozen other drop-down menus to preserve their previous selections when possible after UI actions are taken.
I will eventually do this for lists as well. (quite a few already do preserve selections).
I just complained about the shipyard window resetting too often but there's also a proper bug from it not resetting enough. If you click a tooled shipyard which is set for construction, then click an un-tooled shipyard, the "new class" dropdown retains the class name from the tooled shipyard, which means you can use untooled shipyards to build any vessel for which another shipyard is tooled. I did this by accident at first and it took me a while to solve the mystery of why my untooled shipyard had no slipways available.
Fixed
As previously reported, projected mineral usage can go negative. This is because projected cost for the decimal places of a project hits 0 when the item is x. 5% complete, and then continues down into the negatives until the integer decrements (or the project is complete). For example, if you build a shipyard (1200 each duranium and neutronium), projected usage of those two minerals will count down from 1200 at the start to 0 at 50% complete to (almost) -1200 in the cycle before it finishes.
Fixed
A guy assigned to a geological team died, but the team rating didn't update and there was no team vacancy for me to fill in the Commanders->teams section, nor any way for me to assign someone to the team in the Teams & Academy tab (as far as I could tell). The four of them finished the task as normal, which was nice of them.
Fixed, and implemented the unassignment and reassignment of single commanders to/from teams.
The Fast OB spacemaster function incorrectly multiplies "total cost" by the number of vessels you've indicated to determine cost to decrement. If you design a 500-point vessel, then go into Fast OB and order 5 at once, it will cost you 5x500x5=12500 points. I recognize that this doesn't matter at all.
Fixed
I don't know if this is intended but in Quasar task-based skill increases go by 1% increments, while in Aurora task-based skill upgrades go by 5% increments (teams go by 1%).
Consequence: task-based skill upgrades are extremely slow; I've got commanders who have single-handedly geosurveyed a half-dozen systems each and the best anybody has done is +5%. It makes practical training kind of pointless when staff positions upgrade faster because they earn +5% at a time.
I'm not seeing a bug here. As in Aurora, single-commander duty-based bonuses grant +1%, not +5%, and it's even less if more than one commander is affected. +5% survey bonus is indeed periodically granted to staff leaders and staff survey officers, so it does seem like making many task forces for the sole purpose of skill-ups would be technically faster, if not tedious, than sending a bunch of officers out to do actual surveys. But is this not the case in Aurora as well?
There is still some kind of problem with the Geo/grav survey orders.
Here is a save in which i have 5 vessels all wanting to survey the same survey point, even though there is a lot of unsurveyed. I used a superior formation and copied orders to subordinary formations, maybe this is were the bug lay?
Well in this case they all got a default order to survey nearest survey point from their superior formation. None of them choose the survey point closest to their position but i think indeed the survey point they all want to survey is the closest to the superior formation.
Sounds like the order to 'survey nearest' was set before the fleet split and they all inherited it.
I'm pretty sure that is not the case, as the vessels very reordered after they had previously done the geo surveys.
I'm unable to find a bug. These ships are surveying survey points, although their default orders say they should be performing Geo surveys, so these active orders did not get generated by their current default order. I would need to see a copy of the save file from before this happened so I could trace how it played out. If you don't mind about 2-3 seconds of additional delay between turns, you can enable backups in the Quasar4x Settings menu so the next time this happens you can send me the prior save that leads up to the issue.
Here is an interesting one.
This mass driver is very, very effective.
https://imgur.com/a/SsUnGAg
Should have a capacity of 10.000 per year yet it shipped a whooping 250.000 in a 5 day increment.
I have not previously had troubles with mass drivers. This happened just after i put on "Reserve Level" and only for the minerals that i had set reserve levels for. So i think that's were the bug are.
Btw the minerals shipped off never turned up on the target body
Yikes, goodbye minerals. You have my permission to SM add them back
This bug is fixed.
I also fixed cargo loading orders to honor reserve settings, and a few other bizarre reserve-related bugs.
I think there are something with the system generation.
I run this setup with a 85% local generation and a spread of 8.
https://imgur.com/a/IvZ446S
Yet i have almost 30 system and not a single loop. This may or may not have something to do with the system numbers that I pointed out in a earlier post (i have system numbers up to 5000)
https://imgur.com/a/HcQ4CR4
Yep, unfortunately the bug that was allowing System Numbers ~10x higher than they should have been (fixed in a past update) would have reduced the odds of getting a loop. I did eyeball the code and verify that loops are possible. Although at 500 max systems / 85% local / ±8 spread, it is still easily possible to go 20-30 systems without seeing any loops. I'm unaware if Aurora goes out of its way to increase the odds of loops.
Version 100 is live with the above fixes, and also:
- Negative Wealth reduces the Economic Production Modifier (EPM). EPM is updated every production cycle based on ratio of racial debt to income, and logged if < 100%. Reduced EPM causes reduced rates of production, shipyard tasks, and research. It reduces ground unit maintenance costs, and gradually reduces ground readiness.
- Fixed image loading issues on linux related to case-sensitivity
- Fixed the message log for Alien Installation anomaly
- NPRClassType and minimum Rank Required assigned based on detected class type
