Setting up func_portals (problem)

[SteveL]

Opening a new thread instead of using newbie thread as I can't find a relevant one.

 

Does anyone know what I am doing wrong with this func_portal? This is my only open-able see-though window so far but I did try adding one to a door and got the same symptoms.

 

 

The window is in my map's starting place. The pic is from inside the building, the player starts outside. When I load the map, it works correctly at first. The visportal is closed until the player starts to climb up to it then it opens before he gets face to face with the window, as desired. But once he's climbed through and the sash window autocloses, the portal immediately closes even if he's still standing right next to it. After the player moves outside the 400 range, the funcportal starts to behave correctly. It'll open again as soon as he gets within range and it'll close when he moves out of range.

 

So on this limited test, it seems the portal won't work correctly from a given side until the player has been out of range of it on that side.

 

Also, the portal will sometimes close while the window is open, so it shows skybox through the open window instead of what's outside. That happens if the player gets out of range while he can still see the (open) window. Does window/door "open" status not override the func portal distance and keep it open? I guess I can fix that symptom by making sure the distance is big enough that it never happens.

 

I tried adding another to an opaque door (I know you don't need a func portal on a solid door but I don't have any more suitable windows yet) and that did the same.

 

The other (yellow) entity that's penetrating the visportal is a location separator in case that's relevant.

[Springheel]

Does window/door "open" status not override the func portal distance and keep it open?

 

No. They close portals if closed but that's all they do.

 

Can't speak to the rest of it.

[RJFerret]

But once he's climbed through and the sash window autocloses, the portal immediately closes even if he's still standing right next to it....

 

Also, the portal will sometimes close while the window is open, so it shows skybox through the open window instead of what's outside. That happens if the player gets out of range while he can still see the (open) window. Does window/door "open" status not override the func portal distance and keep it open?

 

Your first result sounds like the window might be targeting the func_portal? (They are just switches, to manually control the portal.)

 

Correct, the purpose of the func_portal is to override the mover's status, give you manual switching instead of automatic for purposes where the auto doesn't serve.

[SteveL]

Ok thanks, I did guess that problem #2 might be my own misunderstanding.

 

Problem #1 remains. My result suggests the func portal might have to be "initialised" by having the player enter its range from each side before it works as intended, if I haven't set it up wrong. (nothing is targeting anything else btw RJF). Looks like the window gets one shot to override the func portal's override, when the player crosses the portal from one side to the other.

 

I'll see whether toggling it a couple of times at map start changes anything. Otherwise I'll just take control of it with a script. The default behaviour will only need overriding the very first time the player climbs through it, which fits nicely with the location system's script events. If no-one chimes in to tell me I'm doing something wrong in the meantime, I'll post the simplest fix I can find in this thread. This issue (if it is an issue) wouldn't be noticed for most func_portals, it's only where the player can climb through one that it would make itself evident.

 

EDIT: Actually, it's not one shot, and the problem is simpler. The visportal closes whenever the window closes irrespective of anything else.

Edited February 2, 2014 by SteveL

[grayman]

Does the visportal touch or go through the window?

[RJFerret]

Then simple solution, separate the visportal from the window.

[SteveL]

Yes the VP touches the window.

 

Then simple solution, separate the visportal from the window.

 

Doh! *smacks self in face* I'll try that now.

[SteveL]

And of course I now have one beautifully functional, transparent, climbinable window.

 

My first func portal, and I'm so used to putting VPs in contact with windows and doors that it never even occurred to me that I could move it. Of course you shouldn't mix the two control mechanisms. I'll try to save face by suggesting an extra line in the wiki to that effect Thanks guys.

Edited February 2, 2014 by SteveL

[RJFerret]

Yay and so done:

 

"Note, if you have a mover (door/window) in contact with the visportal, it will affect it as well, so typically a visportal controlled by func_portal is placed away from the mover."

[SteveL]

Thank you, that would have saved me quite a bit of time if it had been there last night! However obvious the point seems now

[grayman]

You can place a visportal w/in a transparent door or window, but you have to mark the door or window with the "transparent/1" spawnarg.

 

When the door or window closes, the visportal won't close.

[RJFerret]

Good point, thanks, added, "...or use spawnarg "transparent" set to 1."

[Xarg]

You said the window automatically closes? If that's for perf reasons, you could have a trigger later in the map (around a corner inside, and another trigger under the ladder if you leave that way) that close the window when you can't see it, as opposed to it auto shutting after I'm guessing a. time duration, or b. you've got a trigger to close it when you move through it. That's how I'd do it anyway (if the portal was to stay in contact with the window, the fix you've implemented might be preferable to you in these circumstances).

Edited February 2, 2014 by Xarg

[SteveL]

You can place a visportal w/in a transparent door or window, but you have to mark the door or window with the "transparent/1" spawnarg.

 

When the door or window closes, the visportal won't close.

 

Cool, that'll save time on converting visportals. It'll also help out with cases where you want the portal closed while still in view from a distance. You can position the VP in the middle of your glass layer and still see glass instead of blackness from both sides when it's closed.

[SteveL]

You said the window automatically closes? If that's for perf reasons, you could have a trigger later in the map (around a corner inside, and another trigger under the ladder if you leave that way) that close the window when you can't see it, as opposed to it auto shutting after I'm guessing a. time duration, or b. you've got a trigger to close it when you move through it. That's how I'd do it anyway (if the portal was to stay in contact with the window, the fix you've implemented might be preferable to you in these circumstances).

 

Thanks, another good suggestion. This thread is becoming more useful by the minute. I'm hoping to have more transparent windows so I want as many tools in my box as possible. I loved the windows in Kvornig's FM whose name temporarily escapes me, and the way they changed gameplay by allowing you to be spotted from outside. I'm doing a smallish mission for my first FM so that my inevitable newbie errors don't make me run into problems of scale, but I want it to feel unenclosed. Two tactics are transparent windows looking out on the exterior plus a custom skybox that'll let me make windows at the edge of the map look like they have a view. When I've got the first FM out the door, if it's well received the plan is to expand the location and make some of those skybox areas accessible.

[Skaruts]

Is there any real advantage in auto-closing a window that is see-through? I mean, I assume the portal won't close until it's supposed to anyway, regardless of the window being open or closed, so I'm wondering...

[RJFerret]

Your assumption lacks the subject of this thread (func_portals), their purpose is specifically to close a visportal associated with a transparent window/door (which you are right, without a func_portal, wouldn't close). Think of a func_portal as a manual switch for a visportal, in addition to the automatic closing provided by windows/doors.

 

Note visportals do multiple things, they don't just divide areas into separate visleafs to not be rendered when not seen, they also funnel sound around properly, and attenuate said sound. So yes, if you don't close the visportal, the amount of sound heard through a transparent window would be unusually loud (as if the window were wide open).

 

What's more, func_portals allow not rendering that other area if the player is far enough away, which vastly improves performance.

[Skaruts]

My point was regardless of your need for a manual switch for the visportal, but rather about the window itself.

 

If I understood your situation correctly, doesn't it happen that whenever you're close to the window the portal should be open independently of the window being open or closed, and when you're away or around the corner the portal should be closed independently of the window as well?

 

Seems like you could just control the visportal without caring about the window, since it's a see through window. Or am I missing something?

 

Sorry to be digressing from your problem, but I'm interested in see through windows and I'm trying to not miss anything.

[RJFerret]

Seems like you could just control the visportal without caring about the window...

Which was the conclusion above per messages 6, 8 and 11...so...? Perhaps? Don't know what else you might be considering? :-) Sound?

 

On the subject of see through windows, ideally you would design the space beyond them to be nothing more than part of the existing space, IE, performance-wise it's OK to render both at once. This is why usually you don't see clear windows on the outside of buildings, because exterior visleafs tend to be excessive. But make half a room, connected to another with clear glass, no biggy, or an interior courtyard.

 

In that case, let the visportal be open all the time, and use the features in http://wiki.thedarkmod.com/index.php?title=Controlling_Sound_Loss_Across_Portals to adjust sound attenuation.

[Skaruts]

Ah yes. it was suggested.

 

For some reason I thought you were the OP, by now. Must. Go. Sleep.

[SteveL]

The default behavior of a visportal is to close if it's touching a closed window or door. That happens even when you're standing right next to it, so your transparent window will just show black. You can keep it open by using a func portal, or by moving it so it doesn't touch the window, or by adding the transparent spawnarg to your window.

 

The purpose of the visportal above is to let me mark a location boundary. I need different ambient light either side of the window.