@RonJeffries Also, unless you’ve made any modifications to the examples that you’d like to save, could you try the “reset examples” button and see if the problem persists?
I did do a reset, but still only tried the player. I’ll try the others too.
I think the issue is that BasicPlayer is not getting added, the player = is returning nil. BlockLibrary fails right away, terrain fails when you try to spawn player. I don’t think I have the time/energy to dig into it just now. I’ll let you know if I find anything.
This is so broken. Clearly no one has run these for ages. What is the correct new formula for:
grass.setTexture(ALL, "Blocks:Dirt Grass")
I can at least get rid of the asset problems and see what happens next.
Tried this:
grass.setTexture(ALL, asset.builtin.Blocks.Dirt_Grass)
Got this:
…73BDE4/Codea.app/Frameworks/CraftKit.framework/block.lua:68: bad argument #3 to ‘value’ (string expected, got userdata)
stack traceback:
[C]: in upvalue ‘value’
…73BDE4/Codea.app/Frameworks/CraftKit.framework/block.lua:68: in field ‘setTexture’
Basic:47: in function ‘basicBlocks’
Blocks:3: in function ‘blocks’
Main:23: in function ‘setup’
@RonJeffries In one of my projects, I use this.
scene.voxels.blocks:addAssetPack("Blocks")
grass = scene.voxels.blocks:new("Grass Top")
grass.setTexture(ALL, "Blocks:Grass Top")
don;y you get asset warnings from those?
they have started to work on the ipad i tested on last night. does it take time to refresh or something? i’m quite confused now.
OK. I guess restoring examples just takes a while and doesn’t tell you that or when its done. All the example @UberGoober asked about run on both my iPads.
Isn’t there some way to type asset and then tap it to get the asset browser open? I can’t make it work in setTexture, which is where I tried it.
Ron, now that they are running, can you tell me if they have the same speed issues as the voxel walker?
next time i’m on that ipad.
The original voxel player is not too fast on my iPad. But the new one moves at direction normalized * speed, which is 10. I think the original moves x = x + 1 or y = y + 1.
That’s less. 
Using the “rigs” approach I tried out here I’ve pretty much entirely re-structured the Dual-Joystick Voxel Player (née Voxel Walker).
As a result I got a little clearer on how the parts fit together, and I was able to make the camera jump between a third-person and a first-person point of view, as seen in the video.
It’s kind of cool, but it’s not really usable in a game, because I don’t know how to turn the player-model to always face the direction it’s moving, and I don’t know how to smoothly swivel the camera around as the player moves so that the camera is always looking at the player-model from behind.
@dave1707, @West, @Bri_G, anyone else who’s fiddled with Craft—can you give me tips on how to swivel the body and the camera around so they face the right direction at all times?
[project updated and moved below]
@UberGoober Here’s something I have that moves the camera around. There’s an invisible joystick, so move your finger in the direction you want to go. Up to move forward, down to move back, left or right to turn left or right.
viewer.mode=FULLSCREEN
function setup()
bx,bz,sx,vel,dir=0,0,0,0,0
scene = craft.scene()
ground=scene:entity()
ground.model = craft.model.cube(vec3(1000,1,1000))
ground.position=vec3(0,-5,0)
ground.material = craft.material(asset.builtin.Materials.Standard)
ground.material.map = readImage(asset.builtin.Surfaces.Desert_Cliff_Normal)
ground.material.offsetRepeat=vec4(0,0,10,10)
cam = scene:entity()
cam:add(craft.camera, 60, .1, 1000, false)
end
function update(dt)
scene:update(dt)
cam.eulerAngles = vec3(0,180+dir,0)
bx=bx-vel*math.sin(math.rad(dir))
bz=bz-vel*math.cos(math.rad(dir))
cam.position=vec3(bx,0,bz)
end
function draw()
update(DeltaTime)
scene:draw()
dir=dir-sx/5
joyStick()
end
function joyStick()
if show then
d=vec2(cx,cy):dist(vec2(x,y))
if d<50 then
px,py=x,y
else
px=(x-cx)*60/d+cx
py=(y-cy)*60/d+cy
end
d1=vec2(px,py):dist(vec2(cx,cy))
sx=(px-cx)/(d1/4+.01)
vel=((py-cy)/(d1/4+.01))/20
end
end
function touched(t)
if t.state==BEGAN then
cx,cy=t.x,t.y
x,y=cx,cy
show=true
elseif t.state==MOVING then
x,y=t.x,t.y
elseif t.state==ENDED then
show=false
end
end
@dave1707, thanks, this looks promising — and so the idea is that if the camera is a child of the rotating model, it will just swivel as the model swivels, automatically keeping it in the right place behind the model (assuming it’s in third person view)?
@RonJeffries pointed out that my “rig” system, because it adds properties and functions directly to craft entities, risks blundering into conflicts with other code, and also makes it hard for readers to distinguish between properties I’ve added to entities and properties that are baked-in.
I think it’s a darn good point and so I’ve moved almost all the custom properties into a separate table, entity.rig.
I made two kinds of exceptions:
-
The whole point of the cameraEntityThing is to be able to treat the camera and the entity as one object as much as possible, so I’ve left in place the entity’s getter/setters for camera properties.
-
Any customizations of standard cycle-update functions (like draw, update, touched, and touchHandler-related functions) remain as direct modifications on the rigged entities. Customizing these specifically seems like a very standard Codea design pattern, and one that’s even expected in some cases, so that feels right.
Ron, could you tell me if this helps make it easier to understand? We may not agree on teasing this code into separate objects and classes, but I very much agree that it should be easily understood.
[file moved to lower post]
I’ll have a look as time permits. I might take my tutorials down a camera path, and it’d be interesting to see what I’d do.
But now, remain aware that while I do have a good sense of “good code”, a lot of it is subjective, not necessarily so. It’s just what I like, seasoned with a lot of history. That doesn’t make me right. 
You make good points, as always, and you are generous with respecting other approaches, also a good thing I think.
Your interrogation of the qualities a good example project needs is very valuable to me, and I also very much appreciate your perspective on how well or poorly these projects meet those standards.
So I guess all I’m saying is: thanks. 
thank you for paying attention, and more for getting something out of my ravings
i think since joystickView is a child of entity, its update will get called when the parent’s is. is that not the case?