-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add optional conversion to MineClone2, along with a few related fixes. #21
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,132 @@ | ||
=================================================================== | ||
Documentation for "map_content.txt" and "mcl2_map_content.txt": | ||
=================================================================== | ||
|
||
Documentation originally derived from: https://github.com/dgm3333/mcblocks/blob/master/map_content.txt | ||
Updated by MysticTempest | ||
-------------------------------------- | ||
The format of this file is: | ||
MCID data modname:blockname param2 | ||
17 0 mcblocks:Oak_Wood 4 //U | ||
|
||
or with optional preprocessor commands | ||
#if MORETREES | ||
18 4,12 default:leaves 1 | ||
#else | ||
17 default:tree // TODO: Trunk orientation | ||
#endif | ||
|
||
!!!! WHITESPACE TYPE (space or tab) IS CRITICAL:- !!!! | ||
|
||
({tab})MCID({space}MCData1(,MCData2(...))){tab}MTnodename({space}param2){tab}<==Everything beyond this tab is ignored. | ||
Tab characters at the beginning of the line are ignored. | ||
It is critical that tabs and spaces not be mixed up or the line won't be recognised correctly, | ||
and the parsing may fail to progress beyond that point. | ||
|
||
MCID and MCData must be separated by a space/s. | ||
MCData1,2,etc must be separated by commas but no spaces. | ||
There must also be no spaces before MCID or between MCData and the following tab. | ||
MCData must not be >=16, or the remainder of the file will be totally ignored. | ||
MCID/Data and MTnodename are separated by tabs. | ||
MTnodename and param2 are separated by a space/s. | ||
If MCData1 is omitted, the line will match MCIDs with MCData values from 0-15 (and any subsequent entries will be ignored) | ||
Any data following '//' is parsed and not processed | ||
preprocessor commands #if {NAME}, #else and #endif are recognised and intervening lines will be parsed | ||
out or retained dependant on flags in the content.read_content call | ||
|
||
Extra reference documentation: | ||
https://github.com/minetest/minetest/blob/2992b774fe65410a8acd3d06ae82dcd1eb260413/doc/lua_api.txt#L905 | ||
http://dev.minetest.net/minetest.dir_to_wallmounted | ||
http://dev.minetest.net/minetest.dir_to_facedir | ||
=============================================================================== | ||
Minetest uses these values for Wall-Mounted nodes(eg. torches, vines, etc..). | ||
Note that for Y values; it equates to which half of an air node it's in. | ||
Example: | ||
Ladders attached to the bottom of blocks are in the upper half of an air node. Hence are, 0. | ||
Ladders attached to the top of blocks are in the lower half of an air node. Hence are, 1. | ||
param2 direction | ||
0 //U +Y | ||
1 //D -Y | ||
4 //N +Z | ||
2 //E +x | ||
5 //S -Z | ||
3 //W -X | ||
|
||
|
||
-------------------------------------------------------------------------------- | ||
Minetest uses these values for nodebox face directions(eg. chests, Jack O'Lanterns, etc..). | ||
Values range from 0-23, and involve multiple vectors/rotations. | ||
A node's param2 value direction is dependent on a player's face direction. | ||
(ie. A player faces North, but a Jack O'Lantern faces South towards the player with a param2 value of '0'.) | ||
Default values for a node; vector pointing upwards: | ||
param2 direction | ||
0 //N | ||
1 //E | ||
2 //S | ||
3 //W | ||
|
||
------------------------ | ||
Vectors: | ||
------------------------ | ||
Vector points Up; rotation is around the North/South/East/West faces. | ||
0,1,2,3 | ||
Vector points North; rotation is around the East/West/Up/Down faces. | ||
4,5,6,7 | ||
Vector points South; rotation is around the East/West/Up/Down faces. | ||
8,9,10,11 | ||
Vector points East; rotation is around the North/South/Up/Down faces. | ||
12,13,14,15 | ||
Vector points West; rotation is around the North/South/Up/Down faces. | ||
16,17,18,19 | ||
Vector points Down; rotation is around the North/South/East/West faces. | ||
20,21,22,23 | ||
------------------------ | ||
Faces: | ||
------------------------ | ||
Player faces Down, node(eg. Jack O'Lantern) faces Upwards. | ||
0 degree: 4 | ||
90 degree: 13 | ||
180 degree: 10 | ||
270 degree: 19 | ||
|
||
Player faces Up, Jack O'Lantern faces Downwards. | ||
0 degree: 8 | ||
90 degree: 15 | ||
180 degree: 6 | ||
270 degree: 17 | ||
|
||
Player faces North, Jack O'Lantern faces South. | ||
0 degree: 0 | ||
90 degree: 12 | ||
180 degree: 20 | ||
270 degree: 16 | ||
|
||
Player faces East, Jack O'Lantern faces West. | ||
0 degree: 1 | ||
90 degree: 9 | ||
180 degree: 23 | ||
270 degree: 5 | ||
|
||
Player faces South, Jack O'Lantern faces North. | ||
0 degree: 2 | ||
90 degree: 18 | ||
180 degree: 22 | ||
270 degree: 14 | ||
|
||
Player faces West, Jack O'Lantern faces East. | ||
0 degree: 3 | ||
90 degree: 7 | ||
180 degree: 21 | ||
270 degree: 11 | ||
|
||
|
||
-------------------------------------------------------------------------------- | ||
Lastly, it appears some Minecraft Blockstates can be converted to data values. | ||
At least blockstates for axes(eg. Purpur Pillar, Bone Block, etc..). | ||
Example: | ||
Purpur pillar; default & on its side facing N,E,S,W; blockstate translation for X,Y,Z axes. | ||
202 0 mcl_end:purpur_pillar //Default, vector pointing upward, with a MC blockstate for Y | ||
202 4 mcl_end:purpur_pillar 12 //East,West pointing vectors with a MC blockstate for X | ||
202 8 mcl_end:purpur_pillar 6 //North,South pointing vectors with a MC blockstate for Z | ||
|
||
===================================================================================== |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -270,9 +270,6 @@ def isdoor(b): | |
# rotate lily pads randomly | ||
elif blocks[i] == 111: | ||
param2[i] = random.randint(0,3) | ||
# melon/pumpkin blocks | ||
elif blocks[i] == 86 or blocks[i] == 103: | ||
param2[i] = random.randint(0,23) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe I missed it, but, what was the reason this can be removed? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Melons don't need to be randomly rotated since they don't have any face. Pumpkins do have a face in mcl2/minecraft, so the code interferes with conversion of facedirs. |
||
# grass of varying length randomly | ||
elif blocks[i] == 31 and data[i] == 1: | ||
content[i], param2[i] = conversion_table[931][random.randint(0,4)] | ||
|
@@ -290,6 +287,43 @@ def isdoor(b): | |
alt = 964 | ||
if blocks[i] == 71: | ||
alt = 966 | ||
if blocks[i] == 193: | ||
alt = 968 | ||
if blocks[i] == 194: | ||
alt = 970 | ||
if blocks[i] == 195: | ||
alt = 972 | ||
if blocks[i] == 196: | ||
alt = 974 | ||
if blocks[i] == 197: | ||
alt = 976 | ||
content[i], param2[i] = conversion_table[alt][d_face|d_open|(d_right<<3)] | ||
if d_right == 1: | ||
self.metadata[(i & 0xf, (i>>8) & 0xf, (i>>4) & 0xf)] = ({ "right": "1" }, {}) | ||
# re-add code for converting top part of door for MineClone2, ignored for Minetest Game | ||
elif isdoor(blocks[i]) and data[i] >= 8: # top part | ||
below = i - 256 | ||
if (below < 0): | ||
logger.warning('Unable to fix door - bottom part is across block boundary! (%d < 0)' % below) | ||
elif isdoor(blocks[below]) and data[below] >= 8: | ||
logger.warning('Unable to fix door - top part 0x%x below top part 0x%x!', data[i], data[below]) | ||
else: | ||
d_right = data[i] & 1 # 0 - left, 1 - right | ||
d_open = data[below] & 4 # 0 - closed, 1 - open | ||
d_face = data[below] & 3 # n,e,s,w orientation | ||
alt = 965 | ||
if blocks[i] == 71: | ||
alt = 967 | ||
if blocks[i] == 193: | ||
alt = 969 | ||
if blocks[i] == 194: | ||
alt = 971 | ||
if blocks[i] == 195: | ||
alt = 973 | ||
if blocks[i] == 196: | ||
alt = 975 | ||
if blocks[i] == 197: | ||
alt = 977 | ||
content[i], param2[i] = conversion_table[alt][d_face|d_open|(d_right<<3)] | ||
if d_right == 1: | ||
self.metadata[(i & 0xf, (i>>8) & 0xf, (i>>4) & 0xf)] = ({ "right": "1" }, {}) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we maybe include a (lua) example function that converts the old coordinates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly? I'm not sure how that'd work. I just know that converted maps don't keep the player's save location; so spawning into an imported map requires flying/teleportation to the converted area. And, it's quickest if users know the coordinates beforehand so they have a rough idea of where to look.