Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • 0
smeghammer

Eureka editor - mismatched sectors

Question

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.

 

1214854973_Screenshotfrom2020-04-1417-22-28.png.d13240ca8306f5c10a6dbb06c060b8f7.png

 

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

654187841_Screenshotfrom2020-04-1417-11-30.png.8af715f0235d26f30523de2112f85065.png

 

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.

Share this post


Link to post

4 answers to this question

Recommended Posts

  • 0

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.

Share this post


Link to post
  • 0
Posted (edited)

Thanks @Gez.

 

That makes sense with what I see in the editor:

 

image.png.16a8e2feaa8e905d8bd5a1b8c5549ba0.png

 

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 by smeghammer

Share this post


Link to post
  • 0
Posted (edited)

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:

 

2118764474_Screenshotfrom2020-04-1619-49-13.png.8782b6ca3d4741f3218a28dda33afdf2.png

 

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:

 

507716651_Screenshotfrom2020-04-1620-00-49.png.ee6a3efcd81847f44b1a34c9ce2acd98.png

 

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 by smeghammer

Share this post


Link to post
  • 0

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:

 

image.png.9798b80f32b77cee13803e8a94438f75.png

 

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

 

Please consider this question resolved.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×