Center vector

@diclophis @juanca @bennapp More things take Vectors, and Vectors are better.  Most notable @diclophis, `@center` now has to be a vector.
Can chat tonight.  Open to anything :)

I want to show you the cool tunneling code i wrote.

---
Andrew Cantino
VP of Engineering, Mavenlink

> On Aug 30, 2014, at 10:51 AM, Jon Bardin <notifications@github.com> wrote:
> 
> In world-painter/world_painter.rb:
> 
> > @@ -80,6 +138,20 @@ def initialize(centerX, centerY, centerZ, options = {})
> >      @client = MinecraftClient.new(@async)
> >    end
> >  
> > +  def async
> > +    original_async = @async
> > +    set_async true
> > +    yield
> > +  ensure
> ensure I think is more for exception level handling of logic, in this case we are not dealing with exceptions, we are more so dealing in a required sequence of events, set_async, yield, unset_async...
> 
> Also should a dev
> 
> begin
>     painter.async do
>       raise Foo
>     end
> rescue
> end
> or
> 
> painter.async do
>   begin
>     raise Foo
>   rescue
>   end
> end
> Plus it might be best to make all exceptions halt execution in general, which means the ensure is mostly just annotation because nothing rescues anything. And when we actually fix the client to set/unset async/echo via a server command it might raise an "Disconnected/Cannot Write" exception, and ensuring anything at that put is weird.
> 
> The more I think about it, maybe async should be forced on the client side, and the only option is really "echo on/off". Any "blocking" operations, like player_position build the blocking semantics into their implementation methods. For instance "scanning" could be re-impled as a yielding method:
> 
> def scan(upper_left, lower_right, &block)
>   write_testforblock_commands(upper_left, lower_right)
>   blocks = read_testforblock_results
>   blocks.each { |position_v, type|
>     yield position, type
>   }
> end
> Then we could just have the "echo off" be a simple "mode" switch for the client, as an optimization to prevent unnecessary server response output, though there is a bug with that on the server... all the output ends up being extra-broadcasted to whatever other non-async clients there are... maybe network lag even more problematic, BUT i think its a requirement in general that all clients should receive all server output to ensure nothing gets missed... this means we need a whole new architecture for the client.
> 
> Something to the effect of a constant event dispatch when reading output, so that you can just ask the client if you want:
> 
> client.empty_event_buffer do |new_event_that_has_occured_maybe_not_my_own...|
>   switch new_event.type
>     when PlayerPosition
>       # do i care about this players position? if so, unblock my request to fetch it, and proceed with other client commands
>     when BlockPosition
>       # if I am in 'scanning mode' for a region, is this block in that region? if so, save it to my memory
> —
> Reply to this email directly or view it on GitHub.