[Mod] TurtleMiner ... programmable turtles in Minetest

[octacian]

Underground, and in the dark, the darkgrey tech turtle is hard to see.
The 'digging' turtle (green, with yellow helmet) is much better in this regard.

For this reason, I've been considering making turtles emit a light level of 10 (3 less than torches, I believe). This would make it easier to find any turtle in the dark. What do you think? I'll experiment later and post a few screenshots.

[hajo]

Underground, and in the dark, the darkgrey tech turtle is hard to see.

For this reason, I've been considering making turtles emit a light level of 10
This would make it easier to find any turtle in the dark.

I was told that light-emitting nodes would cause too much lag.

How about a command like "/list-turtles", or
putting a dot for each turtle onto the minimap/radar ?

[octacian]

I was told that light-emitting nodes would cause too much lag.

How about a command like "/list-turtles", or
putting a dot for each turtle onto the minimap/radar ?

AFAIK, light emitting nodes do not cause lag in themselves. Maybe a little for client, but not enough to not do that type of thing. What you mean, is that lag could be caused by trying to attach a light-emitting node to a moving entity. However, turtles in TurtleMiner are not entities. In the future, I may experiment with using entities instead as they would allow for smooth movement. It'd probably be an option though, as it would be more resource intensive.

A command to list all the turtles doesn't seem like a very good idea. On a server, that list could get pretty large. Do you mean to list the position of your own turtles? Cause if that's not all, people could also find and destroy other's turtles. Still not really my preference as it'd unlikely that you'd lose your turtle unless you had a remote controller bound to it; and the formspec now has a button allowing you to get the turtle's coordinates.

As I mentioned earlier, turtles aren't entities. If that option is introduced in the future, I'll look into displaying them on the minimap. Right now, the only option would be to attach an entity, but I'm not sure that would be a good idea performance-wise.

[octacian]

Just pushed a commit giving turtles a light_source of 7. Tested at 5, 7, 10, and thought 7 looked the best. It makes both tech turtles and wild turtles far easier to see. I've attached screenshots of the tech turtle at 7 and 10.

[BirgitLachner]

The way to go is to save the def as rubenwardy suggested. However, I think that for now we should stick to getting the main "superturtle" working (if you'd like to call it that). That means text editor, visual editor, upgrades, inventory, etc...

In fact, I'd like to suggest that we remove all but the two basic types of turtle (tech turtle, animal turtle), and simply rely on the upgrades part which I'll be working on soon.

But, for now I think we should keep to our old goal, then worry about making different things for each turtle. Plus, doing this right now would likely conflict with what I'm currently working on, that being a tabbed formspec for accessing the different features (somewhat like the creative inventory).

Hmmm ... okay, I think I can live with it, but then I don't know what to do. I need to wait and promote the Mod ... or do you have other ideas?

[octacian]

Hmmm ... okay, I think I can live with it, but then I don't know what to do. I need to wait and promote the Mod ... or do you have other ideas?

I don't really have any other ideas. Give me a day or two to get the tabbed formspec working, and then go ahead. In fact, on second consideration, feel free to give it a go. However, I am changing the formspec system for the next-to-last time during this, meaning that things might break a little. The last time will be to allow a custom formspec (or sets of formspecs) to be registered in the def - unless you do so first.

[hajo]

Give me a day or two to get the tabbed formspec working,

Have you tried rubenwardy's turtleMiner & editor ?
That editor has tabs, for multiple 'files', that is as good as a remotecontrol,
and even more flexible.
I also made a fork of it, to add some little changes,
e.g. allow comments in the code.

[octacian]

Yes, I have. And I'm sorry (no offense to rubenwardy), but I personally dislike it. What I don't like, is that commands are not given to the robot in Lua, but in plain English. It just doesn't make sense to me. If this is an Education thing, why are we using English to command the robot? If we're trying to teach kids stuff, we should be using Lua. But, I'll leave it up to Birgit as to what happens here. I'm about to merge it with digicompute anyways, and then I'll make a Lua editor. I'll still contribute to this main project, but more effort will go to digicompute.

[rubenwardy]

Because the/my point is to teach children how a computer executes commands one after the other (which isn't obvious to children), not to teach them coding a real language yet. Syntax adds complexity. They can, ofc, progress onto lua later

[hajo]

I don't like, is that commands are not given to the robot in Lua, but in plain English.

Well, look at an oldtimer like COBOL
("COBOL has an English-like syntax, which was designed to be self-documenting and highly readable":)

If we're trying to teach kids stuff, we should be using Lua.

Lua is just one of many programming-languages.
And there are basic concepts to show/explain first,
like sequence / decision / loop / variables / counting / calculations etc.

The current turtles can just have a sequence of commands
(i.e. "mindless automation"), all the control remains with the user.
But just that can already be quite useful, see my Tutorial/digger.

From there, the next step would be to introduce checks & conditions,
e.g. check block in front, and decide if to move, turn or to dig, etc.

Then loops, because they need to check for their end-condition.
Also variables, counting & calculations, depending on the problem.

Now throw in some tips on how to organise code longer then a screenful.
Maybe introduce comments and functions along with that.
Etc, etc. until you have covered as much of the language as you want.

To start right off with lua, see basic_robot.
But there, you might have issues with the sandbox.
(e.g. when digging is limited to 1, user-programs might not work as expected...)

So, starting with a simple, dumb "DSL"-language might not be a bad idea.

[BirgitLachner]

Thanks for giving me the power to decide ...

Because the/my point is to teach children how a computer executes commands one after the other (which isn't obvious to children), not to teach them coding a real language yet. Syntax adds complexity. They can, ofc, progress onto lua later

Hmm ... well, I need to have a look at ComputerCraft, but as I do remember, the visual editor is of cause made/used to concentrate on the basic idea how executing commands happens. The step to the editor with code is even a step to use the syntax.

Look at that: http://computercraftedu.com/img/visual-editor.gif and http://computercraftedu.com/img/code-editor.gif
Both editor for the same code. You can even create the code in the visual editor and see the written code in the other editor.
The same in a video: https://www.youtube.com/watch?v=WMMaR4xkuZk

For me the code they use, doesn't look so difficult. It might be okay to use.

[octacian]

I agree with Birgit. The visual editor is in my opinion the best was to teach kids the basics as to how executing commands happens. And, a visual editor like that of ComputerCraftEDU is possible with formspecs to my knowledge, though it's not at all easy. Once kids understand the basics with the visual editor, they could then progress on to the text-based Lua editor.

PS: I've figured out how to use tabs, as I've already implemented them in digicompute. As soon as I get some time, I'll add an inventory to turtles. Then it's the Lua editor. I think we should leave features like the Ant button for kids/individuals to do themselves with the code editor.

[JulienPavageau]

I find that ComputerCraft is successful and the possibility of switching from the visual editor to the visual editor and vice versa is interesting but I am not sure that the beginners really benefits. As Octacian says it's not easy to develop and the profit for beginners seems pretty slim. Only the problem of syntax is removed, the loop or condition struts are not visible in the ComputerCraft's visual editor.
From my point of view it would be more useful to develop a really compatible LUA editor (with possibly some shorter instructions in addition) and to propose to the beginner a programming by blocks. As Brigit said at the beginning of the project, blockly can export to LUA and to learn to program it would be more profitable to have a web page under blockly with categories specially planned for minetest then one would proceed by simple copy / paste (or even better if you know how to do ...).
I take this opportunity to inform you that an article has just appeared where I speak a little of Turtleminer, "sorry" it is only in French : http://revue.sesamath.net/spip.php?article940 .

[mr_dean]

This is awesome! no, seriously though, this is really cool. I was thinking about trying to make a similar one, but using a Lua entity instead of a node, though my idea for programming it was with something similar to the "Lua Controller" from Mesecons but this is totally awesome!

[hajo]

This is awesome! no, seriously though, this is really cool.
I was thinking about trying to make a similar one

Maybe have a look at the Robots-Overview on the wiki.

What kind of tasks did you have in mind for your robot ?

[xisd]

I really like this idea I've been looking for something like that for a while (an in-game step by step way to teach and learn programming in lua).
I look forward to see it grow and if there is anything I can do to help, I would be glad to !

[octacian]

I really like this idea I've been looking for something like that for a while (an in-game step by step way to teach and learn programming in lua).
I look forward to see it grow and if there is anything I can do to help, I would be glad to !

Thanks for your interest! Turtles will soon have a Lua editor and will consume fuel. However, I may merge turtles into my own mod as it has a lot of the groundwork for editors done already, and seeing as robots and computers kinda go together, it makes sense.

However, for me anyways, development is kinda stalled as I just had an HDD failure and am still trying to recover vital data for my computer mod of over 500 lines.

[hajo]

Turtles will soon have a Lua editor and will consume fuel.

What kind of fuel - coal, or maybe some new stuff ?
That would present the problem of how to get that fuel,
turtles running out of fuel, etc.