Just installed 2.7, and the command-slash and command-minus don’t seem to work to comment / uncommenting lines any more.
IPad Pro, new one. Problem persists after restarting machine and Codea.
Is it just me?
@Simeon I loaded 2.7 and tried the OSC code that was crashing Codea on my iPad Pro when airplane mode was on. Codea doesn’t crash anymore but instead prints a message that says “Unable to start OSC server”. On my iPad Air, Codea doesn’t crash, but it prints the IP address like before but doesn’t give the “Unable to start OSC server” message.
@RonJeffries so sorry about this. Looks like I introduced this bug just recently. I’m sending another update through shortly so will fix this (and this time it should be approved faster, I’ve been told).
@dave1707 thanks for giving the OSC module another test. I think the second case you outlined might be because your iPad hasn’t realised it’s in airplane mode yet. You need to give it a good 10 seconds to kick in fully I’ve found. (Sometimes.)
@Simeon I checked airplane mode on my iPad Air and airplane mode wasn’t turning off my WiFi. I changed it so that it does and now in airplane mode on my iPad Air, I get the message “Unable to start OSC server”. So things work the same on both my iPads.
@Simeon - I don’t know how this works, so you’ll probably tell me that’s the design, but noFill() seems to turn off meshes if used before in the draw function. I was having a problem with emojis using the text() function as they were disappearing. I traced it to the noFill() call in draw(). Just after it I had a call for fill() with a background() adjustment. When I took that out the noFill() effect hit. Some code below for demo, I have been playing with this and still needs a little work to test all conditions.
-- TestText
displayMode(OVERLAY)
function setup()
--
parameter.color("back")
parameter.boolean("noF", false)
bkg = readImage("Environments:Night Up")
mX,mY = WIDTH/2, HEIGHT/2
myMesh = mesh()
sz = 480
-- build mesh and add texture
myMesh.vertices = {
vec2(200,200),vec2(200+sz,200),vec2(200,200+sz),
vec2(200,200+sz),vec2(200+sz,200+sz),vec2(200+sz,200)
}
myMesh.texture = bkg
myMesh.texCoords = {
vec2(0,0),vec2(1,0),vec2(0,1),
vec2(0,1),vec2(1,1),vec2(1,0)
}
-- take image and stretch to same size as mesh
itest = image(sz,sz)
spriteMode(CENTER)
setContext(itest)
sprite(bkg,sz/2,sz/2,sz,sz)
setContext()
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
background(77, 82, 94, 79)
fill(back)
if noF then
noFill()
end
myMesh:draw()
sprite(itest,240,700,480,480)
fontSize(128)
text(“",mX,120)
end
p.s. seen this before 2.7. Please add your own emoji in the text(). Checked on noFill() in reference and it does mention text colour switched off with it.
Edit: updated deleted redundant function an tidied. Note I think the noFill() just makes the emoji and mesh totally transparent.
@Bri_G Maybe this will help you understand what’s happening. The nof slider turns noFill on/off. The col slider sets the fill color (grey) from 255 to 0. The alp sets the alpha value from 255 to 0. So, if you slide the nof on, that’s equivalent to setting the col to 0 and alp to 0. If nof is off and alp is 255, changing the col gives varying intensity to the mesh. You can add r,g,b sliders instead of col, but that will just vary the color of the mesh.
function setup()
parameter.integer("col",0,255,255)
parameter.integer("alp",0,255,255)
parameter.boolean("nof",false)
bkg = readImage("Environments:Night Up")
myMesh = mesh()
sz = 480
myMesh.vertices = {
vec2(200,200),vec2(200+sz,200),vec2(200,200+sz),
vec2(200,200+sz),vec2(200+sz,200+sz),vec2(200+sz,200)
}
myMesh.texCoords = {
vec2(0,0),vec2(1,0),vec2(0,1),
vec2(0,1),vec2(1,1),vec2(1,0)
}
myMesh.texture = readImage("Environments:Night Up")
end
function draw()
background(0, 248, 255, 255)
if nof then
noFill()
else
fill(color(col,col,col,alp))
end
myMesh:draw()
end
@dave1707 - thanks for that, can’t remember seeing any references to this. Think the noFill() in-app references needs effect on emojis added. This came up whilst I was comparing mesh() with sprite() and text(emojis).
Text emojis seems a bit limited now.
Thanks again.
@Bri_G noFill() is basically a shortcut for fill(0,0,0,0) — do you think the behaviour should be different?
@Simeon - that explains my observations. My biggest surprise was that the mesh is subject to this command. I envisaged meshes as 3-dimensional sprites which you can use on a 2-dimensional plain.
@Bri_G it was an API design decision that I am now questioning. I thought if you don’t want to explicitly set vertex colours, being able to call fill() might be easier for some people. But it’s quirky.
@Simeon - looking at meshes they are about vertices, vectors and colours. The only issue I have is with sprites/textures. Don’t think it’s worth changing, nobody else has raised it. But, a little bit of info in the mesh reference section might avoid any issues later.
This question seems to have drifted. Simeon, in what version is the command-slash commenting fixed, please?
@RonJeffries it is not, sorry! I’ve just fixed it now. (Though 2.7.2 is already in review, so I’ll submit a new update as soon as that is approved.)
The fix will be in 2.7.3 which I’ll submit as soon as 2.7.2 is approved (or if it’s rejected, the fix will be in 2.7.2 and resubmitted as part of that update).