Moving all pieces in a location?

[Rob3d]

Is there a way to move all the pieces in a location to another? For
example in dungeon of d when you run out of cards in the power deck
you have to move them from the discard pile and re shuffle the into
the draw pile.

I figure I could just run move_piece_at_location 40 times and add that
as the single_tap of an invisible piece, but I was just wondering if
there was a way to do it in a sngle line of code.

If not maybe something that let's you define the "to & from" locations
as well as maybe moving all pieces of a certain type to a location.

Any one else run into something like this?

[Adam Jeppson]

I just tried something that seems to work.  If you put a <location_in_action action="move_piece_at_location" args="discard_deck,power_deck"> on your power deck, it will enter a logic loop that moves all the pieces over (first dragged piece triggers the moving of the next piece which triggers the next, etc.).  Of course, you wouldn't be able to drag cards into the power deck from anywhere else either lest you trigger the loop.  

The more ideal solution would be to make it a location_out_action on the discard deck with the same action and args.  I tried this as well, but it crashes the program every time.  Probably a bug in EveryGame.  Location_out_actions have always seemed to have problems in the history of EveryGame which is a shame because they are really useful!  I am glad they fixed the last bug I pointed out because it let me do a automatic score increase on a location_in_action and a score decrease on a location_out_action.  

This actually reminded me of something Notch (Minecraft developer) has done.  He regularly uses the bug list at the Minecraft wiki as a resource to know what to fix (http://www.minecraftwiki.net/wiki/Known_bugs).  Nathaniel, perhaps we could do the same here?  Not only would it serve to let you know what the problems are, but it would help us module-makers know if what we are seeing has been experienced by others.

Hope this helps.

Adam

[Rob3d]

That's a neat idea. I'll mess around with it and see how well it
works.

Thanks

[Rob3d]

Unfortunately this doesn't seem to be working for me. It doesn't error
out or even crash, just doesn't do anything.

Here's a piece of a test I set up after it wouldn't work in my DoD
module

<!--TEST DECK-->
<location_type type="stack">
<location_display type="no_display">
<size width="221" height="309">

<valid_types types="POW">
<location_in_action action="move_piece_at_location"
args="MainCanvas,pow_deck">
<corner_coord board="0" x="100" y="100"><location>pow_deck</
location></corner_coord>
</location_in_action>
</valid_types>

</size>
</location_display>
</location_type>


it just doesn't do anything. Is there anything you see as wrong in
what I wrote?

[Adam Jeppson]

I just tested yours in my "Template" game, and it worked just fine in moving ten pieces instantly.  Are you sure your pieces are of type "POW"?  And those pieces of type "POW" are in the MainCanvas location?  And you are dragging a piece of type "POW" into pow_deck?  Does that one piece actually go in?

[Adam Jeppson]

Never mind, I just figured it out!  I'm guessing MainCanvas (the from location) is a "free" location?  I just tried making my source location be "free" and it didn't work anymore.  I'm guessing this is simply because it has no way of knowing which piece to grab.  move_piece_at_location is (I'm guessing) only going to work with a stack, queue, or cell location.  I don't really think that is a bug at all because the free location shouldn't in theory have to have stack like qualities.  

On the other hand, you CAN use send_to_back on a free location.  You can see this by having a few pieces on top of each other in a free location and do a send_to_back and it sends the "top" one to the "bottom".

There does seem to be a little contradiction here.  Nathaniel, care to jump in here?

Adam

On Fri, Apr 29, 2011 at 3:25 PM, Rob3d <robco...@gmail.com> wrote:

[Rob3d]

If that's the case then my original idea of doing
move_piece_at_location 40 times with the single_tap wouldn't work
either.

Its a shame because the random rotation and position I've set looks
cool for the discard pile using "free" location.

maybe as a request a "move_all_at_location" that would work with all
the location types would be useful.
and since I'm feeling greedy maybe a "move_type_to_location" that
would move all designated piece types no matter where they are to a
defined location.

so any other ideas on how to get the desired effect to work with
"free" locations?

[Eggy]

Just for a quick response:

There is a plan to create a "move all pieces at location" action. There have been several requests for a gesture to do this (perhaps a two finger drag), and we could add it as an action at the same time.

Free locations are pretty new, so there might be an issue or two left with them. As you point out, send to back is useful with overlapping pieces. Though it might not always be evident, there is a stack underpinning to them, so mov piece at location could work. If it's not, it's possible that we disabled it, since it could cause the sort of confusion picking piece you describe. I'll look into making that action work.

Similarly, crazy location out actions should work. I think that as described, they might reverse the stack order, but I'm not even completely positive. Once you get into recursion, the specific order of sub operations becomes more important. Hopefully, we can at least make it not crash though! I do find this usage of them to be very inventive and exciting though! It makes me want to create a "double tap here" or "double tap this piece" action so you could do similar recursive tricks for taps. No promises there though -- those are stretching the engine a bit, and might be a bit dangerous to add. :0). We'll see!

-Nathaniel

Sent from my iPad

[Adam Jeppson]

Yeah, half the fun for me in making these modules is getting the existing infrastructure to do all the weird things I want to do. Then, as you implement new features to cover those hacked-together solutions I can figure out weird new uses for those new features.

For this reason it doesn't really bug me too much when I don't have a functionality available because it just means more chances for me to tinker. I DEFINITELY put more time into making these than playing them.

Adam

[Rob3d]

It's good to hear a "move all pieces at location" action will be
worked on at some point. If at all possible it would be nice to use
that action with a location that has rows and columns by using the
location name and not having to specify "location_[col]_[row]". I
tried to set the in_action loop that Adam suggested and it won't
accept the location name without a specified row and column. Its
works well for stacked decks though so I will definitely use the loop
for that.

thanks for the suggestion.

On Apr 29, 8:32 pm, Adam Jeppson <ajepp...@gmail.com> wrote:
> Yeah, half the fun for me in making these modules is getting the existing infrastructure to do all the weird things I want to do. Then, as you implement new features to cover those hacked-together solutions I can figure out weird new uses for those new features.  
>
> For this reason it doesn't really bug me too much when I don't have a functionality available because it just means more chances for me to tinker. I DEFINITELY put more time into making these than playing them.
>
> Adam
>

> On Apr 29, 2011, at 6:08 PM, Eggy <eggy.everyg...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Just for a quick response:
>
> > There is a plan to create a "move all pieces at location" action.  There have been several requests for a gesture to do this (perhaps a two finger drag), and we could add it as an action at the same time.
>
> > Free locations are pretty new, so there might be an issue or two left with them. As you point out, send to back is useful with overlapping pieces.  Though it might not always be evident, there is a stack underpinning to them, so mov piece at location could work.  If it's not, it's possible that we disabled it, since it could cause the sort of confusion picking piece you describe.  I'll look into making that action work.
>
> > Similarly, crazy location out actions should work.  I think that as described, they might reverse the stack order, but I'm not even completely positive.  Once you get into recursion, the specific order of sub operations becomes more important.  Hopefully, we can at least make it not crash though!  I do find this usage of them to be very inventive and exciting though!  It makes me want to create a "double tap here" or "double tap this piece" action so you could do similar recursive tricks for taps.  No promises there though -- those are stretching the engine a bit, and might be a bit dangerous to add.  :0). We'll see!
>
> > -Nathaniel
>
> > Sent from my iPad
>

[Eggy]

To respond to a couple of messages back, hopefully you won't need to use free locations for your discard pile much longer. We're adding in an attribute so the you can specify how many pieces in a stack or queue to display, so you could see them stacked on top of each other in those location types as well.

It will be longer until we could do anything like your request for specifying locations in grids without their row and column though I'm afraid. While it looks like a single location entry in the .XML file, it's really just shorthand to create many different, and independent locations, and by the time the XML parser is done, it doesn't know that they were related in any way. We would need to create a new location type to d otherwise, which is possible, but much more time consuming and error prone than smaller changes.

-Nathaniel

Sent from my iPad

[Rob3d]

That attribute you describe sounds perfect. As for the grid issue its
not really that big deal right now, just thought id mention it in case
there was a possibility it could be added.
thanks.

On May 1, 2:05 pm, Eggy <eggy.everyg...@gmail.com> wrote:
> To respond to a couple of messages back, hopefully you won't need to use free locations for your discard pile much longer.  We're adding in an attribute so the you can specify how many pieces in a stack or queue to display, so you could see them stacked on top of each other in those location types as well.
>
> It will be longer until we could do anything like your request for specifying locations in grids without their row and column though I'm afraid.  While it looks like a single location entry in the .XML file, it's really just shorthand to create many different, and independent locations, and by the time the XML parser is done, it doesn't know that they were related in any way.  We would need to create a new location type to d otherwise, which is possible, but much more time consuming and error prone than smaller changes.
>
> -Nathaniel
>
> Sent from my iPad
>