46 posts
Posted 29 June 2015 - 09:29 PM
After seeing Lion4ever's parkour, I thought about making a modular parkour, where anyone can make parts and mix them together.
So I made a type of parkour, where different structures are plugged together.
Basically this is a program that loads other programs that feed the main program structures so the main program can put them together. :P/>
So you dont have to do the dirty work.
Every structure is an external file, which is loaded and used to make a parkour.
For example, you could have a structure which is one floating block, and a structure of a floating block with a ladder.
Then, you would find floating blocks and ladders forming a path for you to jump.
The idea is that people make their own structures, and upload them to the centralized store.
Then anyone can just download and use them.
-Multiplayer and different gamemodes, where every player plays the exact same parkour.
-Monitor interface, no deleting/downloading, for survival or non-OP players.
-Takes into account that players may have items before playing, and as such, stores them safely before starting.
-Configurable with "parkour_config"
-Enabling/Disabling of structures to create your customized parkour.
-Structure store, with structure versioning and descriptions.
-Changeable difficulty
Main monitor interface.
Main computer interface.
The store.
Monitor player selection.
Inside the parkour.
This is actually more of a tutorial. This is updated to V1.2
Please play the parkour before reading the guide. It will help you understand how it works.
The guide assumes you know lua and lua tables.
Every structure file is just a lua program that returns a table.
Your lua file will be run, and will be expected to return special results, that define your structure.
First of all, the most basic structure would be like this:
The first element of this table will always be a string, and will be one of a set of strings.
But the one we are interested in is "build".
When your script is called with a "build" argument, you must return a structure table, which in turn must contain a series of element in it:
First we will start with blocks.
The blocks table contains a other tables, which represent every block in the structure.
An example would be:
Every structure has a checkpoint, the obsidian block.
The coordinate 0,0,0 is the checkpoint block from the structure before yours.
Sometime the checkpoint of the structure before yours is replaced with an obsidian block. In this case it is obvious were the checkpoint is.
Even when the obsidian block isn't there, the checkpoint is there, as an abstract location.
The coordinate 1,0,0 is one block FORWARD the previous structures' checkpoint (the ocasional obsidian block).
What this would do, is turn this:
into this:
To actually implement this you would do:
Since the elements in the table are the arguments fed to setblock, you can feed meta, oldblockhandling and NBT tags.
Just make sure the first 3 elements are numbers.
The next one is areaCheck:
This is a table of tables, just like blocks, but the function of this one is to check you are inside the structure and haven't fallen.
Example:
So to implement both blocks and areaCheck:
The next is exit:
Exit is the place of your checkpoint, (the ocasional obsidian block), the block that will be considered 0,0,0 for the following structure.
So, remember we had stone on 0,0,0 and 1,0,0?
Now the checkpoint will be in 2,0,0, so if the parkour places an obsidian in our checkpoint we will make a line of blocks:
This would be done as such:
If there is no obsidian in 2,0,0 (the parkour didn't decide to put a checkpoint) you will just be able to jump from there to the next structure, maybe even another of your structures.
The obsidian is autoplaced on your exit coordinate when a checkpoint has to be placed, so make sure you plan for it.
The next one is "next":
Our structure is just a straight line, but what if it turned to the right? How would the next structure know?
'next' does this.
The parkour understands 4 orientations:
The parkour program handles all the rotations. You just need to give it orientations.
The "forward" orientation is "x+", which means that if you set "next" to "x+", no direction change will apply.
But if we want the next structure to be 90° to the right, we would set next to "z+".
Or if we wanted it to be just in the opposite direction we started (eg. our structure is a U-turn) we would set next to "x-".
For this example, we will set it to "z-", and make the next structure be 90° to the left(counterclockwise).
This is because floating blocks(and most structures) work with angles, and the next structure must know the previous' structure angle.
How does this work? With numbered next values.
Look carefully at this image:
So the structure chooses a new angle based on the previous angle, and feeds it into the next structure through "next".
The next structure can get this value through args[2] (it is the second argument fed to the structure when "build"ing)
So to get the previous angle, turn a little to the right, and feed it into the next structure:
And finally, the easiest one of all: "length".
Length is just the difficulty of your structure. 100 means a checkpoint should be placed right after this structure.
1 means that 100 structures should be built before the next checkpoint, 50 means 2 structures should be built before the checkpoint, etc…
This is all in normal difficulty. Normal difficulty has a "checkpointStride" of 100, which means that 100 structures of length 1 should be placed before the next checkpoint.
Hard has a checkpoint stride of 150, and easy has a checkpoint stride of 60. This means the harder your structure is, the higher your length should be.
It would be like this:
You can copy paste it into "/stuctures/guide" (or even better, write it yourself) and then run the parkour with 'Guide' activated to see what happens.
You can also download and check 'Floating Blocks', which is heavily commented to explain how it works. You are also free to modify it to create your own, you dont have to credit me.
To download V1.21(latest), use
Or, if you had the parkour previously, just let it update, it will try to do it by itself.
And if you reached the bottom of this post, and didn't understand anything, just give it a try and you'll very probably understand.
Stupid color tags.
So I made a type of parkour, where different structures are plugged together.
Basically this is a program that loads other programs that feed the main program structures so the main program can put them together. :P/>
So you dont have to do the dirty work.
Every structure is an external file, which is loaded and used to make a parkour.
For example, you could have a structure which is one floating block, and a structure of a floating block with a ladder.
Then, you would find floating blocks and ladders forming a path for you to jump.
The idea is that people make their own structures, and upload them to the centralized store.
Then anyone can just download and use them.
Main Features
-Modular, easy-to-make structures, the easiest way is to edit one of the already made ones.-Multiplayer and different gamemodes, where every player plays the exact same parkour.
-Monitor interface, no deleting/downloading, for survival or non-OP players.
-Takes into account that players may have items before playing, and as such, stores them safely before starting.
-Configurable with "parkour_config"
-Enabling/Disabling of structures to create your customized parkour.
-Structure store, with structure versioning and descriptions.
-Changeable difficulty
Images
Main monitor interface.
Main computer interface.
The store.
Monitor player selection.
Inside the parkour.
Structure Development Guide
This is actually more of a tutorial. This is updated to V1.2
Please play the parkour before reading the guide. It will help you understand how it works.
The guide assumes you know lua and lua tables.
Every structure file is just a lua program that returns a table.
Your lua file will be run, and will be expected to return special results, that define your structure.
First of all, the most basic structure would be like this:
args={...}
if args[1]=="build" then
return [structure table here]
end
The first element of this table will always be a string, and will be one of a set of strings.
But the one we are interested in is "build".
When your script is called with a "build" argument, you must return a structure table, which in turn must contain a series of element in it:
First we will start with blocks.
The blocks table contains a other tables, which represent every block in the structure.
An example would be:
{
{0,0,0,"stone"},
{1,0,0,"stone"}
}
Every structure has a checkpoint, the obsidian block.
The coordinate 0,0,0 is the checkpoint block from the structure before yours.
Sometime the checkpoint of the structure before yours is replaced with an obsidian block. In this case it is obvious were the checkpoint is.
Even when the obsidian block isn't there, the checkpoint is there, as an abstract location.
The coordinate 1,0,0 is one block FORWARD the previous structures' checkpoint (the ocasional obsidian block).
What this would do, is turn this:
into this:
To actually implement this you would do:
args={...}
if args[1]=="build" then
return {
blocks={
{0,0,0,"stone"},
{1,0,0,"stone"}
}
}
end
Since the elements in the table are the arguments fed to setblock, you can feed meta, oldblockhandling and NBT tags.
Just make sure the first 3 elements are numbers.
The next one is areaCheck:
This is a table of tables, just like blocks, but the function of this one is to check you are inside the structure and haven't fallen.
Example:
{
{0,0,0,5},
{3,0,0,4}
}
So to implement both blocks and areaCheck:
args={...}
if args[1]=="build" then
return {
blocks={
{0,0,0,"stone"},
{1,0,0,"stone"}
},
areaCheck={
{0,0,0,5},
{3,0,0,4}
}
}
end
The next is exit:
Exit is the place of your checkpoint, (the ocasional obsidian block), the block that will be considered 0,0,0 for the following structure.
So, remember we had stone on 0,0,0 and 1,0,0?
Now the checkpoint will be in 2,0,0, so if the parkour places an obsidian in our checkpoint we will make a line of blocks:
This would be done as such:
{2,0,0}
args={...}
if args[1]=="build" then
return {
blocks={
{0,0,0,"stone"},
{1,0,0,"stone"}
},
areaCheck={
{0,0,0,5},
{3,0,0,4}
},
exit={2,0,0}
}
end
If there is no obsidian in 2,0,0 (the parkour didn't decide to put a checkpoint) you will just be able to jump from there to the next structure, maybe even another of your structures.
The obsidian is autoplaced on your exit coordinate when a checkpoint has to be placed, so make sure you plan for it.
The next one is "next":
Our structure is just a straight line, but what if it turned to the right? How would the next structure know?
'next' does this.
The parkour understands 4 orientations:
z-
x- x+ -> Forward
z+
The parkour program handles all the rotations. You just need to give it orientations.
The "forward" orientation is "x+", which means that if you set "next" to "x+", no direction change will apply.
But if we want the next structure to be 90° to the right, we would set next to "z+".
Or if we wanted it to be just in the opposite direction we started (eg. our structure is a U-turn) we would set next to "x-".
For this example, we will set it to "z-", and make the next structure be 90° to the left(counterclockwise).
next="z-"
args={...}
if args[1]=="build" then
return {
blocks={
{0,0,0,"stone"},
{1,0,0,"stone"}
},
areaCheck={
{0,0,0,5},
{3,0,0,4}
},
exit={2,0,0},
next="z-"
}
end
This is because floating blocks(and most structures) work with angles, and the next structure must know the previous' structure angle.
How does this work? With numbered next values.
Look carefully at this image:
So the structure chooses a new angle based on the previous angle, and feeds it into the next structure through "next".
The next structure can get this value through args[2] (it is the second argument fed to the structure when "build"ing)
So to get the previous angle, turn a little to the right, and feed it into the next structure:
args={...}
if args[1]=="build" then
previousAngle=args[2]
return {
blocks={
{0,0,0,"stone"},
{1,0,0,"stone"}
},
areaCheck={
{0,0,0,5},
{3,0,0,4}
},
exit={2,0,0},
next=previousAngle+0.2
}
end
And finally, the easiest one of all: "length".
Length is just the difficulty of your structure. 100 means a checkpoint should be placed right after this structure.
1 means that 100 structures should be built before the next checkpoint, 50 means 2 structures should be built before the checkpoint, etc…
This is all in normal difficulty. Normal difficulty has a "checkpointStride" of 100, which means that 100 structures of length 1 should be placed before the next checkpoint.
Hard has a checkpoint stride of 150, and easy has a checkpoint stride of 60. This means the harder your structure is, the higher your length should be.
It would be like this:
length=10
args={...}
if args[1]=="build" then
previousAngle=args[2]
return {
blocks={
{0,0,0,"stone"},
{1,0,0,"stone"}
},
areaCheck={
{0,0,0,5},
{3,0,0,4}
},
exit={2,0,0},
next=previousAngle+0.2,
length=10
}
end
You can copy paste it into "/stuctures/guide" (or even better, write it yourself) and then run the parkour with 'Guide' activated to see what happens.
You can also download and check 'Floating Blocks', which is heavily commented to explain how it works. You are also free to modify it to create your own, you dont have to credit me.
To download V1.21(latest), use
pastebin get wbW5e1ZD parkour
parkour
Or, if you had the parkour previously, just let it update, it will try to do it by itself.
And if you reached the bottom of this post, and didn't understand anything, just give it a try and you'll very probably understand.
Stupid color tags.
Edited on 13 September 2015 - 03:37 PM
