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

unwanted event-block handling changes #72

Closed
Pilvinen opened this issue May 4, 2016 · 4 comments
Closed

unwanted event-block handling changes #72

Pilvinen opened this issue May 4, 2016 · 4 comments
Labels
bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. priority: medium Issues that are detrimental to user experience (prohibitive bugs or lack of useful implementation).

Comments

@Pilvinen
Copy link

Pilvinen commented May 4, 2016

All of a sudden event-block handling has changed and is being done in a very retarded way which breaks a lot of backwards compatibility.

The code below used to work and now it doesn't. In the past Skript held the value of event-block and you could reliably use it in your code to refer to the block which was the event-block at the moment of the event happening. "if event-block is {@kehikko-tammi}" would be true even after waiting for 1 tick and confirming that the block at the location of event-block has indeed changed to air, ie:

on break of {@kehikko-tammi} or {@kehikko-kuusi}:
  wait for 1 ticks
  block at location of event-block is air

  if event-block is {@kehikko-tammi}:
    drop {@kehikko-tammi} at location of event-block
  if event-block is {@kehikko-kuusi}:
    drop {@kehikko-kuusi} at location of event-block

Now as a workaround you have to use the code below:

on break of {@kehikko-tammi} or {@kehikko-kuusi}:

  if event-block is {@kehikko-tammi}:
    wait for 1 ticks
    block at location of event-block is air
    drop {@kehikko-tammi} at location of event-block
  if event-block is {@kehikko-kuusi}:
    wait for 1 ticks
    block at location of event-block is air
    drop {@kehikko-kuusi} at location of event-block

Which proves that Skript has started handling "event-block" in a very different way - it's updating it's value -> making extra checks -> making things run slower as a consequence (the proper way to check the true and current event-block was to check "block at location of event-block" if you wanted to know what it is).

This change makes the code structure more constrained and longer than necessary which is not good. This needs to be reverted back to the way it was.

@Pilvinen
Copy link
Author

Pilvinen commented May 4, 2016

Or if for some reason you can't fix this then at the very least you would have to fix past states (good luck with that...):

on break of {@kehikko-tammi} or {@kehikko-kuusi}:
  wait for 1 ticks
  event-block is air

  if event-block was {@kehikko-tammi}:
    drop {@kehikko-tammi} at location of event-block
  if event-block was {@kehikko-kuusi}:
    drop {@kehikko-kuusi} at location of event-block

--->
[08:51:34 ERROR]: Cannot use time states after the event has already passed (rakentaminen.sk, line 258: if event-block was {@kehikko-tammi}:')

@bensku
Copy link
Member

bensku commented May 4, 2016

Could you tell when it did work? Before my fork, or before @Mirreski's fork?

@Pilvinen
Copy link
Author

Pilvinen commented May 4, 2016

Some of your latest updates broke it.

@bensku bensku added the investigating The core developers are currently investigating this issue. Usually used for complex cases. label May 6, 2016
@Snow-Pyon Snow-Pyon added priority: medium Issues that are detrimental to user experience (prohibitive bugs or lack of useful implementation). bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. and removed investigating The core developers are currently investigating this issue. Usually used for complex cases. labels Jan 31, 2018
@bensku
Copy link
Member

bensku commented May 21, 2018

Probably going for past/future states fix, if anyone happens to stumble to this issue. See #671 for some information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. priority: medium Issues that are detrimental to user experience (prohibitive bugs or lack of useful implementation).
Projects
None yet
Development

No branches or pull requests

3 participants