New release of Eternity Engine

Quasar has released a new version of the Eternity Engine. The new version, v3.40.37 (codenamed "Gungnir"), includes various new features, including better support for the Doom 3: BFG Edition IWADs, DynaBSPs, linked portals, better gamepad support, more stable MIDI code and a new linedef special system. A gallery showing some of the new features can be seen here.

"monsters now able to see and aim through linked portals"

Welp. I'm sold.

Yes, I love that monsters can now interact like normal through linked portals! That's a pretty huge feature on top of the already awesome portal system :D

Now I just gotta make some maps that use it :P

Holy shit!

It's worth noting that linked portals are still in development, though this is definitely a good step. :)

SoM, the main portals guy, has been swamped with schoolwork for a while now and intends to get back to get back to work on the portal clipping system soon. Hopefully we'll be seeing more progress in that direction in the near future!

Does this mean we can look forward to an update to Vaporware? :P

Average said:

Does this mean we can look forward to an update to Vaporware? :P

Essel has said not until the clipping is functional :<

Doom 2 BFG edition?!

Is adding a new custom title pic the right way to handle the lack of one in the BFG Edition?

Congrats on the release! Eternity has been my engine for everyday playing of late, so good to see new updates. :)

How's progress on Strife in Eternity going these days? I'm in the early stages of a new project, and I'm curious if Eternity support would be in its time frame.

Khorus said:

Congrats on the release! Eternity has been my engine for everyday playing of late, so good to see new updates. :)

How's progress on Strife in Eternity going these days? I'm in the early stages of a new project, and I'm curious if Eternity support would be in its time frame.

I intend to make a mighty effort to finally polish off Heretic support in the next version - that entails creating the full EDF inventory and weapon systems.

That'll obviously lay most of the ground work needed to proceed further with both Strife and Hexen. One additional thing Strife needs is a functional hub system, though.

I'd say at this point it's probably two versions out. I'd love to give you a time estimate but EE dev sometimes goes very fast (dynabsps added in two days) and sometimes very slow (gamepad HAL took 3 months to finish) so it can be unpredictable. Depends on many factors.

Vermil said:

Is adding a new custom title pic the right way to handle the lack of one in the BFG Edition?

Doesn't interfere with mods, looks kinda cool, and is better than just showing DMENUPIC or INTERPIC, IMO. Plus it gives it a distinguishing factor when you have both it and the normal DOOM II IWAD. It's more a question to me of "why not do it?".

Quasar said:

I intend to make a mighty effort to finally polish off Heretic support in the next version - that entails creating the full EDF inventory and weapon systems.

That'll obviously lay most of the ground work needed to proceed further with both Strife and Hexen. One additional thing Strife needs is a functional hub system, though.

I'd say at this point it's probably two versions out. I'd love to give you a time estimate but EE dev sometimes goes very fast (dynabsps added in two days) and sometimes very slow (gamepad HAL took 3 months to finish) so it can be unpredictable. Depends on many factors.

Good to hear, thanks! I completely understand that working method. ;)

Does Ladna have plans to work on ClientServer anytime soon, or is that project on hold?

I quite like Eternity, although the version I have doesn't seem to be able to play fullscreen. The more updates, the better. I'd rank it as second place for sourceports, after GZDoom (which wins because of its amazingly userfriendly startup. I cant get Eternity or anything other than Doomsday to load up anything but Doom 2..)

Ragnor said:

I quite like Eternity, although the version I have doesn't seem to be able to play fullscreen. The more updates, the better. I'd rank it as second place for sourceports, after GZDoom (which wins because of its amazingly userfriendly startup. I cant get Eternity or anything other than Doomsday to load up anything but Doom 2..)

If you set your "Favorite screen size" on the video options menu to fullscreen, the available modes in the video mode pick lists will change to ????x???f instead of ????x???w, which means fullscreen. Have you tried that?

It's also possible to manually set a fullscreen video mode, by going straight to where it says video mode, hitting enter, and typing in a "geom string" manually, such as 1680x1050f. Be sure to include the f. EE always defaults to windowed unless it's told explicitly to use fullscreen, due just to the number of people who have problems with things that run in fullscreen.

Ragnor said:

I quite like Eternity, although the version I have doesn't seem to be able to play fullscreen. The more updates, the better. I'd rank it as second place for sourceports, after GZDoom (which wins because of its amazingly userfriendly startup. I cant get Eternity or anything other than Doomsday to load up anything but Doom 2..)

If you set your IWAD paths in system.cfg and enable the IWAD picker (also in system.cfg), you'll get something similar to GZDoom's startup menu. It'd definitely be nice if they could be automatically added to the list if they're in the same folder with EE or something :)

esselfortium said:

If you set your IWAD paths in system.cfg and enable the IWAD picker (also in system.cfg), you'll get something similar to GZDoom's startup menu. It'd definitely be nice if they could be automatically added to the list if they're in the same folder with EE or something :)

They ARE automatically added if they're in the same folder, as of the newest release.

I've never been any good with command lines or paths or so on, so I use (G)ZDoom where it simply reads all the IWADs in the folder its in, or Doomsday where it asks you where each IWAD is during the install. I threw the IWADs in the same folder as EE expecting it to work.

As for the fullscreen thing, whether the option is unchecked or not, or whatever the resolution was set to, it was always the same size windowed box. I'll upgrade versions and hopefully it'll be fixed.

Sorry for the trouble Quasar and Essel!

Eternity 3.40.37 can automatically find IWADs in the following locations the first time it runs:

• Current working directory
  
• Executable directory
  
• On Linux only: /usr/local/share/games/doom ; /usr/share/games/doom
  
• All subdirectories of the basepath
  
• All subdirectories of the userpath
  
• DOOMWADDIR environment variable
  
• HOME environment variable
  
• All directories listed in the DOOMWADPATH environment variable
  
• Default DOS installer locations on the root of the same volume Eternity is running from
  
• (All of the following are Windows only, and not in ConSiGno's builds)
  
• Steam Install Paths (Ultimate Doom, Doom2, Final Doom, Master Levels, Heretic, and DOOM 3 BFG Edition)
  
• Collector's Edition Installation Path
  
• The Depths of Doom Trilogy Installation Path
  
• Final Doom for Windows 95 Installation Path
  
• Shareware Doom for Windows 95 Installation Path
  

If No Rest for the Living exists under the DOOM 3 BFG install path, that path will also be automatically configured.

If you keep your IWADs somewhere else you are out of luck. You'll need to go into /user/system.cfg and set the IWAD selector paths yourself - or configure them from the WAD OPTIONS menu.

Oh cool, it detects Steam paths. I rebought them on Steam entirely for the Master Levels, never had a reason to install the others.

Ragnor said:As for the fullscreen thing, whether the option is unchecked or not, or whatever the resolution was set to, it was always the same size windowed box. I'll upgrade versions and hopefully it'll be fixed.

There is also a `` -fullscreen " switch you can add via the command line that works for me.

One minor issue that I didn't think warranted a separate thread - when I run this in windows from executable in my Program Files directory, settings (key bindings, mouselook etc) don't get saved on exit. I get

Warning: could not write defaults to <path>/user/tmpetern.cfg: Permission denied
<path>/user/doom/eternity.cfg left unchanged
Warning: could not write defaults to <path>/user/tmpetern.cfg: Permission denied
<path>/user/system.cfg left unchanged

It works fine if I instead run it from anywhere else (like from the Documents directory). So there's a simple fix but it seems a bit buggy. I figure it's to do with write permissions but I didn't have this problem with ZDoom.

Other than that it's great, the portal enhancements are impressive. Cheers.

Mesprylum said:

One minor issue that I didn't think warranted a separate thread - when I run this in windows from executable in my Program Files directory, settings (key bindings, mouselook etc) don't get saved on exit. I get It works fine if I instead run it from anywhere else (like from the Documents directory).

Blame Microsoft, which decided that programs can never write to any files in "Program Files".

Fixing this means creating an installer (e.g. with NSIS) which sets up some registry keys, and updaring your code to determine the install folder and config folder based on those registry keys -- it can be a lot of work.

andrewj said:

Blame Microsoft, which decided that programs can never write to any files in "Program Files".

Fixing this means creating an installer (e.g. with NSIS) which sets up some registry keys, and updaring your code to determine the install folder and config folder based on those registry keys -- it can be a lot of work.

Normally, shouldn't it be writing to AppData\Local's VirtualStore and map those paths to the \Program Files\whatever folder transparently for the program?

As a general rule, do not copy anything to 'Program Files' yourself! I run any software that doesn't come with an installer from a separate folder that doesn't have any kind of 'protection'.

This goes for all Doom source ports in particular.

printz said:

Normally, shouldn't it be writing to AppData\Local's VirtualStore and map those paths to the \Program Files\whatever folder transparently for the program?

Not sure what you mean by "VirtualStore" -- is that a Windows 7 thing?

In Eureka, I use SHGetFolderPath() with CSIDL_APPDATA to get the base path for application-specific data. This will work on XP and later (AFAIK), not sure about 95/98/ME.

To determine the installation path, where the game definitions files are (etc), I rely on the installer to set a registry key and query that key during startup.

The days of being able to download a program, unpack it and run it seem to be over (Microsoft are making it harder and harder, e.g. read-only 'Program Files' and by default skipping EXE files when you unpack a zip).

andrewj said:

The days of being able to download a program, unpack it and run it seem to be over (Microsoft are making it harder and harder, e.g. read-only 'Program Files' and by default skipping EXE files when you unpack a zip).

Strange. I have seen more and more 'portable' versions of applications being offered recently.

I never had any such problems and choose a portable version whenever some software offers one.

So, 1) don't put such portable versions in 'Program Files' to begin with. That folder is protected for good reasons and 2) don't use Microsoft tools to unpack Zips. They are made for the computer illiterate public that needs to be protected from its own stupidity.

Unless I'm an admin of a shared PC, I usually put portable programs within my user folder.

andrewj said:

Not sure what you mean by "VirtualStore" -- is that a Windows 7 thing?

Windows Vista and up save files that would otherwise go into \Windows or \Program Files\<name> into a hidden subfolder of AppData (Local IIRC) called VirtualStore. The program thinks it's saving and loading from Program Files or Windows, but in fact the operations are mapped to VirtualStore's subfolders. Oddly enough, I saw exceptions to this rule. An example is Starcraft 1, which stores game saves and custom scenarios within its Program Files subfolder, no VirtualStore mapping.

In Eureka, I use SHGetFolderPath() with CSIDL_APPDATA to get the base path for application-specific data. This will work on XP and later (AFAIK), not sure about 95/98/ME.

I wonder: is the APPDATA (and LOCALAPPDATA and maybe others) environment variable safe to use on all Windowses, instead of calling an API function said to be deprecated in Vista and up?

The days of being able to download a program, unpack it and run it seem to be over (Microsoft are making it harder and harder, e.g. read-only 'Program Files' and by default skipping EXE files when you unpack a zip).

Except on Mac OS X :) (.pkg files notwithstanding)

Graf Zahl said:

don't use Microsoft tools to unpack Zips. They are made for the computer illiterate public that needs to be protected from its own stupidity.

Does it still change the timestamps of the extracted files? Anyway, I prefer Explorer's interface, and I extract by using Ctrl+C/Ctrl+V, I don't trust the automatic extractor, especially after I saw it was changing timestamps in Win XP.

printz said:

Does it still change the timestamps of the extracted files? Anyway, I prefer Explorer's interface, and I extract by using Ctrl+C/Ctrl+V, I don't trust the automatic extractor, especially after I saw it was changing timestamps in Win XP.

No idea what kind of cr*p tool would do that. I exclusively use either Total Commander or 7Zip for all extraction purposes and both act in a sane manner (i.e. they extract everything and don't change timestamps of extracted files.)

Graf Zahl said:

So, 1) don't put such portable versions in 'Program Files' to begin with. That folder is protected for good reasons and 2) don't use Microsoft tools to unpack Zips. They are made for the computer illiterate public that needs to be protected from its own stupidity.

Telling users (1) is easy enough, no problem.

But telling users that they need to use a 3rd party application to unpack the zip, instead of simply using what the OS provides -- I find that ridiculous, and some users would find it annoying, perhaps even suspicious.

While I'm a fan of the "unpack and run it" model, and think that installers are overkill for most applications, Microsoft's stupid decisions have made that model more painful to support than creating an installer.

@printz: cheers for that info. While reading the MSDN docs, I never saw any page say that reading the %APPDATA% environment variable was the best method to use, plus I didn't know which OSes it was guaranteed to be available.