Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

waitdelay property sign has no effect on trains #502

Open
HightechTR opened this issue Aug 18, 2024 · 9 comments
Open

waitdelay property sign has no effect on trains #502

HightechTR opened this issue Aug 18, 2024 · 9 comments

Comments

@HightechTR
Copy link

Info

Please provide the following information:

  • BkCommonLib Version (/train version): 1.20.6-v1
  • TrainCarts Version (/train version): 1.20.6-v1
  • Server Type and Version (/version): Paper 1.20.6

Bug

The property sign does not change the wait.delay property of trains as intended.

Description

The waitdelay property sign should modify the waitdelay property of trains.
However, in my testing, it does not have any effect on the train at all.

Expected behaviour

The sign should change the train's wait delay to the amount defined on the sign.
E.g., a waitdelay property sign with the number set to 5 should change the train's wait delay to 5 seconds.

Actual behaviour

The sign does not have any effect on the train, even when using an always-on power mode [+train].
The train retains the same wait delay it has previously set.

Steps to reproduce

For a wait delay of 5 seconds:
Build a waitdelay property sign with the following format:

[+train]
property
waitdelay
5

Have a train run over the sign.

@bergerkiller
Copy link
Member

It works for me, but maybe its not fully clear what the wait delay does. With a wait delay set, if the train is put to a complete stop (not if its moving super slowly following another train), then before starting to move again it waits this delay.

How did you expect the wait delay to function?

What I tested:

I spawned a train with a wait distance set, delay 0, then a waitdelay property sign sets it to 5. Now when the train is stopped by a still-standing train, and I destroy that still-standing train, it waits for the $waitdelay before starting to move again.

@HightechTR
Copy link
Author

That is exactly how I expected the wait delay to function.
For whatever reason, when I tested it, the waitdelay property sign does not do anything.
I even selected the train and ran /train property wait delay to check, and indeed the sign did not change the wait delay.

@bergerkiller
Copy link
Member

bergerkiller commented Sep 3, 2024

Was the placement correct, so that the train is facing the sign (direction?). You can use [+train:*] to activate from any direction

@HightechTR
Copy link
Author

The sign was placed on the side of the block the rails are on, so the train sees the side of the sign. This should be a correct placement as far as I know.

@bergerkiller
Copy link
Member

Can you include a screenshot? It sounds correct yes. Still worth checking if the * makes a difference

@HightechTR
Copy link
Author

This was the setup I had:
2024-09-09_23 13 00
The sign was lined up with a bunch of other property signs (the others all work by the way).

I had a train run over it, then I ran /train wait delay to check it's wait delay, instead of 5 it was 20:
2024-09-09_23 14 35

I don't even know where the 20 came from, since I did not set the number 20 in the DefaultTrainProperties config at all.

I also tried with the *, sadly it did not make any difference.
2024-09-09_23 15 41

As a hunch, I decided to place another waitdelay sign further down the track just by itself:
2024-09-09_23 22 19

This time, it actually worked:
2024-09-09_23 20 18

Not sure what is going on here but at least I made progress.

@bergerkiller
Copy link
Member

The 20 came from the waitacceleration sign, and without your screenshots I never wouldve figured that out haha

Thanks, this should fix it

https://ci.mg-dev.eu/job/TrainCarts/1600/

@HightechTR
Copy link
Author

Looks good, though I sadly can't test it right now since its a build for 1.21, and our server can't update to that until all our plugins are updated.

@bergerkiller
Copy link
Member

Builds 1.21 work on older server versions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants