Author Topic: Official v5.50 Bugs Thread  (Read 86114 times)

0 Members and 1 Guest are viewing this topic.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11713
  • Thanked: 20616 times
Re: Official v5.50 Bugs Thread
« Reply #420 on: November 07, 2011, 03:06:57 PM »
My point still stands. If the design is to NOT autocreate a TG when a new item is created then orbital habitats, PDCs, warships, and (first) fighters are all bugged. Because as it stands now the game does automatically create them in certain circumstances (such as first build).
If that is not the design, then the bug is reversed and follow-up fighters should be put into a new auto-made TG just like OHs are.
You cannot seriously be arguing that it is WAD to work both ways just depending on the vessel and whether it is the first or a followup build. It should be one or the other, whether holding the players hand or not.

As for auto-creating being an exception and not a rule, I am curious what version your are playing, for the life of me I cannot seem to find a single other situation like this to lend any credence to your point.

Well, newly built ships would be one :)

Quote
EDIT: Ah, and now I see Steve's post. Thanks for backing me up Steve, sounds like you respect logic better than Charlie Beeler ;)

I think Charlie was responding to the sarcasm in your post. That type of thing generally doesn't go down well on these forums :)

With respect to Charlie, he is correct that this is working as intended. In 99% of cases this isn't a problem, as a lot of people play the game and this issue comes up very rarely. That's why I haven't bothered adding a check in the past. However, I agree that to cover the 1% I should add an additional check to make sure the TG that has been assigned by the player (or for the 1st time only by the program) hasn't been subsequently deleted without the player specifying a new destination TG.

Steve
« Last Edit: November 07, 2011, 03:30:23 PM by Steve Walmsley »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11713
  • Thanked: 20616 times
Re: Official v5.50 Bugs Thread
« Reply #421 on: November 07, 2011, 03:26:25 PM »
I have added a check for newly created fighters to ensure that if the specified "New Fighters" TG does not exist, a new "New Fighters" TG is created for that planet

I have also added a similar check for newly built ships, so that if the task group that was specified when they were laid down no longer exists, a new TG comprising just that ship will be created. The TG will have the same name as the new ship.

Steve
 

Offline IanD

  • Registered
  • Commodore
  • **********
  • Posts: 725
  • Thanked: 20 times
Re: Official v5.50 Bugs Thread
« Reply #422 on: November 08, 2011, 10:19:24 AM »
On the completion of a successful ground assault on an alien population the colony of the attacker and the conquered population no longer merge in v5.54.
IanD
 

Offline toxiciron

  • Able Ordinary Rate
  • t
  • Posts: 4
Re: Official v5.50 Bugs Thread
« Reply #423 on: November 08, 2011, 05:16:50 PM »
Opening several windows results in an error:

Error 713 was generated by Aurora
Class not registered.
You need the following file to be installed on your machine.  MSSTDFMT. DLL

I thought I installed it correctly, but the options during installation were very confusing and I'm not sure what I did.
ex - (You have version 2.  Installing version 1.  Keep the new file?) Which one's new, the one that would be newly installed or the version that is newer?
 

Offline blue emu

  • Commander
  • *********
  • b
  • Posts: 344
  • Thanked: 2 times
Re: Official v5.50 Bugs Thread
« Reply #424 on: November 08, 2011, 08:38:28 PM »
The "surrender bug" still exists in v5.53... defeat of an enemy colony causes random surrenders in star systems so far away that I don't even know which direction they lie in.

I haven't tried v5.54 yet.
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5658
  • Thanked: 376 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Official v5.50 Bugs Thread
« Reply #425 on: November 08, 2011, 09:27:35 PM »
Opening several windows results in an error:

Error 713 was generated by Aurora
Class not registered.
You need the following file to be installed on your machine.  MSSTDFMT. DLL

I thought I installed it correctly, but the options during installation were very confusing and I'm not sure what I did.
ex - (You have version 2.  Installing version 1.  Keep the new file?) Which one's new, the one that would be newly installed or the version that is newer?

http://aurora2.pentarch.org/index.php/topic,2031.0.html Second post.
 

Offline toxiciron

  • Able Ordinary Rate
  • t
  • Posts: 4
Re: Official v5.50 Bugs Thread
« Reply #426 on: November 09, 2011, 05:29:06 PM »
Quote from: Erik Luken link=topic=3895. msg42862#msg42862 date=1320809255
hxxp: aurora2. pentarch. org/index. php/topic,2031. 0. html Second post.

I've reviewed the installation and I did do it correctly, so that isn't a problem, but I visited the link and the fix links are broken.
 

Offline Beersatron

  • Gold Supporter
  • Rear Admiral
  • *****
  • Posts: 996
  • Thanked: 7 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
Re: Official v5.50 Bugs Thread
« Reply #427 on: November 09, 2011, 08:01:16 PM »
I've reviewed the installation and I did do it correctly, so that isn't a problem, but I visited the link and the fix links are broken.

http://aurora2.pentarch.org/index.php/topic,1715.msg21036.html#msg21036
 

Offline Owen Quillion

  • Chief Petty Officer
  • ***
  • O
  • Posts: 41
  • Thanked: 3 times
Re: Official v5.50 Bugs Thread
« Reply #428 on: November 11, 2011, 05:25:00 AM »
Quote from: Steve Walmsley link=topic=3895. msg42771#msg42771 date=1320701185
I have added a check for newly created fighters to ensure that if the specified "New Fighters" TG does not exist, a new "New Fighters" TG is created for that planet

I have also added a similar check for newly built ships, so that if the task group that was specified when they were laid down no longer exists, a new TG comprising just that ship will be created.  The TG will have the same name as the new ship.

Steve

This exchange reminds me of a similar issue I first ran into in 5. 52 or 5. 53, and just reproduced in 5. 54.  It took me a bit to realize exactly what was happening, but it's obscure enough I realize why I'd completely forgotten about it until just now. 

I'm not too great at mental math (and was unaware that there's a box in the Task Group screen that tells you total tonnage of that TG), and as my doctrine relies on mixed FAC-sized forces, I was making heavy use of the 'Land on Mothership' commands for groups of FACs.  As it turns out, if you use this with a task group whose tonnage exceeds that of the bays, the event log throws an error that reads "Unable to Land - [ship name] cannot dock as the assigned or specified mothership does not have sufficient hangar space. " for each ship that can't fit and then "Loading Problem - [Task Group Name] failed to land on [Carrier Name].  Any additional orders will be on hold until the problem is resolved". 

The problem here is [Task Group Name] has already been deleted, and the named ships blink out of existence - disappearing from the Individual Unit List and everything.  Not only do you lose the ship, but valuable crew grade and task force training.

On a lighter note, it's worth noting that if the bays are already full, the game just doesn't care - you wind up with completely different space-warping properties.  While trying to replicate the issue, I managed to stuff two FAC wings and a full loadout of dropships (total tonnage being three times the mothership's hangar capacity). 

---

There's a second, unrelated bug I've run into - Error in GetMaxPotentialSensorRange, Error 6 Overflow.  Searching only got one hit for it, which was an unreplied to report of it in this topic. 

To give it some context (spoilered as it involves some specifics of the swarm;

A geological survey vessel noticed a wreck disappearing in a system that, when probed, hadn't appeared to have any activity in it.  Indeed, it seemed the Swarm had set up operations on a moon on the other side of the system, or at least had created an 800 ton wreck there in addition to the one that had disappeared (which I only knew about because of the event log).  The survey vessel fled the system with no issues.  A month later, my combat fleet jumps in and I immediately got the above error, which repeated every turn. 

I haven't fought the Swarm much, so I don't know if this is unusual, but the typical 800 ton meson-spitting gunboats were given a different designation than the group I'd fought before in another system.  I don't know if this is normal or not; however, the Tactical Intel window completely lacked information on my previous group, though it had data for workers and the queen.  After mopping up the gunboats, I encountered what I assume to be the source of the error; a queen (also a different designation, if it matters) from whom I never detected any EM emissions (which was odd as the previously encountered queen had a sensor I detected from over a billion kilometers away and whose shields I'm almost positive I detected well before closing to missile range).

The error quit after the queen was destroyed by a massive salvo, so I assume she was the source of the issue.
 

Offline Goron

  • Chief Petty Officer
  • ***
  • G
  • Posts: 37
Re: Official v5.50 Bugs Thread
« Reply #429 on: November 11, 2011, 04:13:24 PM »
If you create a ship with 100 ordnance capacity, fill it, then refit that ship to a design with less capacity, such as 50, it will retain the ordnance on board and go over 100% ammo.
I did not test what happens if you attempt to actually USE any of that ammo.
 

Offline TheDeadlyShoe

  • Vice Admiral
  • **********
  • Posts: 1264
  • Thanked: 58 times
  • Dance Commander
Re: Official v5.50 Bugs Thread
« Reply #430 on: November 11, 2011, 07:09:54 PM »
If you shut down fuel refineries, their sorium consumption still shows up in the predicted usage panel/ produces a red highlight.



 

Offline metalax

  • Commander
  • *********
  • m
  • Posts: 356
  • Thanked: 4 times
Re: Official v5.50 Bugs Thread
« Reply #431 on: November 12, 2011, 12:52:36 AM »
If you shut down fuel refineries, their sorium consumption still shows up in the predicted usage panel/ produces a red highlight.

Further to this, on the industry tab, if fuel production is shut down the annual fuel production displayed(not actual production) stays at it's normal value instead of saying 0 or shut down. While this may not neccessarily be a bug as it is showing the capacity of the current refineries, it is confusing on whether fuel is being produced or not when looking through large numbers of colonies.
 

Offline AnthonyT

  • Leading Rate
  • *
  • A
  • Posts: 10
Re: Official v5.50 Bugs Thread
« Reply #432 on: November 12, 2011, 01:40:51 AM »
"Cycle moves" is a frequent cause of freezing the game for me. 

I know to be careful with it, but I often forget when a ship has "cycle moves" ticked.   If I clear orders and assign it something like "move to earth" without toggling that.  .  .   I'll be reminded very quickly as my computer fans rev up and the game doesn't come back. 

I'm sure this must have been reported, but couldn't find it.   Sorry if it's a dupe. 

A suggested interface behavior: when clicking "delete all" in task group orders, clear "cycle moves" too.   In general, it would be nice to catch or be robust against all sources of tight, infinite update-loops.  .  .   but I imagine that's no easy task! However, this little interface change would prevent "cycle moves" from being a scary option for me.   Mind you, I'm not sure if I ever had a corrupted database from this one.  .  .   every time I'm certain a freeze was due to this I've been able to reload the database fine and clear the darn flag! :)

Thanks!

Edit (sorry): this is version 5. 54!
« Last Edit: November 12, 2011, 01:42:48 AM by AnthonyT »
 

Offline TheDeadlyShoe

  • Vice Admiral
  • **********
  • Posts: 1264
  • Thanked: 58 times
  • Dance Commander
Re: Official v5.50 Bugs Thread
« Reply #433 on: November 12, 2011, 04:12:05 AM »
That's curious. In my game it just spams the "X taskgroup has completed orders" report if i have a single order on cycle.
 

Offline ZimRathbone

  • Captain
  • **********
  • Posts: 408
  • Thanked: 30 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2023 Supporter 2023 Supporter : Donate for 2023
Damage Control issues
« Reply #434 on: November 12, 2011, 06:50:33 AM »
I was reminded of this by a post in the Academy:

If you use DC to repair a ship it will take a few days to completely repair most combat damage - if the same ship is repaired using shipyard facilities then it takes a number of weeks to fix up a similar level of damage.  Now I know that the DC repairs cost more in terms of Maintenance supplies, but I dont think this covers the magnitude of the savings in time, esp since the Maint Supplies only cost 0.125 x Duranium, 0.0625 Uridium & 0.0625 Gallicite each,  and the SY repairs use the minerals required to build the damaged component. There appears to be no point in using SY repairs for anything other than Armour.

This brought up a bug:  if you repair all internal damage using DC, the ship then does not appear in the Ships Requiring Repair screen, even tho it still has outstanding armour damage (which cannot be repaired by DC)  I suspect that this is because armour is not a "damaged component" and damage there is recorded in a seperate table that provides that nice armour status screen.   The query behind the Damaged Ships report needs to ammended to include this table.
Slàinte,

Mike