... yet you know how a bit painful it is to deal with block id and data value without knowing them by heart.
Which is why whoever tried to make a mod or simply use commands to place blocks had to look with care at Minecraft Wiki and blocks to find how to place a 'north inverted acacia stairs' or whatever mix of block ID and data value that will make you pull your hair.
Fortunately, we can already have it easier with names such as minecraft:log for example. Nevertheless, data value makes it that we still have to verify how to write it.
But, how?
Yes, how can we make the program recognize human writable names like 'big east cocoa', 'double oak slab' and the likes?
Well, with for example "east acacia log", "red wool" and "polished granite", the program would:
Segment analyze each different words (east, oak, log; red, wool; polished, granite)
Find the word(s) describing the model ("log"; "wool"; "granite")
Get the list of block id(s) associated with that model (log, log2; cloth; stone)
If more than one id, Narrow the block id with specific words (acacia: log2)
Form the data value associated with the block ID with the words (east acacia: 4; red: 15, polished granite: 1)
These 5 steps are relatively hyper-fast for a computer to do as opposed to a human having to read through documentation.
Relativity
As well as using absolute positions (North, South, East, West), we can use relative position, that is to say, front, left, right, back, that will be translated into the correct ones according to block faced.
Hmm... Could use some work, but definite support. Maybe have the human-writable part only apply to data values and not block ids and seperate some confusing ids?
Hmm... Could use some work, but definite support. Maybe have the human-writable part only apply to data values and not block ids and seperate some confusing ids?
The main reason for human writable ID and data value is that, for example,
Why ask people to remember that "cloth" means wool, while we can simply have a dictionary of synonyms?
As well, why have people remember that dark oak wood is found is minecraft:log2, while we can simply have "dark oak log" and the program will work its way to giving the correct block ID and data value?
And another, block states have orientation of pillars and logs recognizable by x, y or z. We can work with it but also have, again, a dictionary of synonym understanding that with pillar models, north-south, north, south and x all mean x and the likes for vertical and y.
And yet another, a powered comparator has a different ID from a comparator, but why remember when to use the underscore (_) when the program can have it all sorted out for us?
(I have a Deja-vu. Weird.)
Can you help point out what needs working as well?
Rollback Post to RevisionRollBack
Link RemovedImage RemovedLink RemovedImage RemovedLink RemovedLink RemovedLink RemovedImage RemovedLink Removed Link RemovedImage RemovedLink RemovedImage Removed
It is VERY hard to make that kind of string parser. It takes more work than you seem to think to code something that turns "dark oak log" into "minecraft:log:1".
It is VERY hard to make that kind of string parser. It takes more work than you seem to think to code something that turns "dark oak log" into "minecraft:log:1".
Not that much really. I'm programming in PHP and I could build this string parser with all possibilities.
And it's even easier since block state exist.
-Separate all words
-Find the word(s) defining the model or leading to it (podzol? dirt.)
-Get all block id related to the model
-If more than one block id possible, look at other words to find (acacia? log2)
-Look at the different block states and associate the word to data value ((variant:)acacia? +2; (position:)north?+1)
-Voila!
"Damaged north facing anvil"? facing is unnecessary but not problematic to write. Damaged is translated to +4. North? +0.
"up stone button"? Button gets merged with stone for the ID, and up is the facing part turned data value.
Rollback Post to RevisionRollBack
Link RemovedImage RemovedLink RemovedImage RemovedLink RemovedLink RemovedLink RemovedImage RemovedLink Removed Link RemovedImage RemovedLink RemovedImage Removed
I know parsers like this are possible, but a proof of concept would be nice. It seems like it would be a pain to implement since block states for directions and stuff are not currently standardized afaik. Which would make adding all of these separately a pain and standardizing it would require a converter on newer versions and still break command blocks that place blocks with specific states.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
I know parsers like this are possible, but a proof of concept would be nice. It seems like it would be a pain to implement since block states for directions and stuff are not currently standardized afaik. Which would make adding all of these separately a pain and standardizing it would require a converter on newer versions and still break command blocks that place blocks with specific states.
Thanks for pointing this out, I will make a proof of concept and come back on this topic with it.
Data value is relatively standardized and thus would be relatively easy to implement with no need for new version of data value either, since the other way around exists already in the code, otherwise we would not have data state.
Rollback Post to RevisionRollBack
Link RemovedImage RemovedLink RemovedImage RemovedLink RemovedLink RemovedLink RemovedImage RemovedLink Removed Link RemovedImage RemovedLink RemovedImage Removed
You may not have done...
... yet you know how a bit painful it is to deal with block id and data value without knowing them by heart.Which is why whoever tried to make a mod or simply use commands to place blocks had to look with care at Minecraft Wiki and blocks to find how to place a 'north inverted acacia stairs' or whatever mix of block ID and data value that will make you pull your hair.
Fortunately, we can already have it easier with names such as minecraft:log for example. Nevertheless, data value makes it that we still have to verify how to write it.
But, how?
Yes, how can we make the program recognize human writable names like 'big east cocoa', 'double oak slab' and the likes?
Well, with for example "east acacia log", "red wool" and "polished granite", the program would:
These 5 steps are relatively hyper-fast for a computer to do as opposed to a human having to read through documentation.
Relativity
As well as using absolute positions (North, South, East, West), we can use relative position, that is to say, front, left, right, back, that will be translated into the correct ones according to block faced.
Show your support!
Link RemovedImage Removed
Link RemovedImage RemovedLink RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Hmm... Could use some work, but definite support. Maybe have the human-writable part only apply to data values and not block ids and seperate some confusing ids?
The main reason for human writable ID and data value is that, for example,
Why ask people to remember that "cloth" means wool, while we can simply have a dictionary of synonyms?
As well, why have people remember that dark oak wood is found is minecraft:log2, while we can simply have "dark oak log" and the program will work its way to giving the correct block ID and data value?
And another, block states have orientation of pillars and logs recognizable by x, y or z. We can work with it but also have, again, a dictionary of synonym understanding that with pillar models, north-south, north, south and x all mean x and the likes for vertical and y.
And yet another, a powered comparator has a different ID from a comparator, but why remember when to use the underscore (_) when the program can have it all sorted out for us?
(I have a Deja-vu. Weird.)
Can you help point out what needs working as well?
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
It is VERY hard to make that kind of string parser. It takes more work than you seem to think to code something that turns "dark oak log" into "minecraft:log:1".
Putting the CENDENT back in transcendent!
Not that much really. I'm programming in PHP and I could build this string parser with all possibilities.
And it's even easier since block state exist.
-Separate all words
-Find the word(s) defining the model or leading to it (podzol? dirt.)
-Get all block id related to the model
-If more than one block id possible, look at other words to find (acacia? log2)
-Look at the different block states and associate the word to data value ((variant:)acacia? +2; (position:)north?+1)
-Voila!
"Damaged north facing anvil"? facing is unnecessary but not problematic to write. Damaged is translated to +4. North? +0.
"up stone button"? Button gets merged with stone for the ID, and up is the facing part turned data value.
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Worldedit did this. So definitley possible.
Nice to see you guys again.
Nice! Can you give an example?
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Up with added relative positioning - "front acacia stair" will turn into north facing acacia stairs when facing north.
Please show your support!
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
This would be very nice for those that are rather new to data tags and IDs N' stuff like that. Support.
I know parsers like this are possible, but a proof of concept would be nice. It seems like it would be a pain to implement since block states for directions and stuff are not currently standardized afaik. Which would make adding all of these separately a pain and standardizing it would require a converter on newer versions and still break command blocks that place blocks with specific states.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
Thanks for pointing this out, I will make a proof of concept and come back on this topic with it.
Data value is relatively standardized and thus would be relatively easy to implement with no need for new version of data value either, since the other way around exists already in the code, otherwise we would not have data state.
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Full Support!
GENERATION 37: The first time you see this, copy it into your signature
on any forum and add 1 to the generation. This is a Social experiment.
I just took the Minecraft Noob test! Check out what I scored. Think you can beat me?!
To take the test, check out
http://minecraftnoobtest.com/test.php