[Ohrrpgce] Slice tutorial

[James Paige]

On Mon, Jan 19, 2009 at 11:41:21AM -0800, Adam Perry wrote:
>      And so-on. The upshot is that younger siblings are always  drawn on top
>      of older siblings, and that children of a parent are always drawn
>      directly on top of their parent. Once you get use to it, it is pretty
>      easy to understand how to arrange your slices to make them draw in the
>      order you want.
> 
>    I see. In that case, I'd want "move slice to top" and "move slice to
>    bottom" functions: if I'm using a slice as a mouse cursor, I want it to go
>    on top always.

Yep. I haven't written them yet, but there will be commands like that. 
Your mouse cursor should be the last child of the sprite layer.

>  Slices go above heroes and NPCs, right? In my example, the
>    mouse cursor is likely one of the first things I'm creating on the map.

The slices are currently all drawn just above the maptiles but just 
below the textboxes. SO at the moment, you mouse cursor is still going 
to be underneath textboxes, menus and plotscripting strings.

That will chnage in the future as I enable slices on other existing 
layers.

I'll be tackling strings soon, and the string layer is the topmost 
layer, so once that is slice-enabled it will be easy to make a truly 
on-top mouse cursor.

>      Does that make sense?
> 
>    Yes. I'm not sure I see the need for containers in general (except for
>    layering), but I saw you made the enemy armada one container in Space
>    InvadOHRs, which makes sense.

They can also help for looping. Notice that I use containers for 
friendly bullets and for enemy bullets. I don't really care what order 
they get drawn in, but I do want to easily loop through all friendly 
bullets or all enemy bullets without having to add some kind of check 
that says "if(this is a friendly bullet(handle)) then(do something)"
Instead I just know that any child of the "friendly bullets" container 
is going to behave the same way.

>    Regarding plotdict:
> 
>    I think this is an error:
>    sprite later
>    Returns a slice handle for the layer which contains sprites created with
>    commands such as load hero sprite, load walkabout sprite and others. You
>    can use this together with first child if you want to loop through all
>    your sprites without knowing their handles.
> 
>    Should say "sprite layer."

Fixed, thanks.

>    Also, I noticed today that the menu commands aren't in the wiki either.

Yeah, maybe Mike can re-import.

I would really rather make the wiki the official master documentation. 
it is so much easier to edit and to crossreference, and to get feedback 
on clarity.

>    "slice collide point" has imprecise documentation: I assume x and y are
>    pixel coordinates, but are they absolute with respect to the map or
>    relative to the screen?

Fixed.

>    It would be really awesome to allow alpha transparency for slices (and
>    textboxes and menus, for that matter).

That is a possible long term goal, but I wouldn't expect it anytime soon 
:)

---
James Paige