Wall portals

[Shadow Hog]

Well then, if Eternity-style fixed-offset portals are working correctly, then it's time to go remake "Lunatic Fringe"...

[NeuralStunner]

A bit off-topic, but what kind of hassle would it be to move the FastProjectile's combined X/Y/Z movement into all missiles? I tend to make rockets move quite fast, and it's irritating to choose between proper Z movement and nicer features. It seems like FastProjectile hardly saves any processing these days, maybe it could even be "deprecated". (Or at the least, pack anything "extraneous" into an if block. The function duplication still seems pretty weird to me.)

I wonder if you'd even have to compat-flag such a thing. I can't think of any reason why you'd want the bizarre missile movement.

(I can make this a proper suggestion topic if you'd rather.)

[Graf Zahl]

A bit off-topic, but what kind of hassle would it be to move the FastProjectile's combined X/Y/Z movement into all missiles?

Break a lot of stuff.

[Gez]

I haven't seen any documentation for [wiki]Line_SetPortalTarget[/wiki], which seems to be the function to use to redefine a portal at run-time. So I created it and I hope it's actually how it works.

I'm not sure what happens if you redefine a portal in a way which is incompatible with its original definition.

[Shadow Hog]

Speaking of the wiki, you think it's about time to change [wiki]Portal[/wiki] from a redirect to [wiki]Stacked sectors[/wiki] into a disambig page?

[Graf Zahl]

I'm not sure what happens if you redefine a portal in a way which is incompatible with its original definition.

You cannot redefine linked portals at all. For the other types, they get temporarily downgraded if the features don't mix.

[Gez]

How complete are the Eternity compatibility portals supposed to be? I've loaded Ogro Power Facility, with the following MAPINFO:

Code: Select all

map MAP01 "Ogro Power Facility"
{
	translator = "xlat/eternity.txt"
	next = "MAP02"
	secretnext = "MAP02"
	sky1 = "SKY1"
	cluster = 5
	par = 3000
	music = "$MUSIC_RUNNIN"
}

And the horizon effect, for example, isn't here:
Eternity:


GZDoom:

[Graf Zahl]

The Eternity-style horizon portal is not implemented in ZDoom, and neither is the 'transfer portal to wall' effect and the plane portal.
These are strictly renderer side features, and outside my work area.

In GZDoom all this should work as intended. At least I got them implemented. No idea what's the problem now. Maybe they got disabled by some recent restructuring.

[hfc2x]

Shouldn't it be possible for xlat to translate that specific portal type to Line_Horizon?

[Gez]

Not really, it's set up in a different way.


Static portals seem to freeze GZDoom. It eventually runs out of allocatable memory and crashes. Problem encountered with gzdoom-g2.2pre-797-g7134f53.7z from March 9 on devbuilds.

[Graf Zahl]

Shouldn't it be possible for xlat to translate that specific portal type to Line_Horizon?

No. For the simple reason that it's not the same. The Eternity horizon line takes its data from a model sector, not just from the line's front side. And for that Ogro map it makes a major difference.

[Graf Zahl]

Not really, it's set up in a different way.


Static portals seem to freeze GZDoom. It eventually runs out of allocatable memory and crashes. Problem encountered with gzdoom-g2.2pre-797-g7134f53.7z from March 9 on devbuilds.

Serves you right for insisting on using one-sided lines for portals!
Outside of polyobjects that is absolutely discouraged.

[Major Cooke]

That reminds me, they need a space behind the line, don't they? That is, portals built into walls that are meant to have nothing behind them? Just wanted to double check and update the wiki accordingly.

[Graf Zahl]

Yes. There must be enough space behind to move into. Otherwise you can collide with stuff that occupies the space behind the portal.

[Major Cooke]

Added that and a note that the line should be double sided sans polyobjects.