Glowstone

Glowstone copied to clipboard

I am currently working on Command Blocks (with >1.8 functionality). This is to track the progress of these branches: API & Server implementation.

To-Do:

• [ ] Update the Command block API for the new functions
• [ ] Place the new command blocks
• [ ] Save TileEntity and MaterialData for command blocks
• [ ] Incomplete Open command blocks when clicked
  • [ ] Save data when closed
  • [ ] Fix a bug with duplicate interaction packets (opening the command block twice)
  • [ ] Incomplete Use op permission levels
    • [ ] Set permission level when joining the server (EntityStatus)
    • [ ] Add permission level to configuration
• [ ] Make command blocks reactive to redstone
• [ ] Execute commands on behalf of the block
• [ ] Chain command blocks

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

A demo of the current available mechanic: http://momoperes.ca/videos/commandblocks.mp4

I would like to help but am not sure what you mean by "Add permission level to configuration". What configuration, or do you mean to use the permission methods in GlowCommandBlock? Also, what are those supposed to do? Are they supposed to be the permissions required to open the command block or what?

@LousyLynx The "permission level" limits the things an operator can do on the server. The levels are referenced here: https://minecraft.gamepedia.com/Server.properties#Minecraft_server_properties, in the op-permission-level row. A permission level of 2 is required to open command blocks. The permission level has to be sent to the client using the Entity Status packet (see http://wiki.vg/Entities#Player for relevant permission level status IDs).

Also, I started some code for command blocks but it's not really presentable in a certain sense, so I haven't pushed it yet.

That branch is now, in my opinion, largely out of date. A complete re-do of our redstone system is needed and this would make this branch obsolete.

I will leave the command-blocks branch up for future reference.

One interesting tidbit I found out about when implementing the /testfor command: Apparently some commands give off a different redstone signal strength when executed by a command block. In /testfor's case, the signal strength changes depending on the number of targets it matched. Currently, the command API only supports a boolean success/failure, so this should probably be added to the list of task needed.

A very important feature that takes more than 2 years to implement! :(