Castle Paradox

[Bagne]

Is it yet possible to specify slice layering in relation to map layers?
Like ... placing a slice between map layers x and y?
_________________
Working on rain and cloud formation

[Bob the Hamster]

Yes indeed! Check out "set parent" and "lookup slice" in the plotscripting dictionary.

Basically, you can attach a slice to any map layer, and it will be drawn on top of that layer, but underneath any higher layers.

Remember that when you attach a slice to a map layer, the x,y pixel position becomes relative to the whole map, not just relative to the screen. If you want to attach something to a map layer but still position it relative to the screen, you can use the "set screen x" and "set screen y" commands.

[Bagne]

Hooray!
Clack! Clack!
_________________
Working on rain and cloud formation

[Bagne]

Oops, ok ... question. Or ... feature request ... or something.

Here's what I'm trying to do: I'm trying to get my wizard to summon a massive lightning - bolt that will descend from the top of the screen and strike him. Here's my problem: I wish to be able to summon this lightning *anywhere*, including maps that have graphics in upper layers (i.e. tree tops, etc).

I need to be able to differentiate between the trees I am currently behind, and those in which I am in front. That way, I can get the lightning bolt to pass behind some tree tops, and in front of others, by drawing different pieces of the bolt in different layers.

How do I do this? Well, I'm looking for ideas.

So far, I have been thinking that my script can check for tree tops, and follow the map tiles down to the tree base. I will then use the y - value of that tree base to do a makeshift "y-sort" and thus draw the lightning bolt within the proper layers.

This should work, but it's terribly clumsy.

A related question/suggestion:
Are bigger walkabouts being given serious consideration?
I've been reading the Plan for Bigger Walkabouts - and I think that my lightning bolt problem could also be encountered here - especially if we start using very tall walkabout sprites.
Imagine I draw a bush. It is one tile high, and I draw it in layer 2 so that the hero's feet pass behind it. But now, when a sufficiently tall hero walks in front of the bush, his head gets cut off.
My point is, real-time use of large sprites will make it difficult to use map layers to give the illusion of "in front" and "behind".

In order to reap the full benefit of large walkabouts, it would be a good idea to allow some sort of y-sorting with objects on the map.
Maybe this would involve constructing "map-sprites" out of maptiles (say you make a tree), you associate some kind of wall-mapping to the "map-sprite" (block the base of the trunk), and then paint the sprites onto the map. Game.exe would then automatically y-sort the sprites (like how it's done in battles).
_________________
Working on rain and cloud formation

[Baconlabs]

A lightning bolt attack? Odd, I did something just like that in SHiIDA, though it's not usable outside of one scenario for now.
I used Attack Graphic slices, I think. I can't remember if there were issues regarding map layers, but I think slices automatically have a higher priority than heroes, NPCs, and map tiles.

[Bagne]

Can you summon the lightning to strike in front of a tree (or wall), walk around it, and then summon it behind the tree (and everything will look normal)?
_________________
Working on rain and cloud formation

[TMC]

It's funny how I only considered that while thinking about scripted games and not about built in larger walkabouts. Yes, you are right, we're screwed. The map layer system can't handle this, and we need to move to map objects.

By the way, you don't want y sort. Y-sort sorts based on the screen position (of the top of the slice). You need to sort by the y-position where each item stands (effectively, depth into the screen). Use setsortorder and sortchildren.

Are your trees different heights? Or can you assume that they are have one tile in a layer above the heroes? If so, you can get away with just splitting your bolt in two pieces. Otherwise, your options are to do what you described, or to draw your trees and slices and use z-sorting.
_________________
"It is so great it is insanely great."

[Bagne]

I wanted it so that the deeper into the forest you get, the larger the trees will grow. It should make a neat visual, while also assisting the player in landmarking themselves on the map.

So far my tree tiles look like this:

CC
BB
BB

and

CCC
BBB
BBB

B stands for "Base" - it's wallmapped off, and C is an upper-layer canopy tile.
So, yeah - if I drop my variable tree-size idea, I could just place the bottom-most bolt tile in below layer 2, and the rest above.

I was hoping to include trees later like this:

CCC
CCC
BBB
BBB

or even

CCCC
CCCC
CCCC
BB
BB

and

CCCCC
CCCCC
CCCCC
BBB
BBB

Actually, I can make them to an arbitrarily large size. That's the cool thing.

Okay, maybe y-sort wasn't the right word ... I basically meant to say that if I could associate a tree-top with a tree base tile that is at a higher y-value than my hero, I should place the bolt behind that tree top.

I don't know if I understand your last option.
Draw trees and slices and z-sort? Do you mean that I draw my trees as a slice sprite (along with the lightning)? Can you assign sprites a z-value?
What is z-sorting supposed to accomplish?
When I'm drawing a sprite, I only care about their proximity to the camera (y value).
_________________
Working on rain and cloud formation

[ShakeyAir]

as crappy as the implementation would be, i think having several walkabout graphics that are the same as your overhead map tiles, and using a script to overlay them on the fly, and then draw the lightning bolt with fake y-sorting would be the easiest way to do it.

i mean:


suspend movement
get camera x/y
go through the overhead map layer(s) that show up in the camera position, reading what tile is there
load a walkabout sprite slice that looks the same onto each maptile
individually
set its sort number based on its y position
draw the lightning, set its sort number based on the position it is hitting on the ground
sort slices
..whatever else
resume movement

also, you would need some consideration for when the lighting is hitting below an overhead tile. probably the 'easiest' way to do this is:

check if lightning hits below overhead tile
if true:
check if the tile above the 'hit' tile is also overhead, if so, change its sort number to the same as the 'hit tile'
repeat for tile above that as long as you need to


the main thing that could complicate this even further is if two slices can not have the same sort number. then, you will need to use some value range that increases left to right, and compensate for that (a new Y row is 19 larger than the last (18?(two halfsies?) tiles on screen at a time, 1 for the lightning (which will be 1, i am assuming))

basically. yikes. no fun to code at all. though in practice, you would probably only check tiles that are around the lightning bolt (like the middle 3 columns, top 10 rows or something)

a better idea, probably? assuming you have a long game, wait until big walkabouts and some elegant solution is introduced. until then, just let the lightning show up over everything and dont worry too much.

EDIT: also, to TMC, concerning big walkabouts and z-sorting and all that..

keep in mind that some overhead tiles are truly overhead, and some are just in front. maybe handled with separate overhead settings? like "walk behind layer" and "overhead layer"?

[Bagne]