We've split up the commands, scripting and mods, and add ons category! Please be sure you get your thread in the right place.

← Commands
6
Follow

Minecraft bedrock chain command memory system

Minecraft bedrock edition should have a feature where you can pull the data of or reference a player that has been selected by the previous command block.

For example: if i had a impulse command block saying /clear @p diamond 7 then i could follow it with another command that says execute @c ~ ~ ~ /summon example entity.

the "@c" would stand for choosen player. this in theory should allow me to clear items from players inventory and run commands at player who was effected by the clear instead of the generalized.

Avatar
Registered User shared this idea

7 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 0
    Registered User commented
    Comment actions Permalink

    That's a great idea

  • 2
    Registered User commented
    Comment actions Permalink

    This is possible already through tagging:

    tag @p add chosenPlayer
clear @a[tag=chosenPlayer] diamond 7
execute @a[tag=chosenPlayer] ~ ~ ~ summon ...
  • 0
    Registered User commented
    Comment actions Permalink

    I can’t believe I didn’t think about that, this is a very good idea.
    Reply to ExpertCoder14

    but this would make it much easier

  • 1
    Registered User commented
    Comment actions Permalink

    ReaAquaticCraft Even if this system was implemented, there are still a bunch of kinks to work out. For example, what would happen if a command took two target selectors (like /tp)? Then how would the system choose which to use for the @c later? Ambiguities like that are what make these ideas less solid and less likely to be implemented.

  • 0
    Registered User commented
    Comment actions Permalink

    ExpertCoder14 i think you miss understand the system, this selector would only be used in chain command blocks, to set it up properly you would need to to first find a player with the previous commandblock. so an example is a more secure shop system. remove scoreboard of the closest player, then in a chain give "@c" the item. as far as tp goes, if we apply the rule /tp @c to @c would result in nothing happening in most cases since no player was chosen previously. or if you set it up just right, you can teleport the same person to themselves. and because it only works in a very specific way doesnt mean its not useful or its 2 niche because Minecraft has done this before, in fact they did it worse. you can only use the "@s" scoreboard in your command console, and even then its the same as using :"@p" because you will always be the closest player to yourself.

  • 0
    Registered User commented
    Comment actions Permalink

    BaseplateB0T Thanks for your reply. Based on your response, I believe that I have not misunderstood what your idea is talking about, rather, I believe that I may not have been clear about the issue I was pointing out in my previous comment.

    Suppose the following commands are run, in order:

    tp @p[name=test] @p[name=testB]
    give @c diamond 64

    The problem I was talking about is, who does the @c target? Should it target the first player, the second player, or both? That's why I proposed the tags solution, because you can tag either player beforehand to specify which one to target later.

  • 0
    Registered User commented
    Comment actions Permalink

    Suppose the following commands are run, in order:

    tp @p[name=test] @p[name=testB]
    give @c diamond 64

    The problem I was talking about is, who does the @c target? Should it target the first player, the second player, or both? That's why I proposed the tags solution, because you can tag either player beforehand to specify which one to target later.

    Pretty simply, you just don't log entities for commands that take more than one entity. Even doing this, if you desired, you could set up a command that logs the chosen player beforehand, even if it's just through something like /testfor. Or better yet, use /execute to log it in the same command block, by going like so:

    execute @p[name=test] ~ ~ ~ tp @s @p[name=testB]

    give @c diamond 64

    Here, the @c would be referencing the entity who was executed on.

     

    And finally, to answer a question I thought of: what would happen if you used @a or @e? The way I would do it, is that if @a or @e were used, it would store the actual target selector, rather than an individual entity.