v5.56/v5.60 Official Bugs Thread

[Steve Walmsley (OP)]

So this means my engine-less picket stations will be unable to transit to the far side of a jump point on their own?  That will be a bit of a pain....

John

Ah true. Just thinking out loud here but do you think it would be better to require at least a minimal engine to be able to transit? Even a fighter engine would be enough.

Steve

[sloanjh]

Ah true. Just thinking out loud here but do you think it would be better to require at least a minimal engine to be able to transit? Even a fighter engine would be enough.

Up to you.  I've always thought of it in terms of the station-keeping drive nudges the station through the wormhole (that another ship/jumpgate opened), but one (you ) could easily change the technobabble to forbid that and require a "real" engine to transit.

The way I usually work it is to have 1000 ton jump scouts, and they hold open the wormhole for the picket station (carried in a larger tender) to transit.  So this rule change would force me (or not - see below) to only picket the far side of wormholes with engine-less stations when I have a big enough jump ship available to allow the tender to transit.

In reality, if you change the mechanics, what I would probably do is make a house rule that has the old behavior, then kludge it by using SM mode to change the location of the station to the other side of the wormhole.  In a past version, I can remember having to do this because I couldn't get the transits to work - it was a bit of a pain but not horrible.

So now that I've thought it through, I think from a game play point of view this falls into the same category as the "standard transits" - there's not a compelling reason to put the restriction in from a gameplay point of view (the limitiation was originally intended as a warning to keep people from doing things they didn't want to do, right?), and it causes a micro-management pain for people who want the old behavior as a house rule.

How about this:  Change your fix to be a pop-up warning, rather than forbidding it.  After all, engine-less ships have speed 1, not 0, right?  (I now remember a case where I had a picket cut-off in a system by an enemy fleet, and it started running away from the WP at speed 1 in hopes of getting out of sensor range by the time the WP was checked out by the bad guys - this was actually some fun role playing).  If you do want to put the restriction in, then I would make minimum speed 0 rather than 1 (except for the fact that then you'd get a ton of divide-by-zero bug reports due to places you'd missed ).

John

[Steve Walmsley (OP)]

Up to you.  I've always thought of it in terms of the station-keeping drive nudges the station through the wormhole (that another ship/jumpgate opened), but one (you ) could easily change the technobabble to forbid that and require a "real" engine to transit.

The way I usually work it is to have 1000 ton jump scouts, and they hold open the wormhole for the picket station (carried in a larger tender) to transit.  So this rule change would force me (or not - see below) to only picket the far side of wormholes with engine-less stations when I have a big enough jump ship available to allow the tender to transit.

In reality, if you change the mechanics, what I would probably do is make a house rule that has the old behavior, then kludge it by using SM mode to change the location of the station to the other side of the wormhole.  In a past version, I can remember having to do this because I couldn't get the transits to work - it was a bit of a pain but not horrible.

So now that I've thought it through, I think from a game play point of view this falls into the same category as the "standard transits" - there's not a compelling reason to put the restriction in from a gameplay point of view (the limitiation was originally intended as a warning to keep people from doing things they didn't want to do, right?), and it causes a micro-management pain for people who want the old behavior as a house rule.

How about this:  Change your fix to be a pop-up warning, rather than forbidding it.  After all, engine-less ships have speed 1, not 0, right?  (I now remember a case where I had a picket cut-off in a system by an enemy fleet, and it started running away from the WP at speed 1 in hopes of getting out of sensor range by the time the WP was checked out by the bad guys - this was actually some fun role playing).  If you do want to put the restriction in, then I would make minimum speed 0 rather than 1 (except for the fact that then you'd get a ton of divide-by-zero bug reports due to places you'd missed ).

A warning seems like a good compromise - I'll do that instead.

Steve

[MehMuffin]

The research option for 'Expand Civilian Economy by 20%' appears to expand beyond the allowed amounts of research points, generating a overflow error. Not really a problem, as this only happens after practically every other tech has been researched, but I thought I'd mention it here if it had any bearing on anything.

[Rijjka]

Well I tried a search to find this error, but I didn't have much in the way of luck.   

Anyway about once a year of in game time I get the following Error. 

Error in CreateGameLog
Error 429 was generated by Aurora
ActiveX Component can't create object.

This is then followed by

Error in CreateGameLog
Error 424 was generated by Aurora
Object Required. 

At that point I then need to click okay about 60-70 times before I can continue, as it keeps repeating the error.   After that it works fine for another year.   When I say it happens once a year, it's not right on the clock, this year it happened in march.   Usually it triggers closer to January.   But it seems to always be in the first quarter.   

[miauw62]

This happend twice to me, one time when i clicked refresh all in summar view, now when i clicked in tons on the class design screen. 
ERROR REPORTS MAY NOT BE EXACT. 
Some are threwn at me in dutch, because i (and my computer) am dutch. 

Code: [Select]

Error in cboClass_Click
Error 381 was gneerated by Aurora
Invalid property array indexthen

Code: [Select]

Error in PopulateLoadout
Error 3078 was generated by DAO.database
The Microsoft Jet-database-engine cant find the inputtabel or -query and m.MissileID = c.MissileID. Make sure that this exists and that the name is written correctlythen

Code: [Select]

Error in PopulateLoadout
Error 91 was generated by Aurora
Object variable or With block variable not set a few times
then it repeats or keeps giving me the 91, after i close all windows
it says this:

Code: [Select]

Error in UpdateGameLog
Error 3420 was generated by DAO.Database
Object invalid or not set anymore

Okay, the error in variates sometimes, im sorry. 
It happend when i clicked size in tons in the class design ship. 
is it a database error?
Sometimes it throws 'was generated by aruroa'
sometimes it gives 'was generated by dao.  database'
Also, after the first few repeats it says 'please create a new class before picking the type'

[TallTroll]

A survey ship in Sol with primary default orders "next 3 sys loc" and secondary default "Refuel in this system" completed the Sol grav survey. It got the "orders not possible" message, then "as per secondary orders, has been assigned following orders :" message. I think the orders are actually null though. I had to manually set a refuel, the "next orders" display on the system map shows [] (null contents), and switching next orders display in System Maps view  on / off seems to make no difference, the orders for all ships simply reappear in the next increment.

The actual error dialogue on turn process says "error 94 : invalid use of null" etc etc. Trying to view the task group in the Task Groups screen gives "error 94" again, followed by "error 381 : invalid property array index". The Group / ship has refueled and entered overhaul correctly though

[TallTroll]

OK, it hasn't entered overhaul correctly. The TG management screen lists the ship as in overhaul, with no orders of any kind (I cleared all default and conditional orders, nothing plotted) but the events screen reads "Survey Task Group cannot carry out movement orders as there are ships undergoing maintenance"

Hmm, maybe has entered overhaul then, but the null value is generating spurious "movement" requests. I've also just noticed that the TG still has a speed value displayed, despite being in overhaul. Yeah, I broke something

I can manually set TG speed from the TG Management screen, and it updates the System map. But it shouldn't have a speed...

[Nathan_]

Error 6 overflow, I've got a geo ship tg with 4 ships, capable of traveling at 17467 m/s and hyperdriving on top of that. In hypermode with speeds above 90,000, and time increments above 5 days I'll get several Error 6 overflows on orders, and several cycled order tgs, both colony ships and cargoships, will have their orders corrupted(can't unload X for whatever reason).  The Geo TG is in a fairly large system itself, obviously.

[Cocyte]

A new one on the same game. . . 

Several error 3001 every time I try to add an order to a task group, culminating with a 3003. . .  an a two-freakin'-gigabyte large DB now. . .

I guess it's time to start anew. . .

[Erik L]

A new one on the same game. . . 

Several error 3001 every time I try to add an order to a task group, culminating with a 3003. . .  an a two-freakin'-gigabyte large DB now. . .

I guess it's time to start anew. . .

Could always compact the database. There is a menu command for it.

[Lav]

Could always compact the database.  There is a menu command for it.

Does using that option crash Aurora for anyone else? Doesn't matter if I use it on a clean install or an active one.
"Error 429 was generated by Aurora    ActiveX Component can't create object"
"Error 3420 was generated by DAO. Database   Object in valid or no longer set. "

The last error repeats ad nauseum. 

[Cocyte]

Could always compact the database.  There is a menu command for it.

Thank you once again, compacting the thing reduced it to a "mere" 100 Mb, and the game seems to work for now

[sublight]

5.60
Event Stutter: I have no clue what is causing it, but in one game every time a task force completes orders I receive a dozen or more copies of the "order complete" notification in the event log. That happens for every order completion notice of every task force for all player races. I might be wrong, but every year it feels like there are more redundant notifications.

More information on the Event Stutter: it appears to be caused by running through multiple construction cycles with minimal increment autoturns. At the least, using min-incriments=3, 5-day auto-turns will reliably reproduce the problem on my system. Problem disappears if I restart Aurora and play without changing the min-incriment value away from the default 0.

[Bgreman]

Here's an interesting little display bug:

On the System Map menu, if you add some waypoints, then choose to hide waypoint locations on the Display tab, then close and reopen the system map, the waypoint list tab will be empty, even though the waypoints still exist.  If you re-enable 'show waypoints' on the Display tab, the waypoint list tab is refilled and stays even if you redisable the option.