Hey all, @John is considering using this Dual-Joystick Voxel Editor to officially replace the current Voxel Editor in future Codea updates.
In that case I’d really love to make sure it’s very solid, and to implement two last missing features, and I could really use some help.
I’d love help with three things specifically:
finding bugs
understanding how to implement a fill feature (converting all contiguous blocks of one color into the current selected color)
understanding how to implement a feature to bump the model in any direction by one pixel, and to wrap it around to the other side of the editor if it’s bumped past an editor boundary
(…and if anyone wants to pitch in with cleaning up/refactoring the code to remove extraneous bits and identify code smell, that wouldn’t be bad either)
I’ve made GitHub repositories for both the editor and the Voxel Player, and any and all are invited to join:
@UberGoober - this is a bit off the wall but I find the left hand zoom a little annoying. I think what it needs is a simple vertical rectangle for up down with no right/left input what do you think?
Also, it would help if you have a mini 3D map, say in the top left corner reflecting the 3D World so you know where your model is if it flies out of the viewing window. It may also be worth considering putting limits on your model and drawing the 3D axes up in the mini map.
@Bri_G I like how you’re thinking! If you want to take a stab at any of those things, I’d love to see what you come up with.
ATM personally I’m very focused on debugging and on adding the final two features it needs to be fully usable.
There seems to be some confusion about the dual-joystick system. The left stick isn’t a “zoom”.
This was originally called FPS Voxel Editor because you’re intended to feel you’re a player, not an impartial editor. You’re not just looking at it, you’re in it. I think the reason it feels so off is that people are expecting it to be a camera, but it’s not. The left stick isn’t supposed to feel like it’s moving a camera, it’s supposed to feel like it’s moving you.
I’m probably not going to implement ideas about that paradigm itself, but I’d be very interested in ideas about making it clearer.
@Bri_G having said that, can I talk over your ideas one by one?
1 - left hand controls - as mentioned, I’d rather clarify the current ones than replace them, but ideas to that end are welcome if they occur to you
2 - a mini 3D map seems hard for me to pull off easily, but if you think you know how to do it I would love to see your approach - OTOH the problem the mini-map would solve might be more easily addressable some easier way - like perhaps an arrow on screen pointing in the direction of the model if it’s out of view?
3 - I’m not sure what you mean by “putting limits on the model”, can you clarify?
4 - 3D axes on mini-map - again I’m intimidated by the task of making a mini-map at all, and I’m also not sure there aren’t easier ways to solve the same problems a mini-map would solve
@UberGoober - I’ll have a play with your code and try to add a little to it.
On the point of dual joypads I have always thought the following (wrt Minecraft/Voxel terrains):
There are two ways of viewing - first party and third party.
First party is from your own eyes ie you are not visible in the terrain.
Third party is usually offset, can either be locked behind the players character (always looking at their back and following their motion at fixed offset) or just offset fro the character can see the character turn and moves with a fixed offset in the same direction.
On that basis you have no control over up or down - you just follow the terrain and fall or climb (unless you provide a ‘grip’ function for ladders etc). So the right hand joypad rotates the character with the left/right (X axis on pad) and the up/down function provides motion forward or back.
The left hand joypad can be used for a camera looking at the world by rotating together with the right hand left/right movement but it should be a temporary motion whilst engaged - on release the view should return to straight ahead. The camera mode is only really of use in the first person mode.
If you set up a flying camera roving over the terrain your best bet is to use the right hand joypad for movement - forward/backward and rotation with a rectangle elevation up/down to move the camera in an arc around the Worlds core centre.
You could set up different modes but it could get very complicated.
@Bri_G left hand for ‘body’ control and right hand for ‘head’ control feels more natural to me—I think maybe it’s the standard on console games, but I wouldn’t claim that definitively.
It’s directly from @John’s Basic Player code, which is basically Minecraft, and specifically from the flying mode of the Basic Player.
On a fast iPad, there’s no controlling it. Control needs to be related to processor speed somehow. The .speed member in VoxelWalker defaults to 10. On my iPad, setting it to 1 is almost usable.
If there is a dead area in the left joypad, so that you can stop moving without lifting your thumb, I can’t find it. Either it’s not there, or it’s too small.
As for look direction, people’s taste varies. Some products even allow an easy way of choosing.
Finally, a question, and I think it is a tough one. Do we mean for the examples provided to be good examples? I assume we would answer “yes”, and then we need to decide what we mean by “good”. Some aspects of good to consider:
To what extent should it be easy to understand how the examples do what they do?
To what extent do we want the examples be easy to modify to get something similar but substantially different?
To what extent do we want them to have easily extra title bits that are useful as part of programs people write?
To what extent do we want them to include tests, to show people how they work, what to expect, and, almost accidentally, how to test their code?
To what extent should they show good Codea/Lua coding practices?
To what extent should they reflect overall good coding and design practices?
To what extent should they be object-oriented?
To what extent should they demonstrate interesting capabilities like fluent design, passing functions, pluggable behavior, …?
I think these just scratch the surface, but they begin to address things we might think about. Personally, I find the questions daunting, because I feel like the answers should be “to a great extent” for most of them, and I frankly do not know whether I am up to the task of meeting the standards for examples I’d like to see.
The most important thing to me in viewing an example is that I want to understand quickly “how it works”, because I am probably looking for a specific answer to some question like “how can I figure out what object my finger has touched”, and if the answer to that question is hidden deep inside, my needs are not met.
As an example, I did finally discover the .speed variable in VoxelWalker. It was the fourth tab I looked in, out of four, and until I found it, there was no possibility of trying out the program at all.
Examples are so valuable. How can we best provide them?
Somehow a little dude appeared. I’m not sure what I did to make that happen. I was never able to control the view to get a decent look at any desired side of him.
The buttons x|x y|y z|z. What are they? I tried all the other buttons and they did nothing because I was touching where the dude wasn’t. Finally noticed that the bomb was deleting. That clued me in on adding and selecting color to the patch.
I guess that wedge thing is a brush? It seems to color boxes.
It’s possible that I am a complete noob fool who doesn’t understand the simplest things, but I wasn’t able to have much success with the program. I’m not sure what I needed, but I sure needed something.
@RonJeffries wow great feedback, thanks so much. Not gonna be able to address that all at once (at least not by myself) so let’s start with the first thing: speed.
(I know that’s actually the second thing but the asset warning messages aren’t mine to fix, they come from the dependency on the built-in Block Library.)
Not only haven’t I the foggiest idea how to address the speed, I have no way to test it, because I don’t have a fast enough iPad to reproduce the issue. Does a setting of 0.1 feel less like a runaway train?
i guess what one wants is to move x number of blocks per second? so maybe speed is some number times the time since the last touch or update?? but i haven’t figured out how it actually works yet. anyway somehow i think we need to keep delta time in the equation.
@RonJeffries: on the question of what makes a good example project (let’s distinguish between projects and voxel models, because the first time I read that post I thought you were talking about models and I was confused), I think there’s another criteria that actually applies to the Editor more than anything else: does it make it more likely that people will use it to create voxel models for other projects?
When I got the editor working, specifically after I got mirroring working, I had a lot of fun making models. Having fun making models made me want to make projects that used models; it was a minor thrill, for example, to take my little sword-and-shield fantasy dude and put him in the froggy project and see him hop around.
So for me I’d like to see the Voxel Walker meet as high as possible a standard for helping people code things, I’d like the Voxel Editor to meet as high as possible a standard for helping people make things.
(btw the x|x, y|y, z|z buttons are the mirroring buttons, when you make or color a Voxel they make or color a Voxel on the flip side of the x, y, or z axis of the grid. For me mirroring is what makes it all fun. Mirroring was not implemented in the original Voxel editor)
Ok so I think we’re in a pickle there because doesn’t that mean the physics engine runs at different speeds on different devices? So we have to somehow calculate an amount of force to apply based on the resulting rate of travel depending on the device currently running it. Or is there another way?
now text appears on startup explaining the dual-stick paradigm
Editor now loads with an empty editing area and a much larger grid; some of Ron’s trouble came from not being able to tell what the editing tools did because the grid was so small and there was no indication that he should tap on it—now it’s hard not to tap on.
Main:26: BlockInventory:155: attempt to call a nil value (field ‘button’)
stack traceback:
[C]: in field ‘button’
BlockInventory:155: in method ‘slotButton’
BlockInventory:47: in field ‘init’
… false
end
setmetatable(c, mt)
return c
end:24: in global ‘BlockInventory’
BasicPlayer:21: in field ‘init’
… false
end
setmetatable(c, mt)
return c
end:24: in function <… false
end
setmetatable(c, mt)
return c
end:20>
[C]: in method ‘add’
Main:26: in function ‘setup’
stack traceback:
[C]: in method ‘add’
Main:26: in function ‘setup’
@RonJeffries There are three example programs that use the voxel player: the player itself, the block library, and the Voxel terrain. Can you see if any of them work?