Back to minecraft.net

A feedback area designed for scripting and mods suggestions and feedback. Please note bug reports and support issues will be removed.

← Scripting and Mods
133
Follow

String type for '/execute store' command

The title says it all.

Currently (as of Minecraft 1.13-pre2) it is possible to use the '/execute store result' command to copy values from one data-source to another. This is only possible with the numerical types 'byte', 'double', 'float', 'int' and 'short'.

The ability to also use strings in this operation would have an enourmous impact on map-makers because it would allow completely new levels of player-command interaction while expanding on an already existing game mechanic.

Additionally I would suggest to add the players current username as a string into the player.dat structure. With direct access to the Players username mapmakers could use the new string-copying mechanic to create functionality that depends on the player's name, for example creating a player skull of a certain player. With this it would also be able to utilize the names of offline players (by storing it in a different entity).

Avatar
Registered User shared this idea

9 Comments

Please sign in to leave a comment.

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

    I have an update:

    It would also greatly improve the entire NBT handling via commands if next to what I've mentioned above the game would support an 'nbt' type, basically containing an entire NBT tag (and obviously its content.)
    Like this copying inventories, effects or other information could be done with just one '/execute store' call.

    The problem with both this and the 'string' type would - thinking about it - be the same.
    All data-types mentioned above are primitive (at least in terms of Java).
    Both the 'string' and 'nbt' would have to be handled as objects, and the size of them would vary.
    They could be everything from a few bytes to millions, which could be problematic and might slow the game down if used incorrectly.
    The thing is that every command can (if used incorrectly) theoretically slow the game down. It would still depend on how it would be implemented by the players, so the performance cost should be an irrelevant point.

  • 7
    Registered User commented
    Comment actions Permalink

    It's a nice idea, but /execute store and /data get only support numerical values.  If something like this were to be added in the future, it would be much better to have separate commands for them such as /execute write and /string or /read that could get and convert outputs into strings.    Separate  commands like this would also allow much more extendability, with features such as replace, trim, concat, join, split, substring, upper and lower casing, etc.

  • 0
    Registered User commented
    Comment actions Permalink

    Good idea.

  • 1
    Registered User commented
    Comment actions Permalink

    @MukiTanuki I know that they only store numerical types, I stated that above in my post, I simply requested that it should be expanded to one (or two, see comment) more types.
    Since the functionality would basically be the same, I think it would be the easiest way to integrate the functionality into the existing commands and it shouldn't lead to any downsides (besides the mentioned data-sizes).

  • 0
    Registered User commented
    Comment actions Permalink

    this would be very very useful! I ran in to this when I was trying to spread armor stands throughout the entire world, making them impossible to retrieve for they are in unloaded chunks. Now what I did was the following:
    I set up 3 command blocks which constantly store the armor_stands x, y and z values in scoreboard objectives. This will store their new location when you use /spreadplayers on them, making it possible to teleport to them. Now that's very useful, but I want to use tellraw to make a tp command from these scoreboard values like so:
    /tellraw @p ["",{"text":"/tp @p "},{"score":{"name":"@s","objective":"x"}},{"text":" "},{"score":{"name":"@s","objective":"y"}},{"text":" "},{"score":{"name":"@s","objective":"z"}}]
    And that works perfectly, but then I wanted to use the /execute store command to store that sentence in a commandblock, which I could then use to teleport to the armorstand. I started making the command and then I discovered that string saving is not a thing :(( I really hope this will be added in the near future!

  • 3
    Registered User commented
    Comment actions Permalink

    They should make it so you can trim a string too, and convert it to integer.

    So you can store sign text:
         Text1:'{"text":"195"}'
    to scoreboard as 195

    bacause if you try to get the text of a sign you only get as far as
         {"text":"195"}'

  • 5
    Registered User commented
    Comment actions Permalink

    You mostly get strings from /data get, and you can already copy strings from one location to another using /data modify

    So instead of using /execute store result storage <storage1> <path1> string run data get storage <storage2> <path2>, you can just use /data modify storage <storage1> <path1> set from storage <storage2> <path2>, which also works and is currently supported.

    I think it's more important to have a way to modify strings, like appending one string to another.

  • 1
    Registered User commented
    Comment actions Permalink

    we need list (or array) type for store UUIDs too!

  • 0
    Registered User commented
    Comment actions Permalink

    I would absolutely love that. From the very first time we got to try out execute store i was disappointed that strings weren't working. Now, years later, i see there has been no progress on this. Maybe because no one tried, maybe because it's impossible (or at least not economically viable).

    While ignoring all limitations, we could dynamically do everything you can basically do with commands in chat. Rename entities, redraw signs, change commands in commandblocks, basically edit everything that's nbt.

    And all we need for that is to be able to overwrite and append strings to nbt. Now back to reality, a system as general as this is probably hard to implement / very expensive to compute. But i'd love to see some attempts made in that direction.