A question. It’s a pain to copy / paste the code from my web site, as it is large. I could save it as a text file to click on, or as a zip file. I’m not quite up to doing a magic copy-to-clipboard function, as the code is heavily formatted on the site.
Which of text file or zip file would be easier for someone loading into Codea? I only know how to load a text file into Codea: is there even a way to load a zip? What third way might be better?
Thanks!
@RonJeffries - you can export your Codea file as a zip and then post that. Codea users can then open the zip, using the iOS system, with Codea. That should ease any issues with copy/paste.
p.s. I approach development in a similar manner, but - having a large amount of code accumulated of years of playing with Codea I tend to make shortcuts by building on existing code and refining. I must say often running into many issues, but then again it’s all learning.
how does one open a zip with codea?
@RonJeffries - provided the zip is an exported project from Codea - a long press on the zip file will bring up the sharing dialogue from iOS. Along the top is a row of icons relating to apps which may be able to open the zip. Codea should be one of them, select it and Codea is opened to import the file. If Codea is not in the top list then the far right icon allows you to select from a further list of apps (vertically displayed list) Codea may be in that list
Failing that under the icon row iOS shows a text list of options, one of which is Open With - that should get you there.
I find the whole iOS filing a bit of a mess but you can usually find an option that works.
The sharing list can be configured, up to a point, through iOS.
Oh, by the way it depends on which iOS version you are running.
Ah, good. Odd that to import a paste you long-press the + that adds a project and that that does NOT bring up a file accessor. Thanks!
@RonJeffries worked my way through the blog - really useful and informative. Two major takeaways for me so far:
Now using working copy - I would always get the FOBC (fear of breaking code) if I wanted to change stuff - and would copy and comment out working sections as a backup - unsustainable so glad I’ve found a painless alternative
Splats[self] = self : An alternative to the way I normally manage objects (which was sub optimal and messy) - still am not 100% comfortable with it but getting there
Really looking forward to seeing where you take it
Hi @West Yes, working copy is quite good, if a bit hard to set up. It has way more than I ever use and seems quite solid.
Yes, the Splats[self] thing is odd but seems to work more nicely than updating an array. I imagine odd things can still happen if you nil out one while looping but so far I’ve not seen a timing issue arise.
I look forward to seeing where I go too. 
It’s certainly fun.
so, i pretty much hate the controls on this game. was thinking about whether i could interpret swirling one or two fingers on the left as a turn, etc. there doesn’t seem to be a lot of support for such a thing. ideas? thanks!
@RonJeffries - there is a virtual joypad that has been used many times for ages. That could be a rotation control.
A ‘largeish’ area near the bottom right corner could take a tap for fire, doesn’t have to be a small circle. One thumb on the right and the other on the left could be an easy option.
Alternatively you could reduce screen size and place controls in a panel at the bottom.
Then again you could add mouse input with the new iOS features.
@RonJeffries You could do something like this to rotate the ship. Just slide your finger right or left. You can add whatever restrictions you want on it.
displayMode(FULLSCREEN)
function setup()
ang=0
end
function draw()
background(0)
translate(WIDTH/2,HEIGHT/2)
rotate(ang*2)
sprite(asset.builtin.Tyrian_Remastered.Boss_D,0,0)
end
function touched(t)
if t.state==CHANGED then
ang=ang-t.deltaX
end
end
@dave1707 thanks, i was thinking about something similar as we had supper, may give that a go.
@Bri_G i guess i could wait for mouse and pad support … 
thanks!
How about a multitouch control? Very short duration touches (taps) fires bullets. For longer touches the start of the touch acts as an anchor and the angle relative to the start controls the angle of the ship. A second touch while this is active would turn on the boosters applying a force at whatever direction the ship was pointing.
I’ve not had a look at the new gestures, which may make things simpler, but I’ve always relied on writing my own touch trackers. Let us know if you want me to share (though appreciate you are looking to figure things out by yourself for the purposes of the blog)
i like that idea of the “fixed” point and rotating around it. skips over the issue of recognizing something like a winding motion. thanks! got a few things to try now …
@RonJeffries - I envisage a broad circle with a smaller circle within which adheres to the edge, you can rotate the inner circle within giving the direction of ship.
Alternatively you could have a pointer from the centre to the edge.
@Bri_G Playing the game, I’m finding that a lot of my trouble is keeping my fingers in the designated areas. The circle idea seems to offer more of that trouble, though maybe I just don’t understand the idea.
For now, I’m going to try a simplified version of @West 's idea.
@RonJeffries - I find problems with touch controls, particularily with touches close to the screen limits - due to iOS sliding in other screens.
A crucial feature is how you hold your iPad. Do you place it on a flat surface? Hold it in one hand and control with another? Or, hold it on your knee with fingers behind lower corners and thumbs for use on controls. I usually favour the latter.
May be a good idea to generate a range of options to cover most eventualities in future projects.
my original plan was borrowed from my spacewar program, where you laid the ipad down and worked from opposite sides. for asteroids, more often i hold it in one hand on my lap. too many buttons for thumb only, i think.
agreed that there may need to be options. after trying a few this morning (boring article coming soon) i’ve found nothing i really love. bigger buttons is the next release.
How about something like this?
-- Tocuh based asteroid controls
-- by West
displayMode(FULLSCREEN)
function setup()
touches={}
tsup={} --tsup contains the supplementary info about the start position of the touch
pos=vec2(WIDTH/2,HEIGHT/2)
angle=0
end
-- This function gets called once every frame
function draw()
-- This sets a background color
background(32, 39, 75)
fill(100)
text("Tap to fire. Touch and move to rotate. Second touch to boost",WIDTH/2,HEIGHT*0.9)
noStroke()
--pretty rough touch counter - also no consideration given to touch order
local touchcount=0
for i,t in pairs(touches) do
touchcount = touchcount + 1
if touchcount==1 then
fill(255)
stroke(255)
--anchor
ellipse(tsup[i].tstartx,tsup[i].tstarty,10)
ellipse(t.x,t.y,10)
strokeWidth(2)
line(tsup[i].tstartx,tsup[i].tstarty,t.x,t.y)
--might want to limit this if the current touch is too close to the anchor
angle=math.deg(math.atan2(tsup[i].tstarty-t.y,tsup[i].tstartx-t.x))
else
--boost
pushMatrix()
translate(pos.x,pos.y)
rotate(angle+90)
translate(0,-50)
sprite(asset.builtin.Tyrian_Remastered.Flame_2,0,0)
popMatrix()
end
end
pushMatrix()
translate(pos.x,pos.y)
rotate(angle+90)
sprite(asset.builtin.Tyrian_Remastered.Boss_D,0,0,50)
popMatrix()
end
function touched(touch)
if touch.state==MOVING then
--record path
if tsup[touch.id]~=nil then
table.insert(tsup[touch.id].path,{pos=vec2(touch.x,touch.y),age=ElapsedTime})
end
end
if touch.state==ENDED or touch.state==CANCELLED then
processTouch(touch)
touches[touch.id] = nil
tsup[touch.id]=nil
else
touches[touch.id] = touch
--if there is no supplementary info associated with the current touch then add it
if tsup[touch.id]==nil then
tsup[touch.id]={tstartx=touch.x,tstarty=touch.y,starttime=ElapsedTime,path={}}
end
end
end
function processTouch(touch)
if ElapsedTime-tsup[touch.id].starttime<0.2 then
--FIRE!!
sound(SOUND_SHOOT, 47516)
--you may want a check to see if this is a second or subsequent touch - taps with an exisitng touch might want to be interpreted as boosts
end
end
interesting idea and implementation, use of tables. seems to be just about impossible to fire without turning. my main issue is that the original Asteroids did not have positive angular control, just constant rate of rotation. one of my experiments this morning used a different but equivalent implementation of the touch-hold idea to just trigger constant-rate turning, and i didn’t find it very playable. some may disagree. thanks!
How about segmenting the leftmost part of the screen as a giant fire button (say touch.x<width*0.15 then fire). Remainder of screen use the rotation control provided anchor point starts to the left of the fire button. Should get round the turning when you want to fire.