bergerhealer/TrainCarts

Halt train before teleport until destination is free of trains

Opened this issue · 6 comments

amalon commented

Info

Please provide the following information:

  • BkCommonLib Version (/train version): v1.19.3-v2-SNAPSHOT (build: 1288)
  • TrainCarts Version (/train version): v1.19.3-v2-SNAPSHOT (build: 1453)
  • Server Type and Version (/version): git-Paper-39 (MC: 1.19)

Bug

Description

Using a teleport sign to teleport trains to a multiverse portal in another world doesn't check whether the rail is free at the destination. If a train is stuck (due to other bugs I haven't pinned down), this can cause trains to all land on top of one another and make a mighty laggy mess at the destination. Named mutexes don't work between worlds so can't help.

Expected behaviour

It'd be great if they slowed down and queued up at the teleport sign until there was enough space at the destination for the train to teleport. This would tail back but would prevent more trains from spawning as train spawners appear to have logic to prevent spawning when a train is already stuck waiting there.

Actual behaviour

The trains teleport regardless of the condition at the other end (though I have known for trains to end up broken before the teleport, but I think thats due to pushing around at the destination and ending up teleporting back the other way).

Steps to reproduce

  • In one world, make track with a multiverse portal
    • put a stopped train in front of the portal
  • In another world, put a teleport sign to the multiverse portal
    • start launch trains through it until they pile up on the other side
    • I have a min distance set on the trains, which normally keeps them separated

Additional Information

This is a follow on from issue #460

bergerkiller commented

I can probably add a syntax to make multi-world linking of mutexes work. No technical reason why it cant work

amalon commented

My trains don't even teleport now, and I get this in the log:

[12:40:03 ERROR]: [Train_Carts] Failed to execute GROUP_ENTER for SignActionTeleport at {world x=192 y=75 z=-2249}:
java.lang.NullPointerException: Cannot invoke "com.onarandombox.MultiversePortals.MultiversePortals.getPortalManager()" because "this.plugin" is null
        at com.bergerkiller.bukkit.tc.portals.plugins.MultiversePortalsProvider.getPortalDestination(MultiversePortalsProvider.java:33) ~[TrainCarts-1.20.1-v3-SNAPSHOT-1444.jar:?]
        at com.bergerkiller.bukkit.tc.portals.TCPortalManager.getPortalDestination(TCPortalManager.java:55) ~[TrainCarts-1.20.1-v3-SNAPSHOT-1444.jar:?]
        at com.bergerkiller.bukkit.tc.signactions.SignActionTeleport.execute(SignActionTeleport.java:77) ~[TrainCarts-1.20.1-v3-SNAPSHOT-1444.jar:?]
        at com.bergerkiller.bukkit.tc.signactions.SignAction.executeOneImpl(SignAction.java:436) ~[TrainCarts-1.20.1-v3-SNAPSHOT-1444.jar:?]

This is with multiverse-portals.

Train_Carts: v1.20.1-v3-SNAPSHOT (build: 1444)
BKCommonLib: v1.20.1-v3-SNAPSHOT (build: 1605)
Server: git-Paper-65 (MC: 1.20.1)

bergerkiller commented

Did multiverse portals actually enable properly? Can you check the server log whether it enabled prior?

EDIT

nvm I see what went wrong, give me a moment

bergerkiller commented

This should fix it. I broke it when I rewrote that logic using SoftDependency api. https://ci.mg-dev.eu/job/TrainCarts/1450/

(Should add that the main issue isnt fixed yet or implemented of course)

amalon commented

thanks for the swift response! I'll give that a spin when I can restart server and report back (sorry to hijack this issue!)

amalon commented

confirmed, teleport to portal working again (without mutex)