Eureka editor - mismatched sectors

[smeghammer]

Hi all, just (re)started playing with building WADs after - ooh, 20 years?. I only ever tinkered with it so I am not very good with the details...

 

I have started using Eureka editor on Ubuntu and have run a check/all on my level, and I am getting "4 mismatched sectors", error, and I have no idea what that means.

 

 

When I click on 'show' in the Check dialogue, the map shows these highlighted:

 

The map seems to play OK and I don't seem to be getting any weird HOM or other effects.

 

These sectors are the ones I first built, so it was possibly a copy-paste issue, and I have also noticed that copying and pasting a sector - particularly if it is attached to another one - will result in one of the linedefs still 'belonging' to the sector from which I copied it (i.e. when I select the source sector, one of the lindefs of the copied sector is also highlighted).

 

There did not appear to be any meaningful Google hits when I searched for  - e.g. - 'doom editor what does "mismatched sector" mean' (3 hits!), 'doom editor "mismatch" sector' (mostly standard Eureka readme/example pages).   

 

I'd greatly appreciate any tips here. Thanks in advance.

[Gez]

Looking at Eureka's source code, it seems that mismatched sectors are what's found by this function:

void Sectors_FindMismatches(selection_c& secs, selection_c& lines)
{
  //
  // Note from RQ:
  // This is a very simple idea, but it works! The first test (above)
  // checks that all Sectors are closed. But if a closed set of LineDefs
  // is moved out of a Sector and has all its "external" SideDefs pointing
  // to that Sector instead of the new one, then we need a second test.
  // That's why I check if the SideDefs facing each other are bound to
  // the same Sector.
  //
  // Other note from RQ:
  // Nowadays, what makes the power of a good editor is its automatic tests.
  // So, if you are writing another Doom editor, you will probably want
  // to do the same kind of tests in your program. Fine, but if you use
  // these ideas, don't forget to credit DEU... Just a reminder... :-)
  //
  secs.change_type(OBJ_SECTORS);
  lines.change_type(OBJ_LINEDEFS);
  if (NumLineDefs == 0 || NumSectors == 0)
  	return;
  FastOpposite_Begin();
  for (int n = 0 ; n < NumLineDefs ; n++)
  {
    const LineDef *L = LineDefs[n];
    if (L->right >= 0)
    {
      int s = OppositeSector(n, SIDE_RIGHT);
      if (s < 0 || L->Right()->sector != s)
      {
        secs.set(L->Right()->sector);
        lines.set(n);
      }
    }
    if (L->left >= 0)
    {
      int s = OppositeSector(n, SIDE_LEFT);
      if (s < 0 || L->Left()->sector != s)
      {
        secs.set(L->Left()->sector);
        lines.set(n);
      }
    }
  }
  FastOpposite_Finish();
}

It seems, if I understand what's happening in there, that it looks at what sector the line is facing (s = OppositeSector(n, SIDE_RIGHT or SIDE_LEFT), and checks whether that's the sector the line's side officially belongs to (L->Right() or Left()->sector). If they don't match, you get a mismatched sector error. So check the lines of the mismatched sectors one by one to find the ones that don't make sense.

[smeghammer]

Thanks @Gez.

 

That makes sense with what I see in the editor:

 

 

The sec: value

 

I did not realise what this meant  this before,  so I solved it by removing and then rebuilding the affected sectors rather than copy/paste. The problems have now gone away.

 

Thanks for looking into this.

 

 

Edited April 16, 2020 by smeghammer

[smeghammer]

Oooh! This looks like a bug in Eureka.

 

I replicated the situation, with @Gez comments above in mind.

 

On copying the connected sector, I did indeed see the connected linedef showing up with an incorrect sector ref:

 

 

This is on Check/ALL.

 

Sector on left is 203 and right (copied one) is 206

 

Now, the highlighted linedef on right has an incorrect sector reference, back to source neighbour sector 202:

 

 

From @Gez useful post above, I flipped the linedef and changed the sec: ref to 206. The tests still failed. It looks like the back sidedef flags (which is now not connected to anything) should be removed - but they are not and I don't see how to remove them in the UI.

 

 

 

Edited April 16, 2020 by smeghammer

[smeghammer]

I also just tried the same copy/paste of this sector in DB2 on Windows. The copied sector did not exhibit the same issue as it does in Eureka - the linedef did not have attributes for both sides and there did not seem to be any mismatched sector refs.. The copied sector has all single sided linedefs and there are no errors on testing. 

 

Here, the corresponding DB2 props for the same linedef:

 

 

I therefore definitely think it is a copy bug in Eureka.

 

Please consider this question resolved.