New features added in Eternity

Since Eternity is once again stuck in a development-build mode for many months (or years) now, I guess I should reveal what has been added for modding stuff. In case you're wondering, the issue is that the release you can get from this forum is kinda outdated, and you're welcome to download "development" builds from DRDTeam.org, which, nearly all the time, are as stable as the "official" releases. Links are at https://devbuilds.drdteam.org/eternity/ and https://devbuilds.drdteam.org/eternity-mac/ .

NOTE: I'm taking the liberty to use this thread as a news stream of new features I add to Eternity. They'll always appear on the wiki too.

From my changelog

NOTE: I'd ask @Altazimuth to be sure which of his additions from his changelog can be made public.

Polyobjects with portals no longer need their origin box to be connected to sectors from the spawn spot's layer.

Visual portals can now be placed on rotating polys. No linked portals unfortunately :(

Inconsistent linked portals are possible! The automap will adjust as you walk through the "warped" portals. Albeit with the restriction that you can't link arbitrary place from area A to another place from area A. I think GZDoom allows that, but only by partially linking the physics, some stuff not connecting seamlessly (correct me @Graf Zahl if wrong). You can only make mismatched links between separate layers.

Added the push activation from Hexen! You may need to hack your level editor's configuration to support that.

New specials: Polyobj_MoveTo, Polyobj_MoveToSpot, Polyobj_OR_MoveTo and Generic_Lift. Documentation is available on the ZDoom wiki.

Added a few fields to ExtraData: linedef "portalid" and sector "portalid.floor" and "portalid.ceiling", equivalent to their UDMF counterparts.

F_SKY1 now works on middle textures!

Masked-transparent textures (e.g. MIDGRATE) now work on portal overlays.

New UDMF linedef boolean field: "monstershoot". It was missing and wasn't possible to have triggers activated by monster hitscans, unlike in ExtraData.

New EDF block: pufftype. Added because Heretic has lots of them. You may see examples in the base EDF folder. The syntax is:

         pufftype <name> [: <base>]
         {
           thingtype       <name>
           sound           <name>
           hitsound        <name>
           hitpufftype     <name>
           nobloodpufftype <name>
           upspeed         <number>
           zspread         <number>
           punchhack       <name>
           particles       <number>
           +|-AlwaysPuff
           +|-Bloodless
           +|-LocalThrust
           +|-RandomTics
         }

I've added other things too, but they're not stable enough to be revealed.

34 minutes ago, printz said:

Since Eternity is once again stuck in a development-build mode for many months (or years) now

This line is depressing tbh. I was really hoping for a new release this year, but if I'm reading that right, it ain't gonna happen after all :( .

34 minutes ago, printz said:

you're welcome to download "development" builds from DRDTeam.org, which, nearly all the time, are as stable as the "official" releases

The 64-bit versions need a compatible midiproc.exe for that to be a viable option for me (I prefer 64-bit because More Power™ is always good). The one from the stable/32-bit versions obviously doesn't work.

5 hours ago, printz said:

New specials: Polyobj_MoveTo, Polyobj_MoveToSpot, Polyobj_OR_MoveTo and Generic_Lift. Documentation is available on the ZDoom wiki.

Somehow I missed these changes, I can definitely use those specials to simplify some ugly scripts I have. 

Being able to put F_SKY1 on walls is actually a huge convenience and simplifies stacked portal outdoor setups quite a bit.

6 hours ago, printz said:

Inconsistent linked portals are possible! The automap will adjust as you walk through the "warped" portals. Albeit with the restriction that you can't link arbitrary place from area A to another place from area A. I think GZDoom allows that, but only by partially linking the physics, some stuff not connecting seamlessly (correct me @Graf Zahl if wrong). You can only make mismatched links between separate layers.

Obviously it cannot create a physical link because that requires all potential paths through portals from A to B to have the same displacement. So what GZDoom does is mostly treating the portal like a teleporter, there's actually two variants here: One is a pure teleporter, the other allows some limited interaction with the portal like calculating an offset for spawning a missile.

6 hours ago, printz said:

F_SKY1 now works on middle textures!

What does this do? Make a one-sided linedef display a sky? If so, what does it take the sky from if a sector has different skies for floor and ceiling? (Not sure if Eternity supports this and only has a single sky per sector.)

6 hours ago, printz said:

New UDMF linedef boolean field: "monstershoot". It was missing and wasn't possible to have triggers activated by monster hitscans, unlike in ExtraData.

What are the precise trigger semantics for this? Just monster hitscans or also monster projectiles?

3 hours ago, skillsaw said:

Being able to put F_SKY1 on walls is actually a huge convenience and simplifies stacked portal outdoor setups quite a bit.

I would suggest using a skybox portal instead; it too has the advantage of being able to tag 1s linedefs as part of the skybox.

1 hour ago, Graf Zahl said:

Just monster hitscans or also monster projectiles?

As far as I know, EE doesn't have that distinction yet for shootable linedefs; although it does have for passable linedefs crossed by a flying missile ('impact' vs 'missile' flag).

2 hours ago, Graf Zahl said:

What does this do? Make a one-sided linedef display a sky? If so, what does it take the sky from if a sector has different skies for floor and ceiling? (Not sure if Eternity supports this and only has a single sky per sector.)

Currently the only way to change sky is with the MBF transfer special or its Static_Init UDMF equivalent special, which only targets sectors by tag. Sky floor, ceiling and walls all get the same transfer if they face the same sector. 

2 hours ago, Graf Zahl said:

What are the precise trigger semantics for this? Just monster hitscans or also monster projectiles?

UDMF inherited the "impact" specifier from Hexen, where it means any kind of "player attacks wall". I interpreted that to be equivalent to Doom's G* activation type, or more precisely to ExtraData's PLAYER|IMPACT. However, I realized that "vanilla" UDMF offers no option for monsters, which is already needed by classic constructs such as the classic GR door. I know ZDoom has something like "monsteractivates" for this, but I wanted a symmetrical equivalent to "MONSTER|IMPACT" here, allowing even monster-only triggers. 

Currently in Doom only hitscans have the effect. Heretic is different here. When I'm back at the PC I'll revisit the versatile ExtraData player/monster/missile/polyobject cross/use/shoot/push bipartite graph and see if there's anything missing in UDMF... 

6 hours ago, Mordeth said:

 

I would suggest using a skybox portal instead; it too has the advantage of being able to tag 1s linedefs as part of the skybox.

Thanks - I wasn't aware of this. Looks extremely useful.

I've added the CPXF_ANCESTOR flag (already in GZDoom) in the ACS function CheckProximity, which means you can now detect inherited thingtypes when setting classname to a base type.

@printz Do you think it's posible Heretic compatibility could be ready for the next release?

On 6/22/2019 at 9:29 PM, UNERXAi said:

@printz Do you think it's posible Heretic compatibility could be ready for the next release?

Hope so, but I'm really sensitive about vanilla Heretic experience compatibility (we have other ports like GZDoom if we're OK with a sufficient approximation of the base game). It may take time nitpicking the differences.

On 6/23/2019 at 9:53 PM, printz said:

It may take time nitpicking the differences.

I'm not entirely sure I see the point in doing so when Quasar left a precedent of fixing broken behaviour in Heretic (the tornadoes come to mind).

Fix broken stuff? Yes. Keep stable effects? Also yes. I mean I found little details which didn't imply serious bugs, but were only obvious by looking at the code, such as most actors being sped up in skill 5. GZDoom handles that correctly for example. That's why I want to sweep the greater part of the code. 

Yeah that's fine.