Official v5.02 Bugs Thread

[praguepride]

Wow, got hit with a HUGE NPR error spam. Going on 10 minutes of holding down the enter key to bypass. Figured I'd just start listing the errors here in case it matters:

Error in UpdateAllSensors (91)
-Object variable or With block variable not set
-For loop not initialized

Error in UpdateAllSensors (92)
-For loop not initialized


Error in UpdateAllSensors (424)
-Object Required

Error in UpdateGameEvents (424)
-Object Required

This cycle repeats for things like:
SelectNPRTarget
NPRCombatSetup
NPRChanceToHit
MaxMissileRange


I'm guessing some kind of interrupt or break needs to be put into the code so that one tiny error doesn't cause everything afterwards to fail.

[The Shadow]

I've changed the starting NPRs to a random system number.

Thanks!

Another way that putting the player race at 1 is a bit odd: galaxy growth.  If you start with 1000 systems, then you'll probably have a cluster near your home system that's sitting at 999.  If you later bump the galaxy size up to 10000 (due to things getting crowded), then you'll wind up with a big set of fresh territory that's right next to your core systems.  This will be a very subtle effect, though, since the new systems will probably only be able to come back to the old through undiscovered JP.

Huh, I didn't think of that.  Of course, I've been finding it a little odd that a fully-surveyed system can end up having new jump points later... but I don't really see any way around it.  (Is this what the game means by "dormant" jump points?)

Galaxy growth is a little "unrealistic" in any case, so I think we can live with a few oddities.

[Beersatron]

I've changed the starting NPRs to a random system number.

Thanks!

Another way that putting the player race at 1 is a bit odd: galaxy growth.  If you start with 1000 systems, then you'll probably have a cluster near your home system that's sitting at 999.  If you later bump the galaxy size up to 10000 (due to things getting crowded), then you'll wind up with a big set of fresh territory that's right next to your core systems.  This will be a very subtle effect, though, since the new systems will probably only be able to come back to the old through undiscovered JP.

Huh, I didn't think of that.  Of course, I've been finding it a little odd that a fully-surveyed system can end up having new jump points later... but I don't really see any way around it.  (Is this what the game means by "dormant" jump points?)

Galaxy growth is a little "unrealistic" in any case, so I think we can live with a few oddities.

Think of Closed Warp Points in Starfire, they can only be detected on the other side of them. Adds a bit of spice to things

[sandman662]

Sorry to post this here....

I tried to send Steve a PM, but the message is in my outbox and I can't figure out how to "send" it.  I have gotten stuck on a 60 second incremental time increase and in SM mode it says that the time was adjusted because a ship is in range to fire.  This has been going on for over a day now.  I know that it must be an NPR that is doing this, but for some reason, the "issue" is not being resolved.  I guess I need the developer's password so that I can see where the issue is and fix it.  I am having a fun game (23 years in) and REALLY want to continue it.

Thanks for any help!

[sloanjh]

Sorry to post this here....

I tried to send Steve a PM, but the message is in my outbox and I can't figure out how to "send" it.  I have gotten stuck on a 60 second incremental time increase and in SM mode it says that the time was adjusted because a ship is in range to fire.  This has been going on for over a day now.  I know that it must be an NPR that is doing this, but for some reason, the "issue" is not being resolved.  I guess I need the developer's password so that I can see where the issue is and fix it.  I am having a fun game (23 years in) and REALLY want to continue it.

Thanks for any help!

If it's in your outbox, then that means that it's sent and he just hasn't read it yet (he's been mostly away for the last month or so).

You're probably not going to be able to fix the issue, no matter what passwords you have - it is almost certainly something in the NPR AI.  All you would be able to do is see what's going on and delete the fleets that are in action.  The procedure for getting it fixed is to save your DB (there's a FAQ thread on this) so you can send it to Steve when he asks for it.  (You can find his e-mail by searching on the boards for the way to generate it.  Please do NOT post his e-mail to the boards - he wants to avoid spambots.)  Note that this will only be for extreme cases where it's pretty obvious that the AI is somehow hung - I think this one qualifies.  If Aurora slows down, even to 5 second intervals, for a few hours of game time time then it's probably just working through a battle and not a bug.

On passwords - Steve has requested that noone give out passwords besides himself.  The reason for this is that the passwords give access to the ability to put the DB into a state that the executable won't understand, and which he'll have a horrible time figuring out if someone logs a resulting problem as a bug.

John

[sandman662]

Ok.  Thanks for your reply, John.  I'll do as you say.

[Andrew]

Ok.  Thanks for your reply, John.  I'll do as you say.

this may be a bug so save a copy of your database.
I just 'fixed' the same problem in my game, I ended up Ctrl-alt-deleteing to exit the game when it was autorunning through 1 minute increments. When I restarted the game it started doing large increments again .
However I did not save the database

[UnLimiTeD]

Had a long discussion in the academy around this;
You can pack a pretty much unlimited amount of ECM on a missile to make it unhitable and deny the enemy any kind of AM defense capability.
While at lower levels this isn't a problem, at ECM 5 you just need 3.5 MSP to make your missiles impervious to an equal tech level enemy.
Seeing how that still leaves you with enough space on a size 10 missile to pack a reasonable warhead and enough fuel to reach targets at high ranges, I think this is unintended.
At maximum tech level, a Size 10 missile with 2 sizes ECM (thats -200% range/accuracy) can pack a good 90 points WH and still rather reliably hit targets moving at 100k on a distance of 200m, as shown in this example:

Code: [Select]

Missile Size: 10 MSP  (0.5 HS)     Warhead: 90    Armour: 0     Manoeuvre Rating: 83
Speed: 103800 km/s    Endurance: 32 minutes   Range: 200.0m km
ECM Level: 20
Cost Per Missile: 51.625
Chance to Hit: 1k km/s 8615.4%   3k km/s 2822%   5k km/s 1723.1%   10k km/s 861.5%
Materials Required:    10x Corbomite   22.5x Tritanium   35.176x Gallicite   Fuel x2778.5
This could be fixed by multiplying ECM by 4 and divinding it through missile size, as I posted in the suggestions a while back, or by hardcapping it.
(or you could allow ECCM stacking, though I think that results in people getting several cheap instead of one good one...)

Regards

[Steve Walmsley (OP)]

Had a long discussion in the academy around this;
You can pack a pretty much unlimited amount of ECM on a missile to make it unhitable and deny the enemy any kind of AM defense capability.
While at lower levels this isn't a problem, at ECM 5 you just need 3.5 MSP to make your missiles impervious to an equal tech level enemy.
Seeing how that still leaves you with enough space on a size 10 missile to pack a reasonable warhead and enough fuel to reach targets at high ranges, I think this is unintended.
At maximum tech level, a Size 10 missile with 2 sizes ECM (thats -200% range/accuracy) can pack a good 90 points WH and still rather reliably hit targets moving at 100k on a distance of 200m, as shown in this example:

Code: [Select]

Missile Size: 10 MSP  (0.5 HS)     Warhead: 90    Armour: 0     Manoeuvre Rating: 83
Speed: 103800 km/s    Endurance: 32 minutes   Range: 200.0m km
ECM Level: 20
Cost Per Missile: 51.625
Chance to Hit: 1k km/s 8615.4%   3k km/s 2822%   5k km/s 1723.1%   10k km/s 861.5%
Materials Required:    10x Corbomite   22.5x Tritanium   35.176x Gallicite   Fuel x2778.5
This could be fixed by multiplying ECM by 4 and divinding it through missile size, as I posted in the suggestions a while back, or by hardcapping it.
(or you could allow ECCM stacking, though I think that results in people getting several cheap instead of one good one...)

Regards

I have added a 1 MSP cap to Missile ECM, which I should have done in the first place. In v5.1 it works exactly as it does now except for the 1 MSP cap. This means that if you have the technology for Missile ECM Level 3, you missile is never going to have more than ECM 3 (and can therefore be countered by an equal tech opponent) but it can still have less if there is insufficient space for a whole MSP.

Steve

[Steve Walmsley (OP)]

Sorry to post this here....

I tried to send Steve a PM, but the message is in my outbox and I can't figure out how to "send" it.  I have gotten stuck on a 60 second incremental time increase and in SM mode it says that the time was adjusted because a ship is in range to fire.  This has been going on for over a day now.  I know that it must be an NPR that is doing this, but for some reason, the "issue" is not being resolved.  I guess I need the developer's password so that I can see where the issue is and fix it.  I am having a fun game (23 years in) and REALLY want to continue it.

Thanks for any help!

I have the message now and you should see my reply in your Inbox

Steve

[Steve Walmsley (OP)]

Error in ApplyMaintenanceFailure
Error 91 was generated by Aurora
Object variable or With block not set

I made a ship with no engines and 15 hangers and allowed it to sit around for a year or so out of orbit. After awhile the error above was generated and my large immobile ship had a catastrophic maintenance failure: it exploded. I tried this again and put some sensors on it; 10 size .1 EM sensors to be exact. The same error and result occurred. This was a brand new testing ground game.

I've found the bug. It looks like there is a logic error in the code that executes when you get a maintenance failure and there are no spares available. If the code happens to pick a random system that doesn't suffer maintenance failures, such as cargo holds or hangars, it is supposed to pick a different system. What is actually happening, as far as I can tell, is that If the code happens to pick a system that doesn't suffer maintenance failures, the ship blows up! Oops!

There aren't many systems that don't suffer failures, which explains why this bug has been around for so long. There have been reports of ships blowing up due to a catastrophic maintenance failure in the past but I assumed they had just lost all their systems first. Thanks for the bug report and the extra detail that made me look more closely. It's fixed for v5.1.

Steve

[Steve Walmsley (OP)]

Code: [Select]

Damage Per Shot (4): 9     Rate of Fire: 5 seconds     Range Modifier: 7
Max Range 630,000 km     Railgun Size: 10 HS    Railgun HTK: 5
Power Requirement: 27    Power Recharge per 5 Secs: 25
Got a Railgun (max techlevel, still testing) that requires 27 energy, gets only 25, still fires every 5 seconds.

Comming from here:
http://aurora.pentarch.org/viewtopic.php?f=19&p=23714#p23714

Fixed for v5.1. The code that rounds up to the next five seconds wasn't handling a base ROF greater than 5 seconds but less than 6 seconds. Also was affecting high tech level Mesons, Lasers, Carronades and Torpedoes.

Steve

[Steve Walmsley (OP)]

This bug has been mentioned before, so this is just a friendly reminder/letting you know it has happened to others.

Steve

[Steve Walmsley (OP)]

Wow, got hit with a HUGE NPR error spam. Going on 10 minutes of holding down the enter key to bypass. Figured I'd just start listing the errors here in case it matters:

Error in UpdateAllSensors (91)
-Object variable or With block variable not set
-For loop not initialized

Error in UpdateAllSensors (92)
-For loop not initialized


Error in UpdateAllSensors (424)
-Object Required

Error in UpdateGameEvents (424)
-Object Required

This cycle repeats for things like:
SelectNPRTarget
NPRCombatSetup
NPRChanceToHit
MaxMissileRange


I'm guessing some kind of interrupt or break needs to be put into the code so that one tiny error doesn't cause everything afterwards to fail.

Most of the error handling in Aurora uses "On Error Resume Next" so that one minor error doesn't halt the program. The downside of that is the occasional error spam if things go seriously off the rails. I haven't see that sequence of errors before but something is obviously missing. If you have a saved DB could you send it to me so I can take a look? I have to ask the obvious question when something weird happens and the program can't find somethin, which is have you opened the database at all and modified it directly? I assume not but I like to check

Steve

[Steve Walmsley (OP)]

Found a bug: ticking the Commercial Only box when designing a ship class hides the Maintenance Storage Bay, which is a non-military component.

The Maintenance Storage Bay IS a military component. Now you have got me paranoid . Is there something somewhere else in the program that suggests it isn't a military component or were you just assuming it wasn't?

Steve