Raspbery Pi GPIO plugin

[Matouš]

Hi all!
I have created a small plugin to control your Raspberry's GPIOs from Minecraft!
You can use levers, buttons or torches as inputs or outputs to your pins and as a bonus there are self-updating signs that display some info about your Raspberry, which you can use.
More info on https://github.com/matemat13/MCserver-RaspberryGPIO.
A short (and ugly) video of it at work: http://www.youtube.com/watch?v=Y1ErAeNBC_0

It isn't the fastest thing on earth (although still usable without problems), more of a proof of concept, but if you have any suggestions or even want to contribute, I would be very glad!
I even wrote a C module for the Lua to speed it up but it seems even a bit slower (probably because of the C to Lua interface)...
It should be pretty easy to add more blocks and functionality by editing the Luas or the C module source code (whichever you choose to use).

Hope you guys like it!

By the way is there no API for creating plugins in C/C++? That could help quite a lot with the performance issues.
Other thing which could help would be rewriting this to be completely event-based (write rising and falling edge interrupts for the input pins in C and link them to Lua events or something, use OnPlayerUsedBlock for outputs like levers and buttons), but problem is with blocks like redstone torches, which have no event on change from active to inactive and vice versa... Any suggestions are welcome.

[xoft]

Hi, welcome to the forum.
WOW, this is impressive! Good work! Especially on getting an external Lua library to work.

Would it help if we modified Lua's require() function to look for binary modules in the plugin's folder first? That should make distributing the plugin much easier.

The natural idea that comes to mind is - assign an arbitrary block in Minecraft to be output of an IO pin - so that when that block becomes powered, the output pin is turned on.
This could be done by letting the user specify the blocks, then simply remembering them in an array and reading their state in OnWorldTick() - since there are only a small number of outputs, it shouldn't be too performance-crippling to check the few blocks. I'm not sure though if we have any method allowing you to access the redstone-power state of a block. Tigerw should know more.

Podle jmena a komentaru v kodu soudim, ze kolega?

---

Also, you don't need to require the other files in your plugin, all the Lua files in the plugin folder are loaded by MCS (in alphabetical order, except for Info.lua, which is always loaded last) before the Initialize() function is called.

[Matouš]

Thanks!
Actually the method you described is quite exactly what the script is doing - looping through an array and checking each block/input and setting each output/block in the array in every OnWorldTick(). Actually the user can even specify blocks (with a golden shovel) and assign them to the array, but so far only a few are implemented to actually do something (although that can easily be changed in the script).
The powered state of block is a good idea - so far I have been substituting this with using a redstone torch on the block (makes nice blinking LEDs with a simple circuit ).

As to the require path - it would certainly make it easier than specifying the full path (as different Raspberries can run different OSes).

And is there any way of creating a plugin in C++? Or would I have to recompile the whole server to add some code? Also some OnBlockChange hook would help maybe.

----------------------------------------------------------------------------------------------------------------------------------------------------
Jejda, já tam nechal nějaký český komentáře? Jsem to chtěl udělat čitelný i pro ostatní (ne-čechy), ale zvyk je zvyk Jinak jo, jsem z ČR, konkrétně okolí Prahy.

[xoft]

The description wasn't too clear on this, so I assumed it only worked by the players manually flipping switches. Having circuits in MC that can be "debugged" by real-world LEDs, or even MC circuits actually driving the RasPi outputs, that's cool. Now we need a robotics project, with a robot being controlled by MC redstone

Lua has predefined path on each platform where it searches for require-d libraries. See Lua docs about package.path and package.cpath. We can add the plugin's folder to those paths, so that including a binary within the plugin will work. However, personally I don't like the idea of binaries in plugins much, because MCS is too multi-platform and the binaries will make the plugins work only on some platforms. It's okay for a project like this that is very specific, but doing for example a DB driver this was would be quite unfortunate.

No, there's only Lua bindings. We've had other languages in the past, but they were dropped because the maintenance cost was too high and there was no added benefit for keeping them, everyone was using Lua anyway. There are no plans to change this in the foreseeable future., Lua is pretty fast and is good at what it does. If you believe otherwise, please supply a use-case that would support such an argument.

----
Njn, poprve jsem si to uvedomil u "Plugins/Moje", to jeste neni nic moc usvedcujiciho, ale treba https://github.com/matemat13/MCserver-Ra...n.lua#L261 uz ano. Jinak ja su prazak Za chvili uz nas tu bude dost na to, abychom udelali prazsky MCServer-con

[worktycho]

@xoft I've been thinking about C++ plugins myself (mainly caused by tigers concerns about bloat in the number of simulators). I think that there are some areas where being able to write plugins in C++ would be beneficial to performance (e. eg simulators or adding custom block handlers). leo most of the work involved in writing bindings is the decoupling I'm doing anyway for the generator. The main new thing would be a cross platform way of loading shared libraries. My personal view is that apart from loading them native C++ plugins would have a low cost apart from enforcing use of interfaces that I'm trying for anyway. However If you've tried this before and it was to costly please correct me.

[bearbin]

Lua is actually extremely fast, especially for an interpreted language. If you want to speed it up even more, i'd say go the LuaJIT route rather than a new language.

[tigerw]

Are the HOOK_BLOCK_POWERED and HOOK_BLOCK_UNPOWERED hooks good enough?

[xoft]

Tigerw, such hooks would most probably kill the performance whenever there's a bit more redstone. In this case the polling is actually the better way to go - there's some 16 blocks to poll per tick, compared to possible thousands of hook calls, each having to lock a critical section on a plugin.

However, this does bring me to an interesting idea - how about letting the plugins register callbacks for specific blocks being changed? Something like "If block at XYZ changes, call this function".

[tigerw]

Okay, you can do that then

Currently, I have a VLB (very large bug) concerning the recent refactoring and redstone: moving all the validity checkers to AddBlock was supposed to increase performance, and it does, unless AddBlock is being called loads of times! I think the solution to that would be to have per-chunk powered/linked powered lists, so a SetBlock operation in one chunk with no redstone won't affect the whole world.

Is storing the address of stuff in cChunk (but only using it within calls from SimulateChunk()) safe?

[bearbin]

What about derpstone current being carried across chunks?