4.26 Bugs

[Steve Walmsley]

I had a team that was on a ship that got blew up by an enemy, in which the captain of the ship got killed.  The team members did not get killed, and the team still existed, albeit in limbo and the members had no location on the Officer window.

This also happens when an espionage team is captured or killed.  They don't die or go to the no longer active category, but rather, are assigned to the "0" club.  

I think I have fixed all the various 'member of 0' problems for v4.3

Steve

[Steve Walmsley]

A very boring bug.
in F4,Search by Ability or location windows,Ability A: trade bonus,come this bug:
Error 91...Object variable or With block variable not set

if u "flag" unassigned Officers only come an bug windos for EVERY Unassigned officers...)...

2000 unassigned..u imagine.

Trade is an old bonus so I have removed it for the next version.

Steve

[Steve Walmsley]

Just started a 4.26 game, explored a couple of jump points. I have civilian shipping showing up in the newly explored system when I know they are in home system. Also saw this in 4.1. You can deselect and reselect the system to clear the problem, just a little irritating

I think this is an intermittent bug with the display of contacts rather than the civilian shipping actually moving. It's been around for a while and I haven't pinned it down yet.

Steve

[Steve Walmsley]

Receiving an "Error in CheckForMaintenanceFacilities" Error 91 was generated by Aurora, Object variable or With block variable not set.

Message continues to repeat until I kill the program.  
I have maintenance turned off for this galaxy.

Update:  First receive this error message:

Error 3075 was generated by DAO.Datebase
Syntax error (missing operator) in query express 'f.RaceID = 827 and f.SystemID = f.Xcor = -76964650 and f.Ycor = -128283291 and s.FleetID = f.FleetID and s.CurrentMaint > 0'.

Thanks for the update. The error 91 will occur when trying access a database record that doesn't exist, which is explained by the error above as it would stop the database record being retrieved. What is puzzling me though is trying to recreate it. It's a fairly common function call and a short function. I have identified the piece of code that almost matches the above but the above is missing a small section between 'SystemID ='  and 'f.Xcor' which does exist in the code. Somehow the string variable that holds the SQL seems to have lost a section from the middle of the text. I have added a breakpoint to the function so I will keep tracking it and try to recreate the problem.

Steve

[Steve Walmsley]

I have my Battle Fleet heading 3 systems away to put some hurt on a hostile race. As an escort, I gave two other fleets the command to stay 50k km ahead and offset 20 degrees clockwise and anticlockwise. I had Battle Fleet setup to move to the entry JG of the hostile race and the 2 escort fleets moved into position correctly. But, on the first exit JG from Sol, the two escort fleets didn't jump after the Battle Fleet. Instead, they appeared to move in a random direction within the Sol system for the rest of the timespan. It took 4 days to get everything back in shape.

Thinking about it some more, the escort fleets may have been trying to move to the X/Y coords of the Battle Fleet, only in the Sol system.

Formations can't handle jumps, mainly because it gets very tricky during combat jumps unless every escort can jump. The best option for the moment is to use the Save Escorts button to store the layout of the formation. Use Recall Escorts before you jump and then Deploy Escorts after the jump.

Steve

[Steve Walmsley]

Aurora is not interrupting properly when an NPR transits into a system whose WP is under observation by active sensors.

I've had a picket watching the WP into an NPR home system, about 1M km off with active sensors with a range of about 12M km.  The NPR had already sent through an gate construction ship (based on size and behavior).  I just did a 140,000 second update (which resolves to 40 hours), and got a interrupt enumerating 3 new thermal contacts at t+8 hours.  When I went to look, the NPR had sent 3 ships through the WP, but they had already moved out of range of my actives - about 15M km.  Fortunately, I had just saved, so I reloaded the DB and ran the same update with 30 second timestep (yeah for the rewrite - it didn't take long at all).  This time it worked ok - they were detected at 6 hours, 31 minutes (note that they were already off the WP, but I'm willing to chalk that up to "activation lag" by bored picket sensor operators).

I am stepping through the code to try and figure out what happened. The code is set to generate an interrupt if a transit is actively detected by a hostile race or if the transiting ship is only picked up on passive sensors and its identity is unknown. I am guessing this was a neutral ship, in which case I probably need to adjust the logic so that time also stops for neutral NPRs but perhaps not neutral player races. Or perhaps just for recently discovered neutral NPRs. Before I shoot off in this direction, could you confirm if the NPR was neutral or hostile?

Steve

[Steve Walmsley]

Steve

I'm not sure if this is a bug or not. When you rescue survivors from lifepods you are able to unload them at a suitable planet. However, after a few days, this option seems to disappear from the list of orders and the survivors are no longer present in the rescuing fleet. I seem to remember this happening before and this includes rescued commanders.

Took a little while but I tracked it down

Aurora filters orders on the Fleet Window so that you don't have to scroll through every possible order for every fleet. For example, a fleet won't be given the option of a survey order if it doesn't have survey intruments and it won't be given the option of an unload construction factory order unless the fleet is either transporting a construction factory or has an order to pick one up. In this case of dropping off survivors, the fleet can use Unload Survivors if the order list contains Rescue Survivors. However, the bug is that the fleet window doesn't allow the Unload Survivors order just because survivors are on board. This is why it looked like the survivors were vanishing. They are actually still on the ship but the Unload Survivors order wasn't being let through the filter process unless a Rescue Survivors order was already in the order queue. I have fixed the problem for v4.3 so the Unload Survivors order is allowed when either survivors are already on board or a rescue is planned. In the meantime, you can get around the problem by turning off the order filtering on the Fleet window.

Steve

[Steve Walmsley]

There is a problem with the way civilians and NPRs name ships.
When I get ships from conquering an NPR there can be duplicate names.

Do you mean they have the same names as your ships or that two NPR ships have the same name. If it's the former, it's because the name filtering is done on a racial basis rather than the game as a whole. It's actually quite common in real life for different nations to give their ships the same name. If it's the latter, I need to take a look at the code as that shouldn't happen.

When I sell ships to the civilians (via the task group window), the civilians name all the ships in a fleet the same name. Confirmed by checking the database tables directly.

I should have removed the option to sell to civilians until I update it to the new civilian model. It's gone for v4.3.

By the way these ships are not in a shipping line and thus are not visible to the class design inventory.

Yes, that's the type of problem that will occur until I update it. I'll add something back in once I get time to play with it.

Also I have learned the hard way, you can delete a design (with no ships) that is active in a shipyard.
This causes a bunch of errors until a good design is refitted.

I have added extra checks to the Delete Class function to avoid that problem

Loving the new civilian markets  

Thanks!

Steve

[Steve Walmsley]

Steve, is this for any base "built as a PDC" or those that have the hull type Planetary Defence Centre?  I am asking because I used other hull types for some of my bases "anti-missile base" and "sensor outpost."

If it is fixed at last thanks.

It's based on the Type (Ship or PDC) rather than the Hull.

Steve

[Steve Walmsley]

A related suggestion - I can't find a break-out of the contribution to the economy that my financial centers are making.  Are they included in population taxes?  It would be nice if they were broken out in the wealth tab so I could get a feel for how effective financial centers are decreasing my run rate.

I've changed the code so that the income from actual population and from financial centres is displayed separately on the Wealth tab.

Steve

[Steve Walmsley]

It appears that trade is not being properly accounted for in the wealth run rate at the top of the Population (F2) screen.

At the end of a recent econ update, the top of my F2 screen said I had 65551 wealth, with a run rate of -122.  Over the next few days, the run rate gradually dropped; after 4 days (i.e. just before the next econ update, since I was using 1-day updates) it stood at 65604 wealth, and a run rate of -69.  Hitting a 1-day update (and going through the econ cycle) it was back to 65503 and -112.  The correct run rate would be -48.

It appears that what is going on is that the code to refresh the run rate during an econ update is just comparing the wealth of the start of the update to the wealth at the end - this is ignoring the trade that flowed in during the 5-day.

I believe you are correct. At the start of an update the existing wealth is recorded for the Race as PreviousWealth and the run rate is always the current wealth minus the PreviousWealth.

Assume that a Race has 1100 wealth and is losing 100 during every economic update. At the start of the first economic update the PreviousWealth will be recorded as 1100. Once the update is over, the current wealth will be 1000 and the run rate will correctly show -100. Now lets assume that the race starts to generate trade income and 40 comes in before the start of the next economic update. Before that update takes place, the current wealth will be 1040 and the run rate will show as -60. The program will then record the current Wealth as PreviousWealth (1040) and run the update, using up another 100 wealth and taking the current wealth to 940. This will result in a run rate of -100, whereas in reality the difference between the wealth situation at the end of the first and second updates is only -60.

Therefore I think I need to also record the wealth at the end of an update as well. I'll call it StartingWealth. Now what I do is record the PreviousWealth figure as the previous StartingWealth rather than the current wealth. Using the same scenario as above, that means after the first update the PreviousWealth will still be 1100 (as no trade is involved yet) and I will also record a StartingWealth figure of 1000 after the update is completed. The current wealth is 1000 so the run rate (current wealth minus the PreviousWealth) is -100. Now the 40 trade comes in and takes the current wealth to 1040. However, at the start of the next update I record PreviousWealth as 1000 as that is the StartingWealth figure (not the current wealth). After the update is complete and 100 has been deducted from the 1040 current wealth, leaving 940, I record the new StartingWealth figure of 940. The run rate is now -60 (current wealth minus the PreviousWealth figure of 1000), which is also correct.

Going through one more update to check it works. Assume 30 trade income before the next update, which takes the current wealth to 970. At the start of the next update I record PreviousWealth as 940 (which was is the StartingWealth from above) and run the update. The -100 during the update takes the current wealth figure to 870, which is recorded as the new StartingWealth. The run rate is now -70 (current wealth minus the PreviousWealth figure of 940), which is correct compared to the same point after the last update.

Steve

[Steve Walmsley]

Steve while I had my 3 geosurvey ships out doing essentially automated surveys they kept triggering error 3102 record missing.  I had them set to survey planets and moons primary and asteroids as secondary.  This seemed to be related to them doing asteroid surveys.  It vanished when I switched orders around to next 5 system bodies.

I've tried setting geo survey ships to asteroid surveys for both primary and secondary but I haven't recreated the problem yet. Is this affecting just one system or are the ships in different systems?

Steve

[Steve Walmsley]

The civie transport companies seem to think that a comet mining colony (automated mines only) out by the orbit of Pluto is a valid trade location - about 2/3 of the civie fleet just went on a wild goose chase out there....

That is weird. I assume the comet mining colony has no demand or supply for any trade goods? Any chance it is a huge comet that actually has a colony cost?

Steve

[IanD]

This may well be a feature, I was in the middle of a battle v Precursors, everything was going though not necessarily well. I have 21 FACs left but all enemy craft but one are damaged, when I issued an order to follow the target I got "Awaiting Acknowledgement" next to my FACs on the system display, at this point even FACs in the process of rescuing survivors also display this flag, and all my FACs just stay in place while the damaged precursor continues to move.

An explanation would be welcome

Regards

[Beersatron]

I have the 1st and 2nd Escort groups set to protect the battle group at 50k km each and at 20 degrees to anti/clockwise respectively. Unfortunately they just go speeding off to what looks like the direction of the local star! (no errors thrown)

If I give the 1st an order to escort the 2nd (which is now sitting still with no orders) then I get the following error:

Error in GetEscortLocation
Error 6 was generated by Aurora
Overflow

The battle group is 6 CVE with 10 fighters each, a possible factor?

These are the same fleets that I had set up in escort configuration in Sol but then the escort groups 'bounced' away from the exit gate when the battle group went through.

Could there be an entry in fleet order table that wasn't correctly removed/updated when that happened?