More locations possibilities and All Players events
Hey, a new fresh post, to freshly suggest some stuff that's been needed for a while:
Some new blocks in makecode
- Get location of block player is looking/aiming at (the cursor, in short)
- Get location of block player has placed.
- Get location of block player has destroyed.
- Get event for ALL players not just the code user. I don't get why the "Player" category doesn't already do that. (when player walk should refer to any player who walk for exemple)
Thanks! Nice day to you all!
-
Well, even in Python Azure Notebooks, this info doesn't seem accessible right now for grabbing the location of a placed or destroyed block. I agree about the facing thing. The ability to teleport a player or the agent to be facing a certain direction is a sweet feature.
I'm interested in what you are trying to do! =] But if you had your wish for a command to retrieve the direction the player was facing, one way to get the location of a placed or destroyed block in two steps would be to add to the player's coordinates based on which way they were facing. I'm not sure, though, if this would really be sufficient, because of the different angles and stuff when you "lean" and things.
What information are you hoping to glean from this? I have run a constant event handler (hunting diamonds! the kids like it) and it slows the game down a lot. Are you needing a lot of data, or are you looking for a help for grading student work in worlds (which does sound helpful!)
The idea of being able to detect coordinates with the cursor is kind of intriguing. Kind of like a compass, except more like a locator... Cool. =] Good thoughts! Thanks for posting.
1 -
Core Protect is the plug-in for these kinds of things. I use it on Java Minecraft. Won’t work with Edu :-0
-1 -
"I'm interested in what you are trying to do! =] "
Mostly we try to encourage our kids to create mini-games or museum kind of things, and being able for exemple to teleport any player that walk on a block of iron, to the next mini-game, or the next museum location. Or if a player right click with a stick, it will give them food.
The thing is, the code builder allow to do this, but only for the current code user. The entire player category is either badly misnamed (should be called Current Player) or badly programmed, and should be able to access ALL player that do the action the block is about.
Again, "when player walk" should detect ANY player that is walking, and apply the code to them. It would simplify so much when it comes to automatisation in those kind of situations
The idea of having the cursor location is for our youngests who sometimes have a hard time with coordinates. If we could detect the cursor we could easily make codes to create things where they're looking, which would simplify things for them. Exemple: they want a house, they got the code to make the house, we center it on the cursor and it's easy as looking at where the house should be.
My big beef with education is how much potential it has, and how much of it feel wasted.
It has a good interface, some fun new blocks, but it all feel gimmicky and surface-level because when you try to go any deeper you get forcibly stopped by the missing code and limitations
And even if I wanted to create my own block of code to solve those problems, the lack of any documentation or tutorial on the matter is another hurdle.
And so Education stagnate as this fun shiny toy that looks pretty, and is rather useless beyond that.Speaking of limitation, that remind me:
Enchanting. The way enchanting works in the code-builder is just so limiting.
You can only enchant the object you're holding in main hand, AND only with compatible enchantement AND only up to the max vanilla level.
But if you fail any of those, there is no warning message to tell you why it failed, so many of our kids just thought they did their code wrong.
Why does the code not look for the first compatible item in inventory and enchant that one, instead of the mainhand one? Why not remove the level limit, when using the code builder?
As it is, it's faster and more efficient to enchant with magic books and anvil, vanilla-style. Which it shouldn't be.If you can give blindness 500 for 999 secondes, you should be able to enchant with sharpness 100 on a stick.
And while I am at it, a way to duplicate inventory would be fun, but that's just a fool's hope at this point.
1 -
Well, it sounds like you are working hard to create an engaging environment for some creative world building! I'm sorry I can't wave a magic wand for all of that, but can I make a couple suggestions?
If there is code that each student needs to run (like having something happen in an on_player_walk event) you can either create the code in MakeCode and share a link in the world settings, for each student to run at the outset of the game, OR, you can create a function which can be added and enabled through the /function command, OR, you can use Azure Notebooks and give them the text of code for them to run (maybe too advanced.)
You probably know this, but instead of teleporting players by stepping on iron, they can teleport by selecting an NPC button, stepping on a pressure plate, or activating a command block with a lever. (not code, I know)
Definitely, figuring coordinates is a hurdle for students! One small tip is to stand somewhere, and teleport the agent to yourself. Then you can move away, and the agent's position shows in the display. I let my students take a photo with their phones to capture the coords in the corner all the time. We take a decent amount of instructional time getting used to coordinates.
Finally, the players' selectors are kind of mysterious in MakeCode! You can get a list of everyone, but it takes a bit of fenagling; I think you have the generate a list of players, if I am remembering the trick I was playing with... Let me know if it's worth it and we can look around!
I wish you all the best. The struggle is real, but the struggle also brings about wonderful, exciting classroom moments! Stick with us. We are better together!
0
Please sign in to leave a comment.
Comments
4 comments