I don't have the know-how to create this, but I thought it would be a cool testing element. Usually the exit part of a light bridge loses its paint whenever you move the exit portal. But this would be a bridge that always automatically gets painted one colour, either blue or orange, no matter where it's moved.

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?

The light bridge itself (the blue glowy part) is its own entity which is regenerated every time it's portal is moved. A script could potentially detect this.

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

If a solution that doesn't involve chucking paint at the bridges exists, I'd prefer that. I feel like a powerful sprayer above the bridge emitter either wouldn't work every time, or would be messy, or not be instant enough.

Here's an idea, assuming that it gets initially painted with a normal paint sprayer.

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

Really cool demo HMW! It's not even what I was thinking. All I wanted was bridges that automatically got painted in a single colour all the way from the start of the bridge to the end of the bridge whenever you move it. So no paint dropper at all. Just a magic self-painting bridge.

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!

So I did some playing around with your test and made it work a lot better! Now whenever the sprayers are moved with the portal, they're spawning a paint cleanser underneath the bridge. The cleanser then gets left behind when a portal moves again, so it'll catch any paint still in the air. Then each cleanser will delete itself after a set period of time.

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.

Aha, now I understand what you mean! I was thinking in a completely different direction

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!

Well it took a while (busy, as usual), but here it is. Place the script in your scripts/vscripts folder. It gets triggered by a relay in the map and takes care of the actual painting. I have added plenty of comments to try and explain how it all works, but feel free to ask if you have any questions.

I've had a read of the script and it looks great! I don't understand all the maths, but I'm guessing it's needed to make it work when painting the bridge in any orientation. Very robust.

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