Sniper's Paradise!


Portals

Portals are essentially zones that not only teleport you from point A to point B, but allow you to SEE where you are going to. The portal is a "window" to another place. Since they are actually zones which "connect" the actual terminology would be Warp Zone. In this tutorial the term "Warp Zone" will refer to the portal structure. The term "portal" will refer to the actual zone sheet which is the "window" to the warp destination. You can build a simple "doorway" portal, or a much better effect is a "closet" that you can walk all the way around, or walk into and "warp" to another area. A few issues and problems with the way the engine treat warp zones need to be taken into consideration.

Properties of the WarpZoneInfo actor. (WarpZoneInfo is found under Info and ZoneInfo in the actor browser).

Property Specific
bNoTeleFrag Prevent telefrag when using the portal.
Destinations[] Change destination (OtherSideURL) when triggered.
OtherSideURL ThisTag of the destination WarpZoneInfo.
ThisTag Name of the specific WarpZone.

 

 

 

 

Creating WarpZones:

For a warp zone to work you need to create two zones portals with equal sized and shape and add a WarpZoneInfo actor inside each zone portal. To link the two zones together you need to set the 'ThisTag' value for one portal the same as the OtherSideURL of the other portal and vice versa.

Property Settings:

bNoTeleFrag:
This enables or disables the ability to telefrag another player. This will only happen if the collision area of two players occupy part of the same space once one player teleports.

Destinations:
This set of 8 destination tags, allows for multiple warpzones to connect to a single source. When triggering the WarpZoneInfo it will switch the current destination (OtherSideURL) with the next destination entry. The order they switch through is bottom to top in the list, ie 7-0. If the OtherSideURL property is left blank then it becomes inactive.

When the last WarpZone entry is switched it starts over from the first entry in destinations, ignoring anything placed in "OtherSideURL". This is a bug in the script as the first entry in "Destinations" will be ignored if "OtherSideURL" is blank once it starts over. Because of this, the first destination portal, either 'OtherSideURL' or the first entry under 'Destinations' can only be used once.

Understanding the mechanics:

When rebuilding, the engine takes the 'OthersideURL' and looks for the correct 'WarpZoneInfo' actor that has this in its 'ThisTag'. If none is found the warpzone will be inactive. As long as the warpzone finds a 'WarpZoneInfo' actor with the correct 'ThisTag' it will link the warpzone together. To create the view where you see from one side to another, it links one side of the zoneportal sheet to the other side of zoneportal sheet of the destination warpzone. In essence it looks like the two zoneportals occupy the same space. Position and rotation (bDirectional) of the 'WarpZoneInfo' actor plays no role.

The sheet of the zoneportal is always two-sided which mean that if the incorrect side face outwards you get a warpzone that does not work correctly and produce HOM effects. By rotating one of the zoneportals sheet 180 degrees will correct this problem.

It is not possible to exchange two sides of a brush / sheet meaning that any warpzone created using anything other than sheets will cause trouble. However, it would be possible if one warpzone use a sheet and other side is another type of brush as the sheet can be rotated to show the correct side based on what side face outwards of the other brush.

It's also important to know that it's the sides of the sheets that are linked and not the sheet brushes themselfs. As a result, rotating the texture will rotate the view through the portal allowing for visually physical defiant views. Infact, it affect physics aswell but is not represented very well as the engine do not allow players or objects to rotate (alternative orientation or gravity). You can see this when shooting a razorblade through and see how it change rotation instantly. Only texture / side rotation affect outcome, panning has no effect at all. Rotating the sheet brush (not oposing sides but any other direction) will also rotate the side of the brush but is pointless as you can rotate any side with alignment options. Flipping a texture / side will cause HOM effects. The reason for this is that the side orientation will be off compared to the other side orientation. A flipped side portal will still work as the correct side of the sheet face outwards but HOM effects is still present. Flipping the other side sheet in the same direction will create a normal working warp zone again meaning that it doesn't matter what orientation the side has as long as the correct side face outwards and both have the same orientation.

Objects, inlcuding players, will physically, be where their center is. This means that even if half the body of a player is through a portal the physical being, and collision area, is still only at one side. This will cause a few issues. One is that weapons do not detect hit unless they travel through and collide with players and some weapons don't, like the sniper. Other problem is that the depth of the zone, from zoneportal to inside wall need to be large enough to allow half the body to be inside. In short, the center handle need to actually cross the zoneportal to emerge on the other side. This can be used to control if players and / or projectiles should be able to enter or not. The depth needed is the radius of the object with a few extra units to actually cover the center point. The exit zone do not need to have the same depth but objects will be unable to return through allowing for one way portals. A player occupy 84x36 cylinder meaning that depth need to be at least 20 units for a player to be able to enter (44 units if up or down).

NOTE:
Even if the warp zones face each other (endelss corridor) the engine will only render a depth of 7 and after that render the actual inside of the zone.

Weapons without a projectile (scanhit weapons, minigun, enforcer, sniper and beams, shockrifle primary and plasma secondary) will not travel through which mean that you cannot hit someone on the other side.

Specific texture settings do not affect warpzones but translucent shold be avoided as it will cause the texture to occasionally blink from translucent to solid. Solid textures (opaque) will not break a warpzone but you can not see through it.

If you use mutliple sheets to create a zone, with warpzones, linking of these sheets may not be as expected and cause unwanted 'behaviour'. While it still work fine the outcome is less from perfect. It seems that the engine will link two sheets with each other but treat all zoneportals as one whole portal and mirror this for the other side. as a result you could end up exiting through thin air or even solid wall. If one warpzone only use one sheet and the other use multiple sheets you cannot affect what sheet connect with what. There seem to be a pattern to it but not possible to control.

Light affecting the player (and objects), once they cross, change. Sudden change from one to another can ruin an otherwise great transition. To solve this you can create light on both sides of the zone portal for both warpzones. The inside of the zone need to have the same imidiate lighting as the outside.

Oddly shaped zone portals will not work and produce HOM effects. The portal will not work correct either. Use only rectangular sheets by using the sheet builder.

Even if the script say that you can link warpzone portals with other levels, this is not possible.

Visual problems with warpzones is common. Even if the warpzone work fine the view through a portal can produce strange glitches, especially if you view it from the side. Looking through several warpzones will create even more glitches. Two or more warpzones that is aligned, even if separated with solid brushes, can 'leak' over to each other. This only affect the view and will disappear as closer to the portal you get.

Chainlink warpzones:
When a link between two warpzones is made the actual warpzone only use the "WarpZoneInfo" actor as a reference. It's the source warpzone that is important, as it's the sheets (zoneportals) that actually take care of the hard work when playing you can chainlink warpzones.

In the process of rebuild, a warpzone will look up the destination warpzone (ThisTag and OtherSideURL) and make it so that the source zoneportal exit out of the destination zoneportal. As long as the connection is made it's irrelevant what the destination has as 'OtherSideURL'.

This allow you to have zoneporals link to any other warpzone. The zone you exit can have another warpzone in its 'OthersideURL'.

Portal 1 to portal 2, portal 2 to portal 3 and so on. Exit a zoneportal just to turn around and enter / exit to a third place.

Bots support this ok as they only relate to source and destination or 'ThisTag' and 'OthersideURL'.

Bot support:
When rebuilding the navigation network the engine will place WarpZoneMarkers close by any linked WarpZoneInfo actors. Bots will understand and use these points very much like regular teleporters. They also understand that if the "OtherSideURL" is empty they cannot use this specific warp zone (one way warp zones).

However, bots do not understand the use of triggered destinations. They will never trigger the warpzone to get to another destination.

They can also get stuck entering or exiting a warpzone. As a bot roams the network they touch a pathnode and then move toward the next pathnode. When going through a warpzone they actually do the same. First they touch the "WarpZoneMarker" when entering and then the "WarpZoneMarker" at the exit warpzone.

However, the first one is not important because the bot will only know that it's through the warpzone once it touches the destination "WarpZoneMarker" the bot will think that it isn't through and turn around to go back to the starting warpzone, the bot keeps walking back and fourth, through the portal, being stuck. This is easily solved by keeping the 'WarpZoneInfo" actors very close to the zoneportals.

Bots cannot see through zone portals. They will chase after someone through a portal but will not fire any weapon if the opponent is on the other side

Creating a warp zone:
To start with pick a texture set and build a two 256x256x256 rooms, placed a few grid steps between each other. Texture and light as you like but use different texture for each room to allow easier recognition when linking the portals.

Subtract two small rooms, 128x128x128, at each side and at floor level of the allready placed rooms with any texture you want.

Create a sheet with 128x128 and the orientation set to X-Wall. Place this brush in the opening of one of the small rooms and press the add special brush button. Select 'ZonePortal', leave the rest set to the default settings, then press AddSpecial. Do the same for the other small room.

Open the actor browser, expand info, expand zoneinfo and select WarpZoneInfo. Place one inside, behind the zone portal, of one of the small portal rooms and place another one in the second portal rooms.

Open the properties for one of the WarpZoneInfo we placed and change the following.
WarpZoneInfo, ThisTag: portal1
WarpZoneInfo, OtherSideURL: portal2

For the other WarpZoneInfo change accordingly.
WarpZoneInfo, ThisTag: portal2
WarpZoneInfo, OtherSideURL: portal1

Once done, rebuild the map and add a playerstart to test your portal.

Spam Killer

Back To Top
2005 Sniper's Paradise
All logos and trademarks are properties of their respective owners.
Unreal™ is a registered trademark of Epic Games Inc.
Privacy Policy
Website by Softly
Powered by RUSH