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

triggerEvent/addEvent issue #2448

Closed
flashmta opened this issue Dec 2, 2021 · 3 comments · Fixed by #2333
Closed

triggerEvent/addEvent issue #2448

flashmta opened this issue Dec 2, 2021 · 3 comments · Fixed by #2333
Labels
bug Something isn't working
Milestone

Comments

@flashmta
Copy link

flashmta commented Dec 2, 2021

Describe the bug

triggerEvent is not working when a given resource start/stop order is used.

To reproduce

  1. start test3
  2. start test2
  3. stop test3
  4. start test1

test.zip

Expected behaviour

The event should be triggered (message should appear in debug console)

Version

Multi Theft Auto v1.5.9-release-21024.1

@flashmta flashmta added the bug Something isn't working label Dec 2, 2021
@Lpsd
Copy link
Member

Lpsd commented Dec 2, 2021

This is because you originally add the event in test3. When an event is added for the first time, that resource essentially has ownership of the event (it's "tied" to the Lua VM of that resource).

Since your event is already registered and owned by test3, the addEvent call within test2 resource has no effect (the addEventHandler call still works fine as expected)

When test3 is stopped, since it has ownership of the event, that event is removed completely - regardless of if other resources have handlers for the event. In this case, it doesn't matter that test2 has a handler for your event, since the event doesn't exist anymore.

I do think that ownership of events should be cascaded down to other resources when the owner resource has been stopped. It should be done in the order of the event handlers being added (oldest -> newest).

In this instance, test2 would take ownership of your event when test3 stops, since it was the next resource (in order) to handle the event.

A small concern is whether we have to worry about backwards compatibility for this (regardless of our stance on bwc. for 1.6) - people may expect events to be destroyed when their resource owner is stopped. Or rather, should there be a parameter to choose the behaviour?

@Pieter-Dewachter
Copy link
Contributor

Pieter-Dewachter commented Dec 2, 2021

I have made a PR that resolves this issue a while ago, perhaps it's a good time to give it a new review?
#2333

@Lpsd
Copy link
Member

Lpsd commented Dec 26, 2021

Closed by #2333

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants