Author Topic: Weird Bug Story  (Read 1694 times)

0 Members and 1 Guest are viewing this topic.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11661
  • Thanked: 20384 times
Weird Bug Story
« on: July 21, 2020, 10:02:21 AM »
I have encountered a bug where if you design turret tech with economics and create research windows open and use a custom name the turret tech can be saved as the create research tech type with the create research cost but the edited turret design name.         

Steps to recreate.     
  • Open economics window.     
  • Open create research project window and select something other than an EW project, note research cost.     
  • Open turret design, design a turret, edit the name note research cost (ensure it is different from the step 2 project) and create.     
  • Look in research to see which field the turret was created in and check research cost.     

I have also had a related problem with missile designs giving an error, which I didnt understand enough to reproduce, so I removed my report and bided my time but on further testing it is real and I can now reproduce it and describe it below the turret design bug report because it occurs under similar conditions.         

Turret Design.         
Today my turret saved as a beam fire control in sensors because I had just created a beam fire control project and still had the window open.          Having been alerted by the first missile error episode I took care to check the turret bug was not my mistake and tried to reproduce it.         

It is reproducible - see screenshot "layout bug. jpg".          By typing in a new name or editing the default name for the turret with this layout of windows, I was always able to save the turret as a fire control.          You can see the research required for the turrets with custom name in the sensors window (turrets should go to energy weapons) is exactly the same research as that required for the BFC.         

For accuracy at the time this happened I had 5 windows open i.         e.          the strategic map, research/economics tab, create research BFC, ship class design, turret design window.          I left the create research BFC window open after creating a BFC, then I opened create turret and typed in my own name for it and saved it only to find it was saved as a (shockingly expensive) sensor!

I tested and found I didnt need the ship class design window open for this bug to happen but both the create research and the economics window needed to be open.         

I checked summary and industry tabs of economics and found the bug also happened, so it is not research tab specifically but any economics tab.         

The create research BFC window did not need to be on top for the bug to happen.         

I also tested active sensors and cloak design in design research e.         g.          when cloak design was open the turret was saved to the Defensive Systems research list as if it was a cloak, with the same research points as the cloak I had designed but not created and the custom name of the turret.         

If I created the turret using the default name and did not select the turret name text field at all, the bug did not happen.         

On closing the create research window the bug no longer happened and I was able to create a turret with an edited name correctly to EW research with the correct research point requirement for the turret even with the economics window open.          Likewise after closing the economics window I could create a custom named turret correctly with the create design window open.         

Hope that helps :) if there is anything else I can do to help report this bug better, please say.         

Spike:This is a nicely detailed report.  I was unable to reproduce the turret design error, so there must be some other critical detail.  If anyone can figure it out, please report it. NVM found it.

The missile design error is confirmed.


I've just spent two hours tracking this down and that was only possible due to the very detailed report above. Sharing as this wins the weirdest bug of 2020 so far :)

There is a Tech System Object called CurrentTechSystem, which is used for whichever project is being worked on. During design, this object and the associated component object (component is the item, tech system is the project) are maintained so that a simple 'Create' command will add the existing objects to the dictionary collections that contain all components and tech systems for the game. For easy reference, the component object has a pointer to the associated tech system object, which during design is also the current tech system object.

Somehow, the Current Tech System object and the Turret Tech System object had different values, which was impossible because they were the same object. At first I thought there was some weird local vs higher level variable assignment as I couldn't see any other way the old values would return after the new (turret) values were set. However, I confirmed the code was addressing the same object throughout. They were definitely being set because I stepped through every line in debug mode.

Finally, I realised I didn't need to know what was happening. I would just set the CurrentTechSystem to null as soon as I opened the Turret window. I stepped through and it was definitely null. The turret tech system object was created with the right values. However, somehow the current tech system object was resetting to the beam fire control after that point, even though I couldn't see any assignment code and all the values had being wiped (and it is the current tech object that the game adds to the main collection).

At this point, I was suspecting demonic intervention.

Next, I wondered if somehow the beam fire control code was being triggered in the background. The weird thing was that this bug only happened if I changed the name of the turret and there was no code behind the text box, so that couldn't be triggering any events. In a moment of inspiration, I realised it would trigger a repaint. So I added a breakpoint to the design beam fire control code and it turned out that code ran when I changed the turret name. After chasing that code back to its triggering point, I found an activation event in the Create Projects window. Activations events happen when a form receives focus but I don't remember adding it and have never used that event before, so I obviously mis-clicked somewhere at some point in the past. To make it worse, the single line of code in that event reran the design code for whatever project type was selected.

However, that still didn't explain why a repaint event gave that control focus and triggered the activation event, especially as there was no repaint event code for that form. Then I realised that the Tactical Map did have repaint code. What's more, when the Tactical Map repaints, it will bring other forms to the front if the Keep Tactical in Background option is checked, giving them all focus during that process. I unchecked that display option on the Tactical Map and the bug in the turret window went away :)

So what was happening was that changing the text of the turret name triggered a repaint event for the tactical map, which in turn brought the Create Project temporarily to the front, which in turn gave it focus, which in turn triggered the Activation Event, which in turn reran the Beam Fire Control design, which in turn created a new Current Tech System object, which was no longer the same one I already assigned to the Turret component object, which is why the two objects actually weren't the same and why the wrong tech system object was tied to the new Turret design - phew!

So I deleted the activation event and everything works fine now :)

Offline skoormit

  • Commodore
  • **********
  • Posts: 779
  • Thanked: 312 times
Re: Weird Bug Story
« Reply #1 on: July 21, 2020, 12:12:45 PM »
That is an absolutely delicious bug.

It reminds me of the good times I've had hunting down bugs related to lazy-loading properties.
As in:
"The null error happens on this line. I run the code, it gets to this line, and throws the error. But if I pause on this line and examine the variable that is throwing the error, the value is not null. If I then resume, the error does not occur! It's only null if we don't stop and look at it!"
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Weird Bug Story
« Reply #2 on: July 22, 2020, 08:23:10 AM »
That is an absolutely delicious bug.

It reminds me of the good times I've had hunting down bugs related to lazy-loading properties.
As in:
"The null error happens on this line. I run the code, it gets to this line, and throws the error. But if I pause on this line and examine the variable that is throwing the error, the value is not null. If I then resume, the error does not occur! It's only null if we don't stop and look at it!"

I love Schrödinger bugs!  (And spell-correct was useful for once and gave me the umlaut!! :) )

John