Eureka DOOM Editor version 0.72 available for testing

Eureka is a DOOM map editor for Linux, and after doing a lot of work on it in the past few months version 0.72 is now available for people to try out.

I want to point out that this is not an official release of any kind, and I still consider this "alpha" quality software and I recommend not trusting it with any of your precious wads.

LINK: http://awwports.sourceforge.net/files/eureka-0.72.tar.gz

The package includes a compiled binary, however this might not work on your flavor of Linux and you may need to compile it yourself. An important change is that FLTK 1.3.0 is now required to compile (instead of FLTK 1.1.x as before).

Comments, criticisms, bugs (etc) are very welcome.


Change Log

++ the File menu is fully operational (albeit a bit clunky)

++ browser for textures, flats, thing types (etc)

++ can scale/rotate stuff with middle mouse button


+ use SPACE key for insert function

+ grid snapping works again ('f' key to toggle)

+ quantization function ('q' key) which grid-snaps objects

+ disconnect function ('d' key) in vertex and linedef modes

+ automatic sector insertion when closing a line loop
+ automatic sector splitting when a line crosses a sector

+ the -iwad option works again


- split linedefs by just inserting a vertex on a highlighted line
- merge two linedefs by just deleting the vertex in-between

- select linedef path function ('e' key)
- correct sector function ('c' key)
- new sectors get default flats/textures/etc

- invert selection function (CTRL-I or Edit menu)
- draw the camera on the map (a pink arrow)
- move camera function (' key) and goto camera (END key)

I'm struggling to get this to do much that's useful. Is there a method to create double-sided linedefs etc. at the moment? Also, creating funny-shaped sectors using vertices mode seems unreliable in that Eureka won't necessarily detect that the loop has closed, even when I know it has (pressing ctrl-z and then manually selecting and rejoining the vertices seems to work reliably but it isn't efficient...). Automatic linedef merging would be nice as well (I tried to put a couple of sectors next to each other to make a door but it refused to work properly).
Also, a button to toggle automatic linedef creation in vertices mode would be heaps good.

Chances are pretty good that I just suck but perhaps a tutorial would be a good idea?

Oh, but seriously, thanks for producing a proper native Linux doom map editor.

Excelent, I will try it out.

Lance MDR Rocket said:

I'm struggling to get this to do much that's useful. Is there a method to create double-sided linedefs etc. at the moment?

Do you mean a linedef with the same sector on both sides?Hmmmm for that there is no good way to do it, but this works:

(1) in vertex mode, draw a line inside the sector from one edge, but ending in the middle
(2) drag the end vertex to the other edge to close the two spaces
(3) go to sectors mode and press 'c' in each space to "correct" the sector (the sector needs to become highlighted in yellow)

Also, creating funny-shaped sectors using vertices mode seems unreliable in that Eureka won't necessarily detect that the loop has closed, even when I know it has

The one failure case I'm aware of is when creating a loop on the outside of an "island" (something lying completely inside another sector, like the pillars in MAP01 of DOOM2).

Is that the same problem? If not, please try to reproduce the problem in a known map like MAP01 of DOOM2, or even a fresh map, and tell me the steps to reproduce it.

Note that pressing SPACE in Sectors mode will insert a new sector into a closed loop (where the pointer is), and the 'c' correction function does a similar thing but fixes the currently highlighted sector. This should be easier than reconnecting vertices.

Automatic merging of linedefs would be nice to have -- added to the WISHLIST.

Thanks Lance MDR Rocket for trying out Eureka, soon I will create a web page for it and later on I'll write some user documentation (once the workflow has become stable and everything has settled down).

Also, creating funny-shaped sectors using vertices mode seems unreliable in that Eureka won't necessarily detect that the loop has closed, even when I know it has

Alright, after some wrangling I managed to reproduce this consistently.
It seems to have to do with your aim - the closer your mouse pointer is to the grid point where the vertex is going to be created, the more chance there is of the loop closing properly - obv. I'm using snap-to-grid mode here. I've made a couple of comparison shots (scrot didn't capture the mouse pointer so I had to approximate it's position with pinta):





This seems to hold true whether you're creating sectors in empty space or inside other sectors.

Hope this helps!

(oh and yeah I can do the double sided linedef thing consistently now, thanks; I just wasn't paying attention. It would be nice to be able to toggle which sidedefs any given line has in some way, though)

EDIT: another feature request: when using sectors mode to create new sectors, could you please make it so the sector created is equivalent to the grid size rather than 64x64 all the time? Not a high priority but it would save a bit of time.

Lance MDR Rocket said:

Alright, after some wrangling I managed to reproduce this consistently.
It seems to have to do with your aim - the closer your mouse pointer is to the grid point where the vertex is going to be created, the more chance there is of the loop closing properly - obv. I'm using snap-to-grid mode here. I've made a couple of comparison shots (scrot didn't capture the mouse pointer so I had to approximate it's position with pinta):

Thanks very much Lance MDR Rocket, I really appreciate you taking the time to demonstrate this problem.

I understand what is wrong now and will fix it A.S.A.P.

A way to directly control the sidedefs is a good idea, perhaps an "Add" button appears in the right-hand panel when there is no sidedef, and when there is a sidedef then a "Delete" (or "X") button appears instead.

another feature request: when using sectors mode to create new sectors, could you please make it so the sector created is equivalent to the grid size rather than 64x64 all the time?

Sure, that'll only take a minute or two.

OK first of all, I'm very impressed with how stable this is, especially for an alpha. I've only had one crash so far and I've been unable to reproduce it (I suspect it had to do with either the editor sitting idle for a long time or me opening and closing new maps repeatedly - probably a combination of both. I'll let you know if it happens again).
Anyway despite my complaining I like this program (especially the nice bare bones 3d mode) and I've started trying to make a proper level with it so I'll keep you updated.

On that note, I do have a couple more gripes:

More loop closing woes. In some circumstances there's no way to make a closed loop in vertices mode:




Not quite sure why that would be?

In others it's very difficult as you need to do things in a specific order (numbers and arrows indicate the order vertices were created/selected in):

This doesn't work:


This does:


(I don't know if this is your problem or not but) Eternity (3.4.20) didn't like one of the test wads I made - 'Error: couldn't open doom20'. The defective level worked fine in PrBoom and ZDoom though.
When I made some minor changes to the level and resaved it that fixed the problem, so go figure. Unfortunately I didn't save the broken wad but if it happens again I'll be sure to upload it for you if you want.

This is a minor point but rendering a lot of grid points (eg. grid = 2 map units and then zooming out) all at once is heaps slow.

And some user interface suggestions:

A merge sectors mode please. Reducing architecture like this:



back down to one sector involves manual editing of sidedefs, which is a pain. Merged sectors are also v. useful for stuff like teleport traps etc.

Being able to flip linedef facing would be heaps useful as well. As it is you're kind of at the mercy of the program if you want to make teleport traps and things like that.

Raise/lower floor/ceilings keybindings should be []/,.= +/- 8 px, {}/<> = +/- 16 px etc. (as opposed to just +/- 16 px for everything).

Menu option to invoke a nodebuilder of the user's choice (perhaps defined in config file, eg. nodebuilder="zdbsp -o $f" where $f is the filename of the currently open map). This isn't really a big problem, but just as a convenience thing, you know.

Config file entry to set default mode to either free-floating or snap-to-grid. I prefer STG and always forget to change it when I start the program so that would be a godsend really.

Faster mouse wheel scrolling in browser window please (config file variable again?).

That's all (for now).

Those loop closing woes look like the known failure case I mentioned, when extending onto an island sitting inside another sector. The one where doing the vertices in a different order is odd though -- I will look into that one.

I don't know exactly why grid 2 can be so slow, I guess it is just the number of grid lines it has to draw. The only way to "fix" that would be to just stop drawing the grid when zoomed out so far that it becomes excessive -- controllable by a config item I guess.

For merging sectors, the "c" correct sector function is what you want here, delete the line and press "c" in the new space (in SECTORS mode) to fix all the sidedefs.

The "w" key will flip linedefs.

How far the + and - buttons in the panel and the keyboard equivalents ([ ] { } etc) move a floor or lighting (or whatever) are going to be configurable (ideally in a preferences window, but that is a real wish-list feature at the moment). Making the default snapping configurable is a good idea too.

BTW, I found the cause of the crash you mentioned, and it was indeed related to file loading and saving.

I have downloaded it now and will use it to help me make proof of concept doomsday addons.

Cheers for this program andrewj, keep up the good work

http://www.securitronlinux.com/files/eureka.png

This program looks very good indeed. I can not work out how to convert a solid pillar into a two sided sector, but this program is working very well now indeed. Keep up the good work.

#EDIT, the SPACE key to insert sectors sounds like the right thing, I was not sure about that. I am using this editor to work on my Doom2 project and it is very fast too.

Nice!

There will be another version soon. A handy new feature is: Eureka remembers various editor state (map location, grid settings, etc) when you save a map and these are restored the next time you load that map.

neubejiita said:

I can not work out how to convert a solid pillar into a two sided sector

If you mean adding a sector to the inside area, that should just be a matter of going into sectors mode and pressing SPACE in that area.

Or do you mean something else?

Version 0.74 of Eureka is now available:

http://awwports.sourceforge.net/files/eureka-0.74.tar.gz


CHANGES IN 0.74 (since 0.72)

+ show the current WAD and map in the window title bar.

+ clipboard persists when changing maps (without quitting), so you can copy-n-paste from one map/wad to another map/wad.

+ various user state (grid settings, camera, editing mode, etc..) persists when a map is saved, and is restored when the same map is loaded again.

+ improved SECTOR insertion:
(a) copy properties from a selected sector, or try a neighboring sector if no selection. Use default value as last resort.
(b) if CTRL is pressed, then new area BECOMES the same sector as the one selected.

+ new 'Sort' setting in Thing/Line/Sector type browsers.

+ new 'ADD' and 'DEL' sidedef buttons in the LineDef panel.

+ new -port option to select the source port. Defaults to boom. Other values currently supported are: vanilla, edge.

- fixed problem where you could seemingly close a line loop, but due to grid snapping the vertex was merely placed on top of the existing one and it did not actually close the loop.

- fixed bug where closing a line-loop around an existing shape did not apply the new sector to the outside of that shape.

- new outside-of-map sectors now occupy a single grid square.

- File/New does not ask for map slot unless there's a current PWAD, since that will be asked on the File/Save (== File/Export).

- File/Export asks for the map slot _after_ the filename.

- dynamic rotating (CTRL + middle button) no longer scales.

- dragging/scaling/rotating vertices will draw the lines too.

- fixed display of a certain flat (CEIL4_1 IIRC) which was showing bright cyan in parts that should be black (palette color #247).

- better looking About box.

Just had a peek, but a great editor so far. :)
Please continue!

Bastet Furry said:

Please continue!

I will surely get back to it (when not so busy with other projects), and hopefully improve the workflow which is still very cumbersome for certain tasks.

If you feel like saying, which language/libraries/etc did you use, out of curiosity. I probably gave up on a failed python & omgifol mess. I had 2 goals, neither were successful:
1)make random computer generated maps by starting with an area which just starts as 1 sector, draw a path through it to subdivide into 2 sectors, repeat n times. Now randomly paste/connect multiple areas together, making sure you can walk between them. One idea was to think of texturing in terms of setting a sector's OUTER sidedefs to the same texture and auto aligning the texture's x axis from an arbitrary start point.
2)make it so you can copy paste a complicated area right on top of a different complicated area, and it'll all 'fuse' together automatically. Doing this you could possibly work on floors-only, then paste onto a ceilings-only area, without needing them to 'match' or something.
Whatever, it didn't work and now I've been thinking about learning plain ansi c instead of python. Maybe I'll try more later but really need to focus on getting money now, if there's any ways left without a million monopoly roadblocks and licenses in front of them. Hopefully, if I ever succeed in that, I can come back and try without the internet and computers themselves being illegal by then. I don't have linux right now.

Eureka is written completely in C++. I have toyed with the idea of adding Lua (which is a neat programming language) support to it and implement most commands in Lua scripts -- seems a bit overkill though.

OBLIGE can take a complicated floor and merge it with a complicated ceiling, or have prefabs which intersect or overlap each other. That's because OBLIGE uses a brush-based representation of the map (a lot like Quake, but not as powerful). OBLIGE already uses Lua for its scripting and data files (game definitions, prefabs, etc). As a platform for experimenting with random map generation, OBLIGE can be awesome, unfortunately there is no documentation for that stuff, as everything has been in constant flux.

Speaking of Lua... Is Eureka going to have such things as macros (scripts)?

printz said:

Speaking of Lua... Is Eureka going to have such things as macros (scripts)?

I imagine two aspects:

One would be an ability to /bind a key to a function name, and that Lua function would be called when you press the key. For example: /bind w rotate_thing_left
The code would need to be loaded already.

Secondly: an ability to open a window, type in some Lua code (can load or save it) and the code would be executed. For example, you might write a little script to find all STARTAN3 textures and change them to STARGR1 and vice versa.

It always pays to ask coders stuff. 'Brush based' led me here:
https://en.wikipedia.org/wiki/File:Quake_Vertex_Pruning_Preprocessor.PNG
and here:
https://en.wikipedia.org/wiki/Constructive_solid_geometry
which are quite interesting concepts I've never thought about before.

Someone make an editor I can use with my ASUS EEEpad (Tf101 - Transformer)