Portals and seeker missiles compatibility

[xyz987]

Right now line portals and seeker missiles are not compatible. But maybe they could be in the future??

[Rachael]

Please post an example map with it not working.

[xyz987]

For some reason I cannot attach files so here is a big link:

https://mega.nz/file/eXxQ3BZC#-jfnnWWEe ... EYjf2_nTPE

You can see that when you are in the center, the seeker missiles will move towards where the player is at (outside the wall).
Similarly, if you stand at one of the ends and allow a missile to enter the center, it will then also hit the wall.

[Rachael]

This is already implemented. Check your portal types. Attached is the correct portal types, they should be type 3 (static/eternity)

Seeker Missiles and Portals Fixed.pk3

Static portals can translate sound, lights, monster sight, monster seeker missiles, and any portal-aware object across portal lines.

[xyz987]

I'm afraid that my demo does not fully illustrate the problem. In my mod, I made the center part of the map appear after a switch is activated. I see the wiki says that Line_SetPortalTarget can't redefine static portals. Maybe I'm just out of luck on this one?

[Gez]

Yes, portals are a question of trade-off between capability and flexibility. The most powerful portals must be static; and dynamic portals are more limited in what they offer, but less limited in how they can be set up.

The main issue is that allowing even dynamic portals to behave like static portals would result in a really heavy performance drain. Instead of computing portal offsets once at map startup, they'd have to be recomputed every tic.

What you can do is change the level design a bit. You could have a polyobject blocking off the static portal until it gets opened, for example.

[Rachael]

Also you can combine static and dynamic portals. You can have a static portal in a room somewhere, hidden or in use, and have the dynamic portals for on/off use. As long as every part is still part of the same structure group, the seeker missiles will still go to the proper location. This can be a bit tricky to use and set up though, but the main thing is, you're only using static portals to define the portal groups themselves and keeping the changeable ones dynamic. Also remember that the dynamic portals will still need to be in relatively the same locations as they would if they were static in order for this to work.

[inkoalawetrust]

Yes, portals are a question of trade-off between capability and flexibility. The most powerful portals must be static; and dynamic portals are more limited in what they offer, but less limited in how they can be set up.

The main issue is that allowing even dynamic portals to behave like static portals would result in a really heavy performance drain. Instead of computing portal offsets once at map startup, they'd have to be recomputed every tic.

What you can do is change the level design a bit. You could have a polyobject blocking off the static portal until it gets opened, for example.

Are you sure? I'm pretty sure portal displacements could just be recomputed every time the target line or sector are changed. And that functionality is locked behind a function or two as well. So recalculating the displacements wouldn't even need to be added in too many places.