@dave1707 you probably know how to help me with this:
I’m posting this as a discussion because I’m not seeing an answer to this specifically for CRAFT and having the answer on here will help people in the future:
Ok, so I’ve searched as best I can on the internet, and it seems that the in-app reference material being incomplete is a KNOWN issue. The external sources of further information I have found are extremely helpful but seem to have been made BEFORE craft was implemented.
Is there a source of complete reference information for craft? Have I missed it? I’m not seeing a discussion that points to the answer.
I’m currently reverse engineering the voxel system to make my own.
This line has two issues:
scene.voxels.blocks:addAssetPack("Blocks")
1: the reference in craft doesn’t tell me about it.
2: the output when playing the block library says “asset strings are deprecated”
I know what it does, it adds an asset pack the the blocks stored in the voxel system.
So I’m looking for the reference to see what the proper call is, and what it is expecting, and the reference is incomplete.
It’s less about knowing what it does, but having access to the reference to understand fully HOW it does it.
@Timmy_theBarbarian What you see is what you get. There isn’t very much documentation for Craft other than what you find in Codea which doesn’t give much. As for the “asset strings are deprecated”, that’s because the way assets are now used was changed since the blocks demo was created. The blocks demo hasn’t been updated to correct the deprecated warnings.
@Timmy_theBarbarian I have a lot of Craft code, but nothing as complicated as the Craft examples which is probably a good place to reverse engineer. I once asked for a Craft doc in the form of a Tree diagram so I could see how all the Craft commands are related to each other. That didn’t go anywhere.
I have started with the examples. A tree diagram is smart. That will be how i present it. I’m too dedicated to this tool to not have this information.
Do you have any simplified craft code that uses the voxel engine specifically? If so please PM me with it. It will help me get my bearings with the system as a whole and I can use the examples to fill in the rest.
Fact. I am currently constructing the flow tree aforementioned by @dave1707
I’m making 2.
1 == everything under craft
2 == a “project” tech tree from start to finish showing all the requirements for a base working program with the tree noting the parent - child relationships.
@Timmy_theBarbarian I don’t know how helpful this would be—potentially a lot, potentially not—but I had to wrangle with Craft a lot to create a texture pack:
I think a had to figure out at least one or two undocumented features, in particular the syntax for creating non-cube-shaped blocks, such as the piston and the cactus and the sign.
@UberGoober PRECISELY. I considered the idea of not worrying about it and muddling through. Then I realized I would be muddling in order to get to this level of understanding anyway. So I might as well make it comprehensive. The revamp will be welcome. Historically codea has always improved itself. I just hope it has code folding
@Bri_G EXACTLY! I want to understand how it WORKS. not how to get it to work.
@Timmy_theBarbarian in @John’s demo video of Craft there was a block that didn’t make it into the final release. It looked like a white spinning geodesic ball. It’s possible the code for that still exists even though it never got implemented—if you ever come across it please let me know!
@Timmy_theBarbarian I’ve no idea if this will be of any use to you but here it is anyway:
function gen_docs(table_name)
local f = io.open((asset.documents .. "docs_" .. table_name .. ".txt").path, "w")
-- Track processed values to avoid infinite recursion
local processed = {}
local function tree(key, v)
processed[v] = true
for kn,vn in pairs(v) do
-- We can't concatenate a userdata value
if type(kn) == "userdata" then
kn = "<userdata>"
end
local t = type(vn)
if t == "table" and not processed[vn] then
-- Recurse
tree(key .. "." .. kn, vn)
else
-- Add listing
f:write(key .. "." .. kn .. ": " .. t .. "\
")
f:flush()
processed[vn] = true
end
end
end
tree(table_name, _G[table_name])
print("table listing written to 'docs_" .. table_name .. ".txt'")
end
function setup()
gen_docs("craft")
end
This generates a full listing of everything contained in the craft table (including sub-tables) in Codea’s documents directory as ‘docs_craft.txt’
@Bri_G Excellent. This will speed things up. You focused on things I haven’t got to yet so it will help streamline the process. Thank you. I’m using MindNode for the maps. Haven’t decided how/if I will make the reference library. May not dedicate the time to a full reference. I am fully convinced @Simeon and friends will finish updating the reference library in future versions. In fact i am convinced that they have considered this need and have concluded that with the combined expressed information within the reference library, the code examples nested within said library, and the HORRIBLY commented examples provided with the shipped product, that we have all/most of the information required to utilize the tool in an at least good enough for now format.
@UberGoober I will pour over this and assimilate the information. Thank you good sir.
Another pertinent element is that sooner or later Codea 4 will come along and IIRC it will revamp both the 2D and 3D APIs. They say it will take a while but that’s a statement that’s open to interpretation.
@Timmy_theBarbarian - you’re welcome. I have always struggled with the hierarchy involved in Craft and wanted to understand it better. I’ll probably revisit this sometime with a little more focus - like what you need to produce (and in what order) to create an object. Also things like applying multiple textures or complex models involving several objects. Things that I haven’t fully cracked yet.
Alternatively, this will list everything globally accessible in a Codea Project:
function gen_docs(table_name)
local f = io.open((asset.documents .. "docs_" .. table_name .. ".txt").path, "w")
-- Track processed values to avoid infinite recursion
local processed = {}
local function write_listing(key, value)
if type(value) == "table" then
f:write(string.format("%s = table: %p\
", key, value))
elseif type(value) == "string" then
f:write(string.format("%s = \"%s\"\
", key, value))
else
f:write(string.format("%s = %s\
", key, value))
end
end
local function tree(key, v)
processed[v] = true
for kn,vn in pairs(v) do
-- We can't concatenate a userdata value
if type(kn) == "userdata" then
kn = "<userdata>"
end
kn = key .. "." .. kn
-- Write to file
write_listing(kn, vn)
local t = type(vn)
if t == "table" and not processed[vn] then
-- Recurse
tree(kn, vn)
end
processed[vn] = true
end
end
tree(table_name, _G[table_name])
f:close()
print("table listing written to 'docs_" .. table_name .. ".txt'")
end
function setup()
gen_docs("_G")
end
Here’s a version of the first program that lists the contents to the screen. It’s sorted and can be scrolled up or down.
viewer.mode=FULLSCREEN
function setup()
textMode(CORNER)
fill(255)
tab={}
dy=-40
gen_docs("craft")
table.sort(tab)
table.insert(tab,1,#tab.." Table entries")
end
function draw()
background(0)
for a,b in pairs(tab) do
text(a.." "..b,20,HEIGHT-a*20+dy)
end
end
function touched(t)
if t.state==CHANGED then
dy=dy+t.deltaY
end
end
function gen_docs(table_name)
local processed = {}
local function tree(key, v)
processed[v] = true
for kn,vn in pairs(v) do
if type(kn) == "userdata" then
kn = "<userdata>"
end
local t = type(vn)
if t == "table" and not processed[vn] then
tree(key .. "." .. kn, vn)
else
table.insert(tab,key .. "." .. kn .. ": " .. t)
processed[vn] = true
end
end
end
tree(table_name, _G[table_name])
end