Eureka 1.11 released!

[andrewj]

Eureka is a map editor for DOOM, Freedoom, Heretic and now Hexen too.

I'm happy to announce that version 1.11 has been released.
See: http://eureka-editor.sourceforge.net

With this release I've tried to make editing generally easier and less error-prone. One example is the new drawing mode (when in vertex mode) which uses just the LMB to create new sectors off existing geometry. Another example is the new buttons in the sector panel for quickly setting the headroom to common values.

ChangeLog since 1.07:

Games and Ports:

+  Hexen support!
   (thanks to printz for doing some of the heavy lifting)

+  Boom generalized lines and sectors

+  treat Freedoom Phase 1 and Phase 2 as separate games

+  added Eternity port definition, thanks to printz

-  Heretic: categorized the textures and flats
-  changed default port from Boom --> Vanilla


Editing:

+  rendering of sector flats/lighting in the 2D window

+  easier vertex "drawing mode" using the LMB

+  when adding lines, automatically split crossed lines

-  inserting a vertex with SHIFT continues the drawing mode
-  inserting a vertex with CTRL inhibits creation of sectors

-  SHIFT + LMB in sectors mode always opens a selection box
-  better merging of linedefs when dragging a vertex
-  prevent overlapping lines when deleting 3rd vertex of a triangle

-  much less chance to accidentally drag an object
-  when a line splits a sector, use a consistent orientation
-  when creating a fresh map, add all four player starts
-  allow loading a map with no vertices, no linedefs (etc)


UI:

+  fixed texture warping in 3D preview

-  sector panel: buttons for quickly setting the headroom
-  sector panel: MMB on the ceiling flat sets it to sky
-  right-click on a sidedef or sector texture sets it to default
-  various layout tweaks to the editing panels

-  added "Recent Textures" command (etc) to Browser menu
-  fixed RECENT category to show most recent items at the top
-  status bar lets you see full message via a tooltip


Commands:

-  new "Last Selection" command, undo an accidental clearing
-  added /reverse flag for CopyProperties command
-  extended LIN_Flip command, avoid making lines with no right side


Map checking:

-  find "dangling" vertices
-  detect the Medusa Effect on 2S lines
-  detect transparent tex on solid walls

-  find manual doors on 1S lines
-  don't consider teleport things to be stuck in monsters
-  ability to SHOW unused vertices


Miscellaneous:

-  improved eureka.desktop file, courtesy Fabian Greffrath
-  have a fallback sprite for the MBF dog thing (id 888)
-  replaced "Aspect ratio" with "Pixel aspect ratio" in prefs
-  use absolute paths for resource filenames in __EUREKA lump

[Doomkid]

This is a great thing indeed! Glad Hexen support is there.

[Technician]

Finally! A Mac editor.

[Gez]

Technician said:

Finally! A Mac editor.

Technically SLADE 3 is a Mac editor too. You just need to find a compiled version somewhere (or compile it yourself).

[cybdmn]

There is an OSX version on the project page.

https://github.com/sirjuddington/SLADE/wiki/Downloads

[beast]

I used this version to build a Doom / Freedoom compatible map. This editor has an easy learning curve. Nice work @andrew

[scifista42]

I miss a possibility to set upper and lower textures to 1-sided linedefs for MBF sky transfers - would you add a possibility to set them at least on linedefs with action 271?

Also, with such a strictly controlled way of editing linedefs, why is it even possible to press the "DEL" button of a linedef's front side, creating unclosed sectors and nothing but problems?

While displaying floor textures (or ceiling textures or brightness levels) over the ground plan of the map, it seems that I can use either no grid or the dotty grid to display over it, but not normal grid - is it true?

[andrewj]

Thanks everyone!

scifista42 said:

I miss a possibility to set upper and lower textures to 1-sided linedefs for MBF sky transfers - would you add a possibility to set them at least on linedefs with action 271?

Yeah sounds like something is needed.

Also, with such a strictly controlled way of editing linedefs, why is it even possible to press the "DEL" button of a linedef's front side, creating unclosed sectors and nothing but problems?

I did considered removing them recently, but thought they may have some use for certain vanilla mapping tricks. Hmmm, perhaps hide them normally and have a preference to show them.

While displaying floor textures (or ceiling textures or brightness levels) over the ground plan of the map, it seems that I can use either no grid or the dotty grid to display over it, but not normal grid - is it true?

Yeah, it was not a clear-cut decision, but I found it convenient to be able to switch off the sector rendering via the 'H' key. Probably should have a preference for it.

[Fonze]

Sweet update for Eureka, Andrew!

Lotta really cool features added, from the looks of it :)

Quick question about the auto-stitching of the lines: is my assumption correct that that's a toggle-able thing?

Also, I think it's cool you added the ability to load maps without vertices; makes me think of that thread 40Oz made about making maps with stuff left out (like for this example all lines, so only things were placed) and mappers would fill in the rest of the template level. It'd be a cool idea for a CP, I think, and it's cool that you're making this thing more versatile, which will allow it to accomodate more user-needs.

TL;DR Great job with this update!

[scifista42]

andrewj said:

I did considered removing them recently, but thought they may have some use for certain vanilla mapping tricks.

Which particular vanilla mapping tricks depend on linedefs without front sidedefs? I have never heard of any.

[Gez]

scifista42 said:

I miss a possibility to set upper and lower textures to 1-sided linedefs for MBF sky transfers - would you add a possibility to set them at least on linedefs with action 271?

And 272! Don't forget the flipped version.

[VGA]

Fiddled around with it for a while, cool. Is there a way to select/change textures on the walls while in 3d mode? It shows the outline of the wall, but I can't select it or change it.

[andrewj]

Fonze said:

Quick question about the auto-stitching of the lines: is my assumption correct that that's a toggle-able thing?

Not quite sure what you mean, the "drawing mode" in Eureka is not the same as in DoomBuilder (though I don't use DB so I don't know exactly how it works there).

The auto-splitting of lines cannot be turned off, I'm not sure why you would want to turn it off and create criss-crossing lines, though it is still possible to drag an end-point of a line so that it crosses another one.

VGA said:

Fiddled around with it for a while, cool. Is there a way to select/change textures on the walls while in 3d mode?

Aligning textures is the only editing functionality that exists in 3D mode at the moment. I agree it would be really nice to have texture and flat setting feature for the 3D preview.

[scifista42]

scifista42 said:

Which particular vanilla mapping tricks depend on linedefs without front sidedefs? I have never heard of any.

I'm still curious about this. I've searched and found nothing. Is a linedef with no sidedefs omitted from rendering but still usable for collision detections or triggering special actions or something?

[Linguica]

scifista42 said:

I'm still curious about this. I've searched and found nothing. Is a linedef with no sidedefs omitted from rendering but still usable for collision detections or triggering special actions or something?

Without looking it up, I am pretty sure that's right. The Doom engine renders segs, and segs are tied to sidedefs, so a linedef with no sidedefs will be totally invisible. But the engine uses linedefs for collision calculations without caring about sidedefs or segs. See, e.g., https://www.doomworld.com/vb/post/1374173

[printz]

Linguica said:

Without looking it up, I am pretty sure that's right. The Doom engine renders segs, and segs are tied to sidedefs, so a linedef with no sidedefs will be totally invisible. But the engine uses linedefs for collision calculations without caring about sidedefs or segs. See, e.g., https://www.doomworld.com/vb/post/1374173

What?!? I thought all Doom games (save ZDoom maybe) crash if you forget the first sidedef of a line. They likely assume line->frontsector is non-null.

[Graf Zahl]

printz said:

What?!? I thought all Doom games (save ZDoom maybe) crash if you forget the first sidedef of a line. They likely assume line->frontsector is non-null.

Unless the missing sidedef isn't patched they'll indeed crash. I think Boom or MBF fixed it first, ZDoom only got the fix years later.

[scifista42]

Does anyone know a particular vanilla-compatible map made in the past (that is, not made after I asked here) that included such a "trick"?

[Linguica]

I figured I would actually try it, and it crashed Chocolate Doom. The specific error is in P_GroupLines, more specifically:

    // count number of lines in each sector
    li = lines;
    totallines = 0;
    for (i = 0; i < numlines; i++, li++)
    {
        totallines++;
        li->frontsector->linecount++;

        if (li->backsector && li->backsector != li->frontsector)
        {
            li->backsector->linecount++;
            totallines++;
        }
    }

And, of course, what's li->frontsector?

	if (ld->sidenum[0] != -1)
	    ld->frontsector = sides[ld->sidenum[0]].sector;
	else
	    ld->frontsector = 0;

So from a cursory inspection, it looks like the engine sets ld->frontsector to a pointer to the sector_t struct, but if there's no sidedef on the first side, it gets set to 0. Then in P_GroupLines it tries to increment the linecount member inside the sector_t struct, but doesn't know what to do with a null pointer, and bombs out.

Which makes me wonder: what happens in doom2.exe which is generally happy to stomp all over its own memory? Turns out a 0-sided linedef works fine! Or, at least, it doesn't crash and burn; god only knows what sort of data it's trying to increment, or if it's succeeding...

None of this has anything to do with Eureka, obviously, but whatever.

[andrewj]

scifista42 said:

Which particular vanilla mapping tricks depend on linedefs without front sidedefs? I have never heard of any.

My main point was that vanilla tricks often require doing "low level" operations on the map. And that is what those ADD and DEL buttons are -- low level operations that are not normally needed.

Clearly removing a front sidedef is always invalid, but a user may be doing it as part of a longer sequence of operations (e.g. adding a fresh sidedef, or flipping the linedef).

[scifista42]

andrewj said:

My main point was that vanilla tricks often require doing "low level" operations on the map.

Then why did you make it impossible to set upper/lower textures on 1-sided linedefs, or set a combination of Hidden/Shown/Secret linedef flags at the same time? Setting Shown+Secret flags at the same time can be actually useful, we already talked about actions 271 and 272 too (thanks, Gez), and it's not impossible that there might be other tricks utilizing these.

[andrewj]

scifista42 said:

Then why did you make it impossible to set upper/lower textures on 1-sided linedefs

I already agreed with you that something is needed for those rare cases where editing the upper/lower textures on 1-sided linedefs would be useful.

So I think you are just trolling now, arguing for the sake of arguing, and with no intent to be helpful.

[scifista42]

Sorry if that's how it appears. I want to be helpful, and so wanted to understand the reasons behind your design decisions. The restricted texture assigning and restricted linedef flag editing made me believe that your general approach is "high level", deliberately disallowing seemingly illogical operations for the sake of user's convenience and foolproof-ness. Your editor also makes it impossible to manually edit the "double sided" flag, or to have a linedef with just back sidedef but no front sidedef, which is in compliance with the abovementioned philosophy. But then you have allowed breaking the map by deleting front sidedefs of 1-sided linedefs, and you said that it was because you wanted to support "low level" operations. It surprised me a lot, and so I wanted to reassure what your philosophy behind designing this editor actually is.

I am personally of the opinion that the editor should allow the user to do anything that's possible in the map format. However, I admit that the "high level" enforcements will come in handy for most users for most of the time. Therefore I suggest that every such enforcement should be toggle-able from options menu. The editor could even remember these settings for each editing configuration individually.

Regarding the default enforcements themselves, I suggest to disallow deleting front sidedefs of linedefs, to add "Shown + Secret" flag setup for linedef's "Vis" group of flags, and what we already agreed on about the upper/lower textures on linedefs with action 271/272.

[Jon]

Thanks andrewj, I will have to give this a look.

I like Eureka and use it on a Mac, but I need to plug in a mouse to use it properly, too many operations need middle click which I can't conveniently do on just the trackpad. So no mapping on a train for me :) (No matter, I spent last year's train time on WadC and chocolate doom instead :))

[Graf Zahl]

scifista42 said:

Sorry if that's how it appears. I want to be helpful, and so wanted to understand the reasons behind your design decisions. The restricted texture assigning and restricted linedef flag editing made me believe that your general approach is "high level", deliberately disallowing seemingly illogical operations for the sake of user's convenience and foolproof-ness.

... which we all know, is not how many things in Doom are done...

Your editor also makes it impossible to manually edit the "double sided" flag, or to have a linedef with just back sidedef but no front sidedef, which is in compliance with the abovementioned philosophy. But then you have allowed breaking the map by deleting front sidedefs of 1-sided linedefs, and you said that it was because you wanted to support "low level" operations. It surprised me a lot, and so I wanted to reassure what your philosophy behind designing this editor actually is.

I have to admit that these restrictions seem a bit odd to me.
There's indeed legitimate cases where the upper and lower texture of a one-sided linedef may have some meaning, even outside 271/272. Legacy and ZDoom also have some linedef types where some non-textures can be entered here.

As for the two-sided linedef flag - unsetting this from a two-sided line will actually make a drastic change of how such a line behaves in the game - and there are maps which actually use this (if you want an example, check out heptic.wad from /idgames.)

On the other hand - deleting the first side of a linedef is always an error case, so allowing this but not the abovementioned legitimate cases is indeed a bit strange.

[andrewj]

(sorry that this response is a bit late)

A few issues here:

(1) the visibility flags. That decision is solely because I wanted Eureka to be usable on a 800x600 monitor, and the linedef panel was already very crowded and having a separate checkbox for those flags would have taken up too much room. (BTW I also wanted the sidedef sub-panels to be vertical, lower texture at the bottom and upper texture at the top). So that is why it is the way it is. I'm reluctant to increase the minimum usable resolution to 1024x768, but I consider the possibility. Having a "Secret+Mapped" choice is an easier possibility.

(2) Two-sided flag. I mainly did not show that because it crashes vanilla when it is wrong a certain way (set on a 1S line I think). The same space issue (in the UI) was another factor. It seemed to me something that most users would not want to worry about, and the special effect which can be done with it is almost useless (imho).

(3) upper/lower textures on 1S lines. The decision not to show them (or allow them to be edited) is mainly about not showing information to the user which is generally useless -- a kind of visual noise, and something that the documentation would need to explain too (that nothing happens if you change those textures).

Also there is a remapping of the order of the textures: the middle one for 1S lines is on the left (in the "lower" slot), so the real lower would be shown in the spot for the "rail" texture (if they were all shown). That is potentially very confusing for users when they are all shown. The reason for this remapping is because I found a pure one-to-one mapping quite painful to use when you selected multiple linedefs, some which are 1S and some which are 2S, it was so easy (and annoying) to accidentally set middle textures of 1S lines to a solid texture that you wanted to just place onto all the solid parts. Treating 1S walls as though it was a just one big lower solved that problem really nicely.

But I know something is needed for source port features that use uppers and lowers on 1S lines, still thinking about what to do (probably a preference to show them all).

[printz]

I cannot use Eureka to look at this map: https://www.doomworld.com/vb/eternity/85686-sky-transfer-bug/ to find some Eternity bugs, because:

1) I'm unable to highlight ultra-short linedefs (think of 1-sized triangle sectors)
2) I cannot find the linedef that triggers the current sector (other than seeing it highlighted on the map, which is not possible because the source line is too short in a huge map)
3) Since I can't see the upper and lower textures of sky transfers, I have difficulty addressing the EE bug here which IS related to sky transfers

[andrewj]

printz said:

1) I'm unable to highlight ultra-short linedefs (think of 1-sized triangle sectors)

I will look into it.

In future, please report bugs on the issue tracker on the SF project page.

2) I cannot find the linedef that triggers the current sector (other than seeing it highlighted on the map, which is not possible because the source line is too short in a huge map)

You can find lines with a particular tag with the Find/Replace panel, e.g. use "*" for the texture and un-hide the filters to enter a tag number.

[Giomancer]

Hurrah!

[beast]

I have made two maps with Eureka, used the find and replace yesterday and man was it a big help!