2014-08-02_00002.jpg

When I put some linked_portal_door in the map,sometimes it looks buggy,especially when players fire portals.Like I can look through the walls , mixing the world geometry in the view.Or sometimes when ingame I look through the place where the linked_portal_door is placed,the opposite site of view appears white.Do you guys have solution for this kind of bad performance?(When I finish a regular PeTI map,when I enter the exit elevator and look back,same thing happens).

Another question is that I don't know how to make logic and,like how to make two laser catchers control one exit door in hammer.

Picture files are uploaded.

The most important thing to be aware of with portals/worldportals is that only 4 portals can be onscreen at once. You can have more if they are closed, but this is the maximum supported by the engine. When this occurs, you'll get wierd visual errors (showing rooms you shouldn't be able to see) and the console will spam errors about exceeding the maximum number of portals. The white-portal thing I believe happens based on how far you are away from the portal, and is based on how powerful your computer is.

There are 3 main ways to mix logic together: logic_coop_manager (simplest but only handles 2 inputs), logic_branch with logic_branch_listener(handles up to 16), and math_counters(the way PTI does it, it's tricky to setup right though). I'll give example inputs/outputs with catchers and doors, but it'll work with anything.

To use a logic_coop_manager, place the entity and configure the starting state for "A" and "B". Use the SetStateATrue/False for one catcher, and use SetStateBTrue/False for the other. OnChangedToAllTrue Open the door, and Close OnChangedToAnyFalse.

For logic_branches, place one down per catcher/input and give a unique name. Use the SetValue 1/0 to set the state (you can also use these by themselves with the Test input to get an OnTrue/False output depending on the state, with the ToggleTest/SetValueTest first toggling/setting the value before firing outputs.) Place one logic_branch_listener and give it a list of all the branches it should listen to (feel free to double up with multiple listeners on the one branch if needed.) Like the coop_manager, it has a OnAllTrue output to Open the door, but an OnMixed output used to Close the door.

For math_counters, set the Minimum value to 0, and the maximum value to the number of input items. OnPowered the catchers should Add 1, and OnUnPowered Subtract 1. (You need to make sure a device can't trigger these outputs multiple times, unlike the other methods.) OnHitMax Open the door, and OnChangedFromMax Close the door. All the PeTI items are setup this way, with a $connectioncount (plus $connectioncount_polarity for funnels) setting the max value for an internal math_counter.

I'm pretty sure you can have more than 4 portals without issues. My 3-player coop map had 6 portals active without any glitches

They have to be onscreen, ie. all simultaneously visible (probably not seen through another portal). I had the bug occur only with the 4 coop portals and one worldportal, your map might be designed nicely so players can't do it, or no one tried.

TeamSpen210 wrote:
The most important thing to be aware of with portals/worldportals is that only 4 portals can be onscreen at once. You can have more if they are closed, but this is the maximum supported by the engine. When this occurs, you'll get wierd visual errors (showing rooms you shouldn't be able to see) and the console will spam errors about exceeding the maximum number of portals. The white-portal thing I believe happens based on how far you are away from the portal, and is based on how powerful your computer is.

There are 3 main ways to mix logic together: logic_coop_manager (simplest but only handles 2 inputs), logic_branch with logic_branch_listener(handles up to 16), and math_counters(the way PTI does it, it's tricky to setup right though). I'll give example inputs/outputs with catchers and doors, but it'll work with anything.

To use a logic_coop_manager, place the entity and configure the starting state for "A" and "B". Use the SetStateATrue/False for one catcher, and use SetStateBTrue/False for the other. OnChangedToAllTrue Open the door, and Close OnChangedToAnyFalse.

For logic_branches, place one down per catcher/input and give a unique name. Use the SetValue 1/0 to set the state (you can also use these by themselves with the Test input to get an OnTrue/False output depending on the state, with the ToggleTest/SetValueTest first toggling/setting the value before firing outputs.) Place one logic_branch_listener and give it a list of all the branches it should listen to (feel free to double up with multiple listeners on the one branch if needed.) Like the coop_manager, it has a OnAllTrue output to Open the door, but an OnMixed output used to Close the door.

For math_counters, set the Minimum value to 0, and the maximum value to the number of input items. OnPowered the catchers should Add 1, and OnUnPowered Subtract 1. (You need to make sure a device can't trigger these outputs multiple times, unlike the other methods.) OnHitMax Open the door, and OnChangedFromMax Close the door. All the PeTI items are setup this way, with a $connectioncount (plus $connectioncount_polarity for funnels) setting the max value for an internal math_counter.

Wow thank you for such detailed reply ! So now I got two pairs of linked_portal_door,that means 4 world portals?And if blue and orange portals are fired,there will be six,exceeding the max amount of portals on screen? And does it mean for a map,only 1 pair of linked_portal_doors can be active at one moment?

CamBen wrote:
I'm pretty sure you can have more than 4 portals without issues. My 3-player coop map had 6 portals active without any glitches

Really ? How did you do that? Require special solution?

CamBen wrote:
I'm pretty sure you can have more than 4 portals without issues. My 3-player coop map had 6 portals active without any glitches

hey I've uploaded pictures about my issue,you can check it.

Freeman|TR wrote:
CamBen wrote:

I'm pretty sure you can have more than 4 portals without issues. My 3-player coop map had 6 portals active without any glitches

Really ? How did you do that? Require special solution?

The Co-op Hub has six portals as well, but the white walls are placed strategically so that you can never see more than four at once.

FelixGriffin wrote:
Freeman|TR wrote:

CamBen wrote:

I'm pretty sure you can have more than 4 portals without issues. My 3-player coop map had 6 portals active without any glitches

Really ? How did you do that? Require special solution?

The Co-op Hub has six portals as well, but the white walls are placed strategically so that you can never see more than four at once.

now I got what you mean . Regardless of the world geometry like walls,floors,we can't have players seen more than 4 portals at one time right ? Even though the linked_portal_doors are placed behind something ?

Yea, but I've had all 6 portals on one wall before and I could see through them without errors...

Actually, the engine can support 131 open linked_portal_doors at once before it crashes. Seriously. 0_0

The recursion problem mentioned by several previous posters has to do with portals which are overlapping within their associated visleafs. Because of how the game renders portals within a space, the portals do not actually create any sort of visleaf divide, and so the room behind them continues to draw normally - but the engine is also trying to draw the space within the portals, as well. When the game starts trying to draw portals behind portals, or where too many spaces are trying to overlap in the drawcalls, then it starts throwing those red recursion errors.

I've found that putting bounding geometry (like a tools/skybox brush, for instance) behind linked_portal_doors makes them behave much more predictably. Think of it like leaking maps, but with space instead of light - use geometry to keep that space from leaking through multiple portals when drawn from any one point. I am currently working in a map which takes 8 cube-shaped rooms and organizes them into a tesseract by connecting their sides together, using 48 linked_portal_doors to connect them at the side faces, creating a space which loops infinitely in every direction. With the exception of visual lag (solved by putting in a sensible Far Z Clip plane to the map), it works perfectly, and with NO recursion errors. The trick is bounding each cube and its associated portals with another skybox cube just past them. Sticking to less than four portals at once will prevent the problem, but it's not the cause of the problem.

Doomaflatchi wrote:
Actually, the engine can support 131 open linked_portal_doors at once before it crashes. Seriously. 0_0

The recursion problem mentioned by several previous posters has to do with portals which are overlapping within their associated visleafs. Because of how the game renders portals within a space, the portals do not actually create any sort of visleaf divide, and so the room behind them continues to draw normally - but the engine is also trying to draw the space within the portals, as well. When the game starts trying to draw portals behind portals, or where too many spaces are trying to overlap in the drawcalls, then it starts throwing those red recursion errors.

I've found that putting bounding geometry (like a tools/skybox brush, for instance) behind linked_portal_doors makes them behave much more predictably. Think of it like leaking maps, but with space instead of light - use geometry to keep that space from leaking through multiple portals when drawn from any one point. I am currently working in a map which takes 8 cube-shaped rooms and organizes them into a tesseract by connecting their sides together, using 48 linked_portal_doors to connect them at the side faces, creating a space which loops infinitely in every direction. With the exception of visual lag (solved by putting in a sensible Far Z Clip plane to the map), it works perfectly, and with NO recursion errors. The trick is bounding each cube and its associated portals with another skybox cube just past them. Sticking to less than four portals at once will prevent the problem, but it's not the cause of the problem.

Much thanks to the explanation!The cause seems to be deep inside the engine.I think I could find out the solution gradually as I learn more about hammer ^^

Doomaflatchi wrote:
I am currently working in a map which takes 8 cube-shaped rooms and organizes them into a tesseract by connecting their sides together, using 48 linked_portal_doors to connect them at the side faces, creating a space which loops infinitely in every direction.

That sounds like it would be fun to explore for a while. I once tried to make a tesseract. I gave up after a while due to the extreme difficulty I encountered. I hope you release the level as I would love to explore THAT test chamber.