EE 3.33.33 "Paladin" Released

That's right, you can now exhale the breath you've been holding for half a year, because v3.33.33 of the Eternity Engine has been released.

New features and bug fixes number the most ever seen in one version of the engine, so I'm not even going to try to mention it all here. Just go to the Eternity page and you'll find everything you need.

Happy DOOMing!

FP: Finally!

I love you. POLYOBJECTS! WEE!

Fucking Finally <3

Hurrah! I'd go home and play with it now if missing any more tutes without a valid reason wouldn't make me fail.

Man, am I ever looking forward to tossing about with polyobjects and that.

Something odd: in order to navigate multi-page menus, rather than just pressing right arrow or left arrow, I need to press Ctrl in addition. Assuming this is a deliberate feature, it seems a little non-obvious.

And there was much rejoicing...

Grazza: Yes, deliberate. But as the text file mentions, there are also new keybinding actions named menu_pageup and menu_pagedown. Binding these to keys will allow you to page over with only one key press.

Basically, Eternity cannot use plain left/right to page over because that action is already preferentially taken by toggle-type menu items to change values (BOOM and MBF did not possess this type of menu item and thus didn't have that issue).

Also, don't miss the menu_contents action. With it, you can bring up a table of contents for any multipage menu. You can bind all three of these actions on the Menu section of the Keybindings menu.

Hell YES! Looking forward to play around with this new version once I get home!

Swankity-doodle-doo!

But... portals are broken again. Excess HOM tends to kick in over relatively long distances. I'm not sure, because of the limited amount I have available to test with, but I think it happens after a certain amount of ceiling beams are lined up across a single portal. I know it's the engine because I unpacked the 3.33.02 fix again and all is fine in the exact same areas under the exact same conditions.

Also, look up/down is still broken. I can enter the keys in the menu, and it will say "look down = z" or "look down = pgdn" or whatever key I press, but when I press that key in-game, the player doesn't "look" anywhere.

And if you wanted to make the menu navigation easier, you could have "next" be a selectable item.

Portals are SoM's department so I don't know what to tell you here. Testing was done and no problems were found, but you've used portals in ways nobody else has yet so if there are bugs, you're going to be the first to find them. Please remember that there are spatial restrictions on ALL anchored portals. If you can see it from a certain location, the anchored portal cam had better still be within valid space or the alternative is HOM.

I don't understand why your keybindings are broken. *PLEASE* make sure to go to the mouse/joystick menu and enable *BOTH* of the variables there. You cannot mouse look or key look unless BOTH variables are set to ON or YES (actually you can, but one of the variables controls whether or not you must press a separate key first to be able to look around, which is meant to be used with mouse play as a way to lock your view -- most people do not expect this behavior so I say both).

EDIT:
The variables are "Enable Mouselook" and "Always Mouselook". Enable mouselook is like a comp option. If it is off, you just can't look up or down at all. Always mouselook is the variable I described above. If it is set to no, then you must bind a key to the "Mlook On" action which you will notice listed in the looking section of the keybindings menu and hold it down in order to look. There are no separate config variables to control mouse vs key look at the present time; they are considered the same.

Lüt said:
But... portals are broken again. Excess HOM tends to kick in over relatively long distances.

I just (quickly) checked out a couple of my levels that make extensive use of portals (in various shapes and sizes) and have not seen any problems so far.

That said, I haven't yet use portals which are meant to be seen from long distances away.

I did encounter a few warning messages about portals not being rendered, in a level which I hadn't adjusted (yet) to SoM's new way of making portals (introduced in previous version). Will fix those (weekend) and see if everything works as it's supposed to :)

the new portal drawing breaks rf's map. Oh well...

I do have a beef with r_swirl. if you have a large animated flat in a sector, setting r_swirl to 1 will instacrash.

Portals are broken, again. OK, we've established that, let's move on. Please no more reports that portals are broken >_<

I told SoM the swirling thing wasn't going to work, and so here we are. It looks like at this rate, v3.35.00 will be coming out in a couple of days rather than a couple of months.

There's too many threes in that number. I'm gonna go for a smoke . . .

Not only with large flats r_swirl bombs Eternity to command prompt, but with regular ones too. I have normal 64X64 flats with the r_swirl flag and Eternity crashes with the Segmentation Fault (SDL Parachute Deployed) message the time i have line of sight with the sector with the animated flat. First i think portals were the cause, but when removing all r_swirl flats the level runs fine.

Cya.

Proper functioning of portals very much depends on the way you construct them, and this proper way to construct them has changed from version to version. This may explain why some portals suddenly break with the release of a new Eternity version.

I'd like to compare notes with some other Eternity-using level designers.

Ceiling portal using old (not 2-way) trigger: easy to do. Setup: sector B, tagged, 0/128, ceiling F_SKY, inside sector A. Portal C to be drawn on top of B, 128/160, floor F_SKY. Sometimes I use non-SKY & tagged ceiling patches inside B to prevent hitting projectiles from disappearing. The edge between B en C I usually do in the portal itself (eg sector D around C in portal area, 144/160, border textured). Creating an double edge (border texture in B and another one in C) seems prone to cause HOM more earlier when walking away from the virtual camera.

Floor portal using old (not 2-way) trigger: tricky when used as "hole" in floor. Maximum "depth" of the "hole" about 32, because it will cause HOM when player's view goes below the portal plane. Setup: normal sector A (say, 0/128); inside that sector B as a border, -8/128; floor = F_SKY, borders A/B textured, tagged; inside that sector C, -32/128, borders not textured. Portal area next: D (-33/128) on top of area B+C, ceiling = F_SKY, borders not textured. And eg E (-33,-8) around D for the portal view. Floor portals always need a border, but along 1s borders you can sometimes forego them.

As always, going too far away (relative to size of portal effected area) from the virtual camera will cause HOM, usually starting at some point of height difference within the portal. And it usually happens for ceiling portals; floor portals seem not be bothered too much by this.

I'll try and provide some test levels with different kinds of portals this weekend, plus experiment some more with 2-way portals (which I hope will give me more freedom with floor portals).

Is this also the way things are set up for those people reporting broken portals? Or did you do it differently?

People just don't seem to understand the basic concept of the anchored portal.

Think of it like this.

At level start, a camera spawns along with the player. That camera is offset from your position by the distance between the portal and the anchor lines.

No matter how you move during the level, that camera remains offset from your position along the exact same vector. Consider this diagram:

       +------+
       |      |
       |      |
       |   C  |
       +------+
          /
         /
+------+/
|      /
|     /|   
|    P |
+------+

Point P is the player. Point C is the camera. There is a line attaching them and when the player moves, the line pulls the camera along with him. What happens if there is a hallway behind the player but not behind the portal area? Well I'll tell you what: the portal camera moves RIGHT THROUGH that wall and into void space. You're now looking at a view that may or may not contain HOM depending on the layout of areas visible in the portal.

Why this seems so magical or hard to understand, I'm not sure, and why we haven't just drawn a picture to clearly explain it yet, I can't say either.

Another thing to beware of: The portal camera is *always* at the player's viewheight. It will NOT adjust itself to remain at floor or ceiling level. Going below a floor or above a ceiling in DOOM == HOM no matter what.

Quasar said:
Going below a floor or above a ceiling in DOOM == HOM no matter what.

In practise, you can go above a portal ceiling, but not below a portal floor. Didn't I post a testlevel a while ago, with the player being able to see the "roof" over a "house" structure? This still works in the latest version.

I still don't quite get where the virtual camera is located, but I've learned that placing the portal a couple of thousand units away from the tagged sector (which is usually right at the other side of a level) usually prevents HOM. When I get HOM, first thing I do is move the portal from its original location to another corner of the map, and always well away from the tagged area... and voila, the problem "goes away" :P

Thirty more minutes before I can leave work... tick, tock.

NokturnuS said:

Not only with large flats r_swirl bombs Eternity to command prompt, but with regular ones too. I have normal 64X64 flats with the r_swirl flag and Eternity crashes with the Segmentation Fault (SDL Parachute Deployed) message the time i have line of sight with the sector with the animated flat. First i think portals were the cause, but when removing all r_swirl flats the level runs fine.

Cya.

Found the problem. The code was accessing flattranslation[-1] about a hundred different times and then adding the possibly random value there to firstflat and telling W_CacheLumpNum to load it.

Mordeth said:

In practise, you can go above a portal ceiling, but not below a portal floor. Didn't I post a testlevel a while ago, with the player being able to see the "roof" over a "house" structure? This still works in the latest version.

I still don't quite get where the virtual camera is located, but I've learned that placing the portal a couple of thousand units away from the tagged sector (which is usually right at the other side of a level) usually prevents HOM. When I get HOM, first thing I do is move the portal from its original location to another corner of the map, and always well away from the tagged area... and voila, the problem "goes away" :P

Thirty more minutes before I can leave work... tick, tock.

There shouldn't be any "magic" tricks necessary. Just make the anchored portal area large enough and shaped correctly so that no matter where the player views it from, the camera remains in valid space. Does this mean that if an anchored portal is visible from your entire level that you have to duplicate your entire map? Yes it does. Just a dramatic example, and a reason why anchored portals cannot reasonably be used over an entire map.

Just add an option to visualise the cameras in the automap and they'll get it.

I have a few questions, I apologize in advance if they're somewhat stupid or have been answered before.

Are there any detailed tutorials explaining the use of portals? The Eternity Wiki doesn't seem to cover them and the editing reference at the Eternity homepage is rather basic.

Are there any plans to implement support for screen resolutions up to 1600x1200?

Doom_user said:
Are there any detailed tutorials explaining the use of portals?

Not really, but you can start looking at SoM's Lava Factory level.

http://joe.youfailit.net/portaltut.rar

Or you can have a look at this for a more simple example of how portals work.

Anders said:

Just add an option to visualise the cameras in the automap and they'll get it.

Fantastic idea. I'll think about how this might be possible. It might require a console command to activate camera display for a particular portal, otherwise it might be too cluttered to make any visual sense.

EDIT: Btw, a portal bug has been fixed. "De Kerker" was giving some extraneous error messages because it turns out that child portals can have child portals and so on to an Nth level of generations. The "tainted" count wasn't being cleared for anything but the first generation of child portals, and so Nth generation children would continue increasing their tainted count to infinity.

Well, some more testing done. I get increasingly more warnings about "portal not being drawn" (even when I do not see any problem in-game), sometimes (not always) accompanied by a HOM here and there. Sometimes the warning displays only once, from a particular position, but does not display again for the duration of the game when standing in the same position. Sometimes there is no flaw at all, using standard non-sky ceiling portals. Sometimes I have to use F_SKY ceilings or everything displays as HOM; sometimes even that does not help. This of course with setups that used to work in the previous version :)

Only very basic simple portal setups seem to work 100% all the time.

So in short, no real "standard" way to design a portal. No way to know in advance if your portal is going to work or not. And what exactly does cause "portal not draw"?

I'd rather wait for the next version, see if that stabilises things.

One thing I always loved for a tiny thrill to mess around with in Eternity was the "spawn" console command. I like making an alias with 6, 9, 16, 31, 32, 33, 34, 35, 36 just for fun and binding it to my second mouse button. Or I'd just make a bunch of "spawn 35" in an alias and put on that plasma BFG option and go through levels on nightmare. It was also fun spawning friendly monsters and stuff to cause fights and set barrels all over the level.
But I can't do that anymore because eternity no longer recognizes spawn as a console command. As far as I know there is nothing mentioned about changing it in any documents. I could also use that in heretic now too.
All I have now is the summon command, and that's not nice to use. I don't remember every single weapon or monster to use that.
That's the only thing I've messed around with that hasn't worked.

To this day I've never noticed anything special about the BFG11K thing though. What's that do? I was thinking it might have been a bit like Quake2 or something. But It acts the same as the normal BFG as far as I can tell.

idontknow said:

To this day I've never noticed anything special about the BFG11K thing though. What's that do? I was thinking it might have been a bit like Quake2 or something. But it acts the same as the normal BFG as far as I can tell.

Read the BFG FAQ, and then try again. The differences should be very noticeable.

Please do not start redesigning your portals, Mordeth. Like I said in my previous post, there are bugs in the "tainting" system that keeps non-two-way anchored portals from crashing the game. Those bugs are causing spurious error messages to appear where no error is occurring. Please wait for the next maintenance release before you change any maps!