Running Paper 1.15.2, TR 3.0.2

Sample working TR code:
blockX = 10302 blockY = 68 blockZ = -1489 blocktype = "OAK_PLANKS" #SETBLOCK blocktype, "world", blockX, blockY, blockZ
Result: correctly places an OAK_PLANKS block

Sample not-working TR code #1:
blocktype = "DARK_OAK_PLANKS" #SETBLOCK blocktype, "world", blockX, blockY, blockZ
Result: seems to strip off the first word (DARK) and just places OAK_PLANKS block

Sample not-working TR code #2:
blocktype = "RED_NETHER_BRICK_SLAB" #SETBLOCK blocktype, "world", blockX, blockY, blockZ
Result: places nothing

In all not-working cases, there are no error messages generated either in chat or console.

I've tested this with multiple types of blocks. The common thread seems to be whether there are multiple underscores in the block type name.

If there are 2 underscores, the first word and its underscore are stripped off.

IF there are 3 underscores, nothing gets placed.

Though there may be systemic issues w/ #SETBLOCK traceable to legacy conflicts, I want to mention again for emphasis that prior to recently upgrading to 3.0.2 I had scripts running #SETBLOCK without any incident. Then, suddenly, it wasn't working correctly, presumably after the 3.0.2 update. That's my impression of events, anyway. :)

I've done some more testing (on paper 1.13.2) and concluded that the problem has nothing to do with underscores:

"DARK_OAK_LOG" -> "ACACIA_LOG"
"CYAN_WOOL" -> "WHITE_WOOL"
"STONE_BRICK_STAIRS" -> "STONE_BRICK_STAIRS"
"DEAD_BUBBLE_CORAL_BLOCK" -> "DEAD_BUBBLE_CORAL_BLOCK"

All of the blocks that aren't working used to be controlled by data values in previous versions.
SETBLOCK has some legacy code for handling it, such as block.setData(blockData);
The problem is a nasty interaction with the data value system.
Specifically, the blocks are getting reset to the 0 data values
white_wool and oak_planks both occupy the 0 slots of the data values
acacia_log might seem like an exception, but the log blocks are divided into 2 block ids:
https://minecraft.gamepedia.com/Java_Edition_data_values/Pre-flattening#Wood

@gmalone
@wysohn

Can't reproduce on 1.12 because none of the troubled material ids existed back then
I also can't reproduce the issue where nothing gets placed at all. I would have to set up a 1.15 server.
Hopefully fixing the data value issue fixes that too.

Good information, @gerzytet
Your testing has far exceeded mine. Ironically, it all worked fine until the last several days, which I thought might be due to recent 3.0.2 update. Again, though, my testing not in-depth enough to verify that.

@gmalone
have you updated bukkit or your minecraft version since then?
My feeling is that it's caused by a change in API behavior.
Checked the git log and the last time that #SETBLOCK was touched was 4a4a12d dated Christmas 2018 under version 2.1.7 (other than the time it got moved along with the rest of the executors in June 2019, as part of 3.0)

@wysohn
do you know how to detect the minecraft version?
If we're 1.12.2, we use the same implementation. If we're on 1.13+, we don't touch the block data.

@gerzytet
We could do that, yet it might be better to write separate implementation for those of legacy version(1.5.2~1.12.2) and latest version(1.13+)

I think we will need some modification in gradle configuration to do so. (or it can be not necessary since I believe the default configuration already does it)

Ex) use the implementation in the bukkit project first, and then the bukkit-legacy and bukkit-latest overwrite the Executors or Placeholders if it exists.

In this way, we don't have to write same implementation for both legacy and latest, yet if we are required to do so, we can by implementing the specific Executor or Placeholder which requires separated implementation.

@gmalone
have you updated bukkit or your minecraft version since then?
My feeling is that it's caused by a change in API behavior.
Checked the git log and the last time that #SETBLOCK was touched was 4a4a12d dated Christmas 2018 under version 2.1.7 (other than the time it got moved along with the rest of the executors in June 2019, as part of 3.0)

I recently upgraded from Paper 1.14.4 to Paper 1.15.2, along with nearly all plugins upgraded too. I upgraded to TR 3.0.2 around the same time -- last week.

Sounds like you and @wysohn have a plan. Let me know when I can test any fixes.

@wysohn
the solution you described would be ideal, but it would require a lot of rework to pull off. (especially for a bug fix)
This is also the first time we've needed to change the behavior based on minecraft version.
I suggest we keep it simple and use Bukkit.getBukkitVersion​() and an if statement.

@gmalone
We know what you are talking about.

The issue here is that, as @gerzytet said, it's not the code we have written causing the problem.

It's the change in the Bukkit API itself. But it's not surprising since they already announced that they are no longer going to maintain the older version of Bukkit API, and altering the data value of Blocks are deprecated since it is removed starting from version 1.13

I only can assume that it has been working because the Spigot team internally built the backward compatibility codes to support the plugins, which were built based on versions prior to 1.12.2.

Simply, the version 1.15+ cannot provide such backward compatibility due to the change in Minecraft itself, or the Spigot team just decided to drop the legacy support as they announced earlier.

Either way, we have divided the project into legacy and latest for this reason, so it will be handled in the future versions.

Thanks, understood @wysohn

I appreciate the explanation from both you and @gerzytet

@gmalone
Can you try to reproduce the issue again
I booted up the test server just now and couldn't reproduce it anymore.
This smells like a library bug to me.
I'm testing on paper 1.13.2

@gerzytet Yes I can easily reproduce. I've left my code as-is since reporting it. If you'd like, I could do a specific test for you. See my earlier post to see what I see. Should you try using 1.15.2? My server:
[13:43:17 INFO]: This server is running Paper version git-Paper-105 (MC: 1.15.2) (Implementing API version 1.15.2-R0.1-SNAPSHOT)

EDIT: I see there's a new version of Paper for 1.15.2. I'm installing and will test again, just in case the issue's on their end.

UPDATE: Now using this version:
[14:19:49 INFO]: This server is running Paper version git-Paper-120 (MC: 1.15.2) (Implementing API version 1.15.2-R0.1-SNAPSHOT)
Same issue exists as previously described. :(

@gmalone
Sorry if it's too late.

Somehow, I can't reproduce the problem even in paper 1.15.2. Can you confirm again? I'm on TR 3.0.3. I don't think there was a fix for executors in 3.0.3 version too.

The code used:
/trg run #SETBLOCK "RED_NETHER_BRICK_SLAB" player.getLocation()

Result:

Ignore the errors. I just ran the command without the parameters to see what parameters I need to provide.

Please re-open the issue if the problem persists.