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

Eureka 1.27 released

Recommended Posts

yay! congrats! and i hope you'll find some time and inspiration to finish UDMF support eventually. this is prolly the last missing bit for Eureka to be The Editor for me. ;-)

Share this post


Link to post

That's great news! I'm glad you were able to regain your interest in the further development of Eureka.

 

I'm personally not troubled by not having UDMF support, but I recognize that is the last big limitation (in my opinion) of it as an editor.

 

Admittedly, I haven't checked out the new  yet, but I did review the changelog on the website. You've made a lot of changes, and they all sound like they will be great additions.

 

My only suggestions for features to add (for the next version):

  • The ability to use pk3's (like Supercharge) as a resource in addition to wads.
  • Recognizing the sky transfer tag (Type 271) when the map type is Boom. It currently shows up as "Unknown." Yes, sky transfers are an MBF feature, but the common usage of "Boom maps" appears to include sky transfer.
Edited by Pegleg : Type 271 not 272.

Share this post


Link to post
6 hours ago, Pegleg said:

The ability to use pk3's (like Supercharge) as a resource in addition to wads.

Yeah, that is currently the first item in the TODO doc.  I really think that PK3 support is necessary to make UDMF worthwhile.

 

6 hours ago, Pegleg said:

Yes, sky transfers are an MBF feature, but the common usage of "Boom maps" appears to include sky transfer.

I agree that these linetypes are generally considered part of the "Boom compatible" standard.  For now you can set the port to "mbf" to get them (or a more advanced source port).

Share this post


Link to post

Huge thanks goes to @printz for building the MacOS package for Eureka 1.27.  It can be downloaded from the Eureka website (see original post for the link).

 

EDIT: I jumped the gun on this, there is a fairly minor fix still in the pipeline for the MacOS package, so I suggest waiting for that.

Edited by andrewj

Share this post


Link to post
On samedi 8 février 2020 at 4:40 AM, andrewj said:

I agree that these linetypes are generally considered part of the "Boom compatible" standard.  For now you can set the port to "mbf" to get them (or a more advanced source port).

For SLADE I was originally envisioning an MBF configuration but given how it'd basically just be "#include boom.cfg: the config" I settled on just adding "MBF sky transfer" and "MBF helper dog" to the Boom config, prominently labelled as MBF extensions this way.

Share this post


Link to post

I'm glad that this project hasn't been discontinued, after all.  The various Doom Builder offshoots are great tools, but not very GNU/Linux friendly.

Share this post


Link to post

I love Eureka. It's very comfortable to use. The preview feature is also much quicker than in Slade as it throws you directly into the game without having to cycle through the menus. 3D mode is very smooth, too. Definitely needs UDMF/ACS support though, but otherwise great.

 

Oh BTW, I did notice one bug that I find very annoying... wondering if I'm the only one... but when I'm in vertices mode, drawing lines, very often it'll stop working... ie it will place the vertices but the lines in between don't get drawn. I have to save and re-open the map for it to start working again... thankfully that's quick and painless to do, but it's still infuriating as it happens A LOT, sometimes within a few seconds of re-opening the map... I haven't managed to find a pattern for this though (at one point I thought it was switching grid size that created the issue, but I'm not so sure anymore).

 

Share this post


Link to post
10 hours ago, Andreas said:

Oh BTW, I did notice one bug that I find very annoying... wondering if I'm the only one... but when I'm in vertices mode, drawing lines, very often it'll stop working... ie it will place the vertices but the lines in between don't get drawn. I have to save and re-open the map for it to start working again...

Hmmm that is really strange, not something I have ever seen.

 

What operating system do you use?

 

If you can try the latest version, 1.27, that may fix the problem since Eureka now uses OpenGL to draw the map and the 3D view.

Share this post


Link to post
8 hours ago, andrewj said:

Hmmm that is really strange, not something I have ever seen.

 

What operating system do you use?

 

If you can try the latest version, 1.27, that may fix the problem since Eureka now uses OpenGL to draw the map and the 3D view.

 

I'm running Mageia with KDE desktop.

 

# uname -a
Linux unicorn 5.4.2-desktop-1.mga7 #1 SMP Thu Dec 5 17:40:00 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

 

Share this post


Link to post

@andrewj

@printz

 

I've been using the Mac build of Eureka 1.27 since February 20. First, I would like to say that I love what you've done with the program. The editor is great, especially working in 3D mode. I like the additions you've made to it.

 

I've been having a problem with 3D mode, though. I was hoping it was just a memory problem on my end, but it hasn't gone away.

 

I can work in 2D mode, including all the different rendering modes. I can go into 3D mode fine. I can work in 3D mode fine. The problem comes when I switch out of 3D mode; the program just closes without warning. I can't say when it will happen, because it doesn't happen every time. It doesn't seem to ever happen while switching into 3D mode, only when switching out of 3D mode back to 2D mode. It has happened enough that I now save before exiting 3D mode, just in case it crashes.

 

I am running Mac OS X 10.13.6. When it crashes, the report generated reads:

 

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

 

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000 (the address is sometimes different from this value)
Exception Note:        EXC_CORPSE_NOTIFY

 

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

 

Has anyone else using Eureka 1.27 natively on a Mac have this issue? There were other intermittent errors on v. 1.24, but never this one. Was this something that was addressed by a new build that was fixed (and I just downloaded it too early)? Or is there something else going on?

Share this post


Link to post

During 1.27 development I had a report of a crash bug that would occur occasionally.  I ran as many tests as I could, but never could trigger it myself.  That was on Windows.  It is possible yours is the same thing, but seeing that you can trigger it quite often, it is equally possible to be a Mac-specific bug.  The way that the graphical toolkit (FLTK) handles OpenGL on retina displays is a bit odd and I needed to workaround an issue there, so it might be related to that.

 

So unfortunately I don't know what is causing your crashes, if I could reproduce it here then I would gladly fix it.

Share this post


Link to post

@Pegleg Is that the entire crash log? You can see by starting the "Console" application and going to the "application exits" (or aborts or however it's called) and you'll find this app crash. It would be great if you can post here or by PM to me the entire crash log. I'll also start editing a map to see if it happens to me too.

 

But beware that I'm using macOS 10.15, not 10.13 (and depending on what software you use, you may not want to upgrade). I can't tell whether your problem wasn't fixed in the meantime by the system update...

 

I'm a bit puzzled that so-called "Retina" displays are still a problem. I thought by now that scaled displays are commonplace. Does FLTK have the same problem on scaled Windows 10 displays? Or Gnome/KDE/etc.

Share this post


Link to post

I believe Retina displays are difficult to handle due to Apple's API for them (sounds to me like that got it quite wrong, more confusing that it should've been, even SDL had issues with it).

 

Anyway, here is the issue I started on FLTK's github mirror about this:

https://github.com/fltk/fltk/issues/57

 

You probably should double check my workaround, it may not be needed anymore with the latest FLTK, or it might be doing the wrong thing.

Share this post


Link to post
4 hours ago, printz said:

@Pegleg Is that the entire crash log? You can see by starting the "Console" application and going to the "application exits" (or aborts or however it's called) and you'll find this app crash. It would be great if you can post here or by PM to me the entire crash log. I'll also start editing a map to see if it happens to me too.

 

But beware that I'm using macOS 10.15, not 10.13 (and depending on what software you use, you may not want to upgrade). I can't tell whether your problem wasn't fixed in the meantime by the system update...

 

I'll PM you the most recent crash log.

 

The last time I tried to update from 10.13.6, there was a conflict between something (software or hardware) that caused the update the fail part of the way through and render the computer unusable. I've been loathe to try updating again for that reason.

Share this post


Link to post

Somewhat unrelated, but I have been working on my own fork of an old version of Oblige.

 

That code has the ability to output wads as a text file instead of as a binary .wad; I use this ability to run tests against the code.  I run tests like: If I remove this code, are all of the megawads made with a given seed and parameters the same as before?  If I change this code to affect deathmatch play, and remove all of the multiplayer-only items, are the maps the same?  If I change the number of monsters in a map, are all of the non-things (lifedefs, sectors, etc.) the same?

 

Thinking out loud, since Andrew has mentioned UDMF format, and since UDMF is a text format, it should not be too hard to add UDMF support to this old version of Oblige; I just have to change how the text looks and update the tests to test against a UDMF map. This way, the text wad support can be useful for more than just running automated tests.

Share this post


Link to post

The copy-paste logic is apparently missing some checks, and this leads it to creating mismatched sectors. See thread:

 

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
×