If a vector range goes backwards, the blocks setter doesn't currently notice. We should issue a warning and then ignore the request

from picraft import World
from os import environ

world = World(environ["ADDR"])
world.events.main_loop()

this code causes

Traceback (most recent call last):
  File "minimal.py", line 5, in <module>
    world.events.main_loop()
  File "/usr/local/lib/python3.5/site-packages/picraft/events.py", line 376, in main_loop
    self.process()
  File "/usr/local/lib/python3.5/site-packages/picraft/events.py", line 392, in process
    for event in self.poll():
  File "/usr/local/lib/python3.5/site-packages/picraft/events.py", line 352, in poll
    events = list(player_pos_events(self._track_players)) + list(block_hit_events())
  File "/usr/local/lib/python3.5/site-packages/picraft/events.py", line 347, in block_hit_events
    s = self._connection.transact('events.block.hits()')
  File "/usr/local/lib/python3.5/site-packages/picraft/connection.py", line 298, in transact
    return self._receive(required=True)
  File "/usr/local/lib/python3.5/site-packages/picraft/connection.py", line 250, in _receive
    raise NoResponse('no response received')
picraft.exc.NoResponse: no response received

tested with Python 3.5 and this server

Getting and setting blocks accepts a slice with a step other than 1,1,1 but the underlying bulk functions don't permit this. Fallback on individually enumerated gets/sets in this case.

Dave can't spell picraft in MANIFEST.in...

Not entirely sure how we can extend the event decorators to work on methods in classes. This may require an additional decorator on the class itself plus some magic to register instantiations ... should investigate this for 0.6 though.

Test coverage is dropping as we add more bits. Need to figure out how to accurately test the multi-threaded event handling logic, and get test coverage back up to 99% for 1.0.

Might be nice to include some (can't be that hard given it's a pure Python package with almost no dependencies?)

Need to add a routine (or optional parameter to lines?) to generate filled polygons. The brute force method of sorting the vectors and filling all intervening points looks okay if we use a set to remove all the duplicates (the likely use-cases aren't enormous so the memory use is unlikely to be excessive).

Looks like there's an easier option than Raspberry Juice: https://www.instructables.com/id/Python-coding-for-Minecraft/

Oh, and add a link to https://github.com/JuliaBerry/PiCraft.jl while you're at it!

The half-open nature of vector_range is resulting in an awful lot of "+1"s in code. This is the sort of thing that half-open ranges were meant to avoid. Before we go plunging into 1.0 (and frankly before the package becomes too popular (assuming it ever will!)), we should think about whether there's a good argument for using closed ranges instead. It might be that the vector use-case is sufficiently different to strings et al in Python that it's justified ...

As stated in the title, using World().blocks[Vector(a, b, c)] returns a block with its proper data value, but World().blocks[Vector(a, b, c):Vector(d, e, f)] returns a list of blocks with the data value inevitably set to 0, regardless of the block's actual data value in Minecraft.

The Raspberry Juice mod supports getting multiple blocks at a time; we should support this implicitly in the blocks getter

The Makefile already generates these - just got to check with the Raspbian maintainers that they're happy for me to include them in the repository. Ought to do this for 0.4 to enable people to test stuff a bit more easily (that might even make 0.4 ready enough to call it 1.0).

Need lots more recipes, including ones covering absolutely basic functionality (along the lines of the introductory recipes in the Basic chapter of picamera). Wouldn't hurt to have a lot more screenshots in there too (actually it would hurt the docs package which is already several hundred kb, but oh well).

Translation and scaling of vectors is already pretty simple, just need to add decent support for rotation now. I'm thinking something along the lines of a rotate method for rotation about an arbitrary (non-origin fixed) line, and maybe derivative methods for rotation about the three axes, and rotation about an origin-fixed direction vector. Alternatively, it might be enough to provide default args to the generic method... Need to have a play and see what performs well.

I know that the minecraft API doesn't allow this on pi's, but does on raspberry juice.

However I know direction of movement has been implemented here:

http://www.stuffaboutcode.com/p/adventures-in-minecraft-forum.html?place=msg%2Fadventures-in-minecraft-forum%2Fxj6_42BrBAY%2FrEuwnB5gv98J

I want to try write up an algorithm to find a players direction of movement and move it into this library.

I can't have the direction I'm facing on a pi but I'd settle for movement and know others would as well.

Let me know your opinion on it.

We've got an implementation of Bresenham for lines - now how about another one for circles, and if possible general ellipses? There's several good references for these but they all seem to be 2D. That's probably enough for starters, but it'd be nice to have a completely generic 3D one (that can draw an ellipse on an arbitrary plane), if such a thing exists.

You've got Ubuntu packages...

Create a routine (similar to lines et al) for construction of spheres.

Should we also add something for cube (based on vector_range) and possibly more obscure shapes? (cuboids, ellipsoids, etc.?)

We need to add something like Martin's obj loader for 0.5. Probably don't need all the rotation and scaling stuff - we can defer to Vector for that. Rather it should be something brutally simple: load the obj and present it as a dict mapping vectors to blocks. For the material mapping we might to provide something a little extra - maybe a function to query all the materials used by the file, or something?

Also need to provide recipes showing how to scale/translate/rotate the resulting dict of vectors (although that should be pretty obvious from the vector tutorial, but you can bet people who want obj loading will jump past that stuff).