Full rewrite of the ZoomTube system

[Daniel-Cortez]

After fixing an orphaned node in 1de2b1b I decided to take a closer look at the code in ZoomTubePath.gd, as I was wondering why Base Zone only has one-way pipes. As it turned out, the two-way mode was never implemented, although some extra variables for it were already there.

This PR is my take at finishing the said two-way mode. I also made one of the pipes in Base Zone two-way, and took a liberty at cleaning up the code a little bit.

[DimensionWarped]

ooh this one sounds fun. Didn't even know that was planned.

[Daniel-Cortez]

two-way_pipes.mp4

[DimensionWarped]

One thing I think I'd like to see on this is a visual aid in the editor for understanding which pipe has which set of odds when switching. Is that something you think you can implement? Everything else here looks good to me.

EDIT: I guess also the forking when going backwards might complicate things when making a tool like that though... You know, when I'm thinking about this a little more I'm not sure we shouldn't just have each entrance be its own gimmick rather than having pipes being explicitly bimodal. Mind hitting me up a little later on Discord to talk design?

EDIT2: For what it's worth, process vs physics process isn't going to be a major factor when repositioning a character when collisions and acceleration aren't coming into play. In fact, it might be preferable to keep it in process just to make the action smoother when 120hz displays are used with 60hz physics processing.

[Daniel-Cortez]

What was supposed to be a simple improvement of an already existing system, turned out to become a complete overhaul.

The new system brings the following functionality:

• Three distinct types of tube nodes:
  • ZoomTube - the tube itself.
  • ZoomTubeEnd - responsible for the player entering and exiting the tube.
  • ZoomTubeConnector - connects tubes to each other, accepts the player when they finish traveling through a tube connected to it, and defines logic for launching the player into the next tube.
• Two branch modes for connector nodes: Random and Player Input.
  Random mode performs a weighted random selection based on weights specified for each tube (for example, if tube A has a weight of 40 and tube B has a weight of 60, then tube B would have bigger probability of being selected). The tube the player has entered the connector node from is excluded from selection, so the player won't be randomly sent back into it.
  When Player Input mode is specified, the gimmick waits for player input (arrow keys), then launches them into the tube connected from the selected direction.
• In-editor visual hints.
  If the tube connector is in Random mode, the weights are displayed for each connected tube.
  
  If only 2 tubes are connected, the weihts are not displayed (see the upper connector in the above image), because in Random mode one tube always gets removed from the selection, and there's no actual selection with only one option left, which makes weights meaningless in such cases.
  Also, if the connector is in Player Input mode, the arrows are displayed instead of weights in order to reflect this.
  
• In-game visual hints.
  If the branch mode is Player Input and show_hint_arrows is true, when the player enters a connector node, the arrows (the very same ones that are also displayed in the editor) start blinking, hinting that the user input is required to proceed. This is an opt-in feature (variable show_hint_arrows is false by default).
  

[Daniel-Cortez]

In-game footage:

2026-03-02.02-40-57_1.mp4

[Daniel-Cortez]

In-editor tube placement footage:

2026-03-02.03-36-41_1.mp4

[DimensionWarped]

Can't wait to play with this. Looks like you just keep upping the features too.

[DimensionWarped]

I have a few findings on usability that we need to go over. I'll be happy to take some pushback on some of them if they are too much hassle for too little reward. A few others

1 - I can't connect the same zoom tube to a connector in two directions. IE - if I set connector A's north side to zoomtube B and then try to set connector A's east side as zoomtube B Is there a compelling reason for this?

2 - This is just a gripe, but the zoom tube path starts at the center of the graphic, so naturally the tube renders inside of the connector. Do you think it would be possible to fix that by having offsets automatically be determined and have a secondary path for the visuals that automatically places the terminal points offset from the tube center based on the size of the sprite?

3 - Please expose the connector/end sprite textures in exports similar to how the connector exposes its line texture.

4 - In a similar vein to 2, it's very easy for the tube to get visually messy near the terminals as you add points to the line. We can probably fix this by laying down a couple extra points on each side. I don't know if that's worthwhile though.

5 - I don't know if this is just a bug, but I think there are some nasty side effects to the connectors trying to aggressively control the first/last points of the zoom tube that make manual editing of the paths tricky. In fact, I think they might be gumming up the editor in general. When I end up in a situation where I can't delete path nodes I also seem to be unable to add objects to the scene at all. I'm not sure if this is something we can address immediately though. I'll test this issue more later. I'd shrug it off as a one-off thing if it hadn't happened to me twice while doing approximately the same type of thing.

6 - Ends can eject players the wrong way under certain conditions (this one is less negotiable -- we either need a fix for this or an explanation for why what I'm doing here is invalid)
https://github.com/user-attachments/assets/e3fd21c8-dc1e-464f-8570-dc8bc8d3cd67