It would be a cool element in single player, because there's not much you can do with painting light bridges when there's only one player. Either there has to be paint dropping directly above the exit part of the bridge, or you have to stick with only painting the "first half" of the bridge. Automatically painted bridges would free you up a lot portal-wise, and allow a lot of new puzzles.

It would also be a very cool element in coop. I can imagine a fun series of tests involving one player controlling an orange-painted bridge, and the other player controlling a blue-painted bridge. There are too many coop possibilities to even list, though.

So yeah. How would you do this? I can imagine it would be possible using a setup of portal detectors which spawn paint entities inside the bridge at incremental points. But that doesn't sound too flexible. There must be an easier way of automatically painting light bridges. Any ideas?

Or you could put a really powerful sprayer right above the bridge emitter.

When the bridge receives paint, spawn an invisible paint sprayer right above the bridge underneath the "real" sprayer, and parent it to the exit portal. I think this can be done entirely with entity logic. (Portal detectors, relays, logic_branches, entity makers.) Then, whenever the exit portal moves, briefly activate and deactivate the sprayer so it paints the same spot relative to the portal.

Maybe I'll try making a demo map to test this out.

Edit: And here it is. There's a bridge and two paint droppers (bounce + speed). When you move the bridge by moving the exit portal, the paint will move with it. If the new length of the bridge is shorter, paint beyond that length will disappear. (That's why there are so many different templates: one for each distance.)

The template spawning and removal is controlled by the various portal detectors and connected logic. The activation of the sprayers is done by the portals themselves, via their "OnPlacedSuccessfully" event.

It works fairly well, except that the re-painting is not instantaneous, and sometimes fails entirely. The invisible sprayers seem to need some random amount of time to apply enough paint, and you can trick them into painting the floor by moving the portal around quickly. (Tried paint bombs as well, but they cause massive spillage and the splash effects cannot be hidden.)

Anyway, if you can get that one wrinkle ironed out (or find a clever way around it), I think this could make for some interesting puzzles

But your thing is still cool! To fix the paint spilling thing, I have an idea that should work. It would involve spawning a large enough trigger_paint_cleanser directly under every paint sprayer, just under the bridge, and have it hang around another half a second after the paint sprayer stops spraying.

To make killing the "wayback" sprayer more automatic, instead of manually putting portal detectors on surfaces that are gonna make the bridge too short... which wouldn't be too good on big maps. Instead you might be able to achieve it with the trigger_paint_cleanser from the previous step. If the paint cleanser receives paint in a very short time period after a portal moves, then the bridge mustn't have been blocking the paint, so it should kill the sprayer. You could also put triggers inside walls that kill any paint sprayers, to avoid spawning the sprayers inside walls, if that's a problem.

But anyway, could you have a go at a magic self-painting bridge? It's probably much easier than what you tried here!

I also discovered that the reason the bridge wasn't getting painted reliably wasn't because there was some random chance that the bridge wouldn't get painted. It was because of the 250 paint blob limit. There was a random chance of blobs spawning in the first place because you're always at the blob limit. So I added a timer to deactivate the two paint droppers while any bridge sprayer is doing its magic.

Not the best solution, but at least the bridge is painting very reliably now.

Anyways, I still have no idea where to start with my original "magic self-painting" bridges. So it'd still be cool if you could give that a shot.

I do like your changes to my example, the anti-spill trigger and workaround for the blob limit. Very elegant! Maybe the timing intervals for shutting off the paint could be a bit more tight, but that requires a lot of trial and error, probably.

Painting the entire bridge might be done in a similar way, with an array of temporary sprayers. The hard part is figuring out how many sprayers to spawn in a given scenario, preferrably without covering every portal-able surface in triggers. I think this is quite possible, with a tiny bit of scripting. I'll give it a try later this week and let you know!

I've seen that the paint sprayers are all active for a second, and each put out 4 blobs a second. So what's the reason for putting a delay of 0.1 seconds between spawning each sprayer in the script? Doesn't seem like you' be hitting the blob limit very fast.

Another question: would it be possible to modify the script slightly to always paint the bridge from "underneath"? By this I mean the sprayers would always choose the side of the bridge lower in terms of the y axis, and spray upwards. This would just mean any paint blobs would more likely be out of your way during the painting of the bridge (it doesn't matter which side you paint of a bridge, both sides get the effect... and even the sharp edges of the bridge get the effect! You can see this in a video of mine. https://www.youtube.com/watch?v=t-ff3nsGhMM).

And one last thing. I see that the script just paints every bridge in the map one colour. This makes it impossible (I think) to have two different-coloured auto-painting bridges in the same map, and even difficult to have normal unpainted bridges in the same map as auto-painted bridges.

So would it be possible to make the script "know" which bridge is which, so that you could have normal unpainted bridges, auto-blue bridges, and auto-orange bridges all in the same room? This would be essential for a coop map where one player controls an auto-blue bridge and the other player controls an auto-orange bridge, and they're both moving their portals around at the same time.

Blaizer wrote:
I've seen that the paint sprayers are all active for a second, and each put out 4 blobs a second. So what's the reason for putting a delay of 0.1 seconds between spawning each sprayer in the script? Doesn't seem like you' be hitting the blob limit very fast.

I was getting reliability problems when activating all sprayers at the same time. Some parts of the bridge would not get painted. Adding the delay seems to improve it somewhat, although I don't really understand why.

Blaizer wrote:
Another question: would it be possible to modify the script slightly to always paint the bridge from "underneath"? By this I mean the sprayers would always choose the side of the bridge lower in terms of the y axis, and spray upwards. This would just mean any paint blobs would more likely be out of your way during the painting of the bridge (it doesn't matter which side you paint of a bridge, both sides get the effect... and even the sharp edges of the bridge get the effect! You can see this in a video of mine. https://www.youtube.com/watch?v=t-ff3nsGhMM).

That is a very good idea. I will see what I can do to make that happen.

Blaizer wrote:
And one last thing. I see that the script just paints every bridge in the map one colour. This makes it impossible (I think) to have two different-coloured auto-painting bridges in the same map, and even difficult to have normal unpainted bridges in the same map as auto-painted bridges.

So would it be possible to make the script "know" which bridge is which, so that you could have normal unpainted bridges, auto-blue bridges, and auto-orange bridges all in the same room? This would be essential for a coop map where one player controls an auto-blue bridge and the other player controls an auto-orange bridge, and they're both moving their portals around at the same time.

I have thought about that, and decided to not tackle that problem just yet and instead provide this "proof of concept " first.

I will try to add your suggestions to the script, but it might take some time. At the moment my "Portal 2 time" is taken up largely by something I'm making for Portal Stories, and that is getting urgent