Quote from RustyDios on January 31, 2014, 5:53 pm

Goldenknighttim wrote:

Well, the tobbel's autoportal didn't work. It had the same problem that the beemod autoportal had where the orange portal would spawn in the last place the orange portal had been placed before the player is demoted to a 1-portal gun. For now, we have gotten the glitch to somehow only happen in a way that we could cover up. The VDC page was useful, but it didn't help in the end. Thank you both anyway.

This might be your problem here... I'm not sure I've seen any maps where someone gets demoted in portal gun use. Auto-Portal maps usually start with no gun, then upgrade to one shot and finally to two-shot use if needed. The only times I can think of when this has happened it's been part of a map-pack where the end of the previous map you loose your two-shot gun (ie from a long ending fall) and at the beginning of the next loaded map (starting during the fall) soon acquire a new/damaged one-shot gun. You don't actually get demoted in the same map.

Someone correct me if I'm wrong, or if they know of any portal-gun demotion maps... so I can go and play them... .. sounds interesting...

Quote from FelixGriffin on January 31, 2014, 7:32 pm

Factum Solus does something like that, alternating between dual-portal and one-portal chambers.

And you don't need to use a func_portal_detector for that. As you've noticed, in Portal 2 (but not Portal 1 afaik) if there's a prop_portal with the proper linkage in the map already the gun will just move it around. Place your two portals somewhere, give them names, then use the input to change their location.

Quote from CJLERCH on February 6, 2014, 10:36 pm

Okay, STOP using the autoportal instance. Do it manually. prop_portal is the portal, use a prop_dynamic for the portal spawner model (it needs to be a dynamic entity if you want the light effects to work), and env_shake if you want the shake effect used in the campaign. I don't recommend using an instance for it; while maybe a bit more convenient, they don't always work properly, especially when they're used in a different way than what they were intended to be used for (assuming that you're trying to use it in Hammer). I'd link you to a developer page, but there really isn't one, or at least one I could find.

Quote from iWork925 on February 7, 2014, 12:13 am

CJLERCH wrote:

Okay, STOP using the autoportal instance. Do it manually. prop_portal is the portal, use a prop_dynamic for the portal spawner model (it needs to be a dynamic entity if you want the light effects to work), and env_shake if you want the shake effect used in the campaign. I don't recommend using an instance for it; while maybe a bit more convenient, they don't always work properly, especially when they're used in a different way than what they were intended to be used for (assuming that you're trying to use it in Hammer). I'd link you to a developer page, but there really isn't one, or at least one I could find.

https://developer.valvesoftware.com/wiki/Prop_portal

Quote from Gemarakup on February 7, 2014, 12:15 am

It's not quite useful though. Just shows you the keyvalues and I/O.

Quote from iWork925 on February 7, 2014, 12:43 am

Because that is all you need to know. Place it on a wall, activate it through a trigger or something. Done. I am trying to understand why people are having problems with it. I made a simple map in hammer with a prop_portal and a single portal gun, works fine.

Quote from Gemarakup on February 7, 2014, 2:03 am

Yeah, but you can get mistaken with the outputs and keyvalues. You're not allowed to have a prop_portal "Active" at start and some people might use the Enable/Disable instead of SetActiveState 1 or 0.

Quote from iWork925 on February 7, 2014, 2:20 am

True. Someone awesome should update the VDC.