ID:273379
 
How could I get bridges and mountainous regions with multiple elevation levels going?

Basically I'm wondering how I could make structures in BYOND's built-in isometric mode. For instance, a bridge that can be walked over or under. I've had a bit of a play around with it and the best I can do is have objs or mobs (or, really, any atom that isn't a turf) as the structure.

Only problem is that I'm not entirely sure how I would go about using them and making the movement snippets bug-free, especially in a turn based tactics engine.

I've taken a look at pixel_z, and I've successfully used it for turfs, but I get another problem in that only one turf per square shows up.

Could someone please point me in the right direction?

(Also, client.dir will allow me to change a client's viewpoint of the map, right?)
You can only ever have one turf on a given location. The effect you see when you put one turf 'on top of' another and get both at once is caused by the map editor adding one turf as an underlay to the other.

Basically you do elevation by giving every turf an elevation value - which probably relates to its pixel_z somehow - and then overriding turf/Enter() so that it checks that the atom/movable moving can get to the elevation of the target turf. Bridges are harder - one way would be to allow lists of elevations.

Example code, minus bridges. Entirely untested, may not even compile:
turf
var/elevation = 1

Entered(atom/movable/o)
.=..()
o.elevation = elevation //When entering a turf, we go to the turf's elevation

Enter(atom/movable/o)
//Only allow atom/movables to enter the turf if they're within 1 elevation
if(abs(elevation - o.elevation) < 2) return ..()
return 0

mountain_side
elevation = 2

mountain_peak
elevation = 3

atom/movable
var/elevation = 1


Try that code, scatter around a few mountain_side and mountain_peak objects with appropriate pixel_z values, and then see which ones you can enter.
In response to Jp
Works like a charm, I just had to simply add another line of code to calculate pixel_z for the mob to make it look right. I could use a system much like this for my actual program. I'll have to add animations for jumping up and down z levels and things though, at the moment simply setting the pixel_z is rather choppy.

<s>So then, graphically, I should be doing that manually? Adding the turf's required underlays at runtime, I mean? One of my big problems is that, for instance, there's no grass under my suspended walls, and I can't make a pillar of walls currently with the map editor.

And moving under the walls is a whole other problem, but with lists of elevations, like you said, it should be possible. So I'll do a bit of testing, see what I can come up with. Edit: I've got the elevation lists working, though I'm not sure I've done it right. I still can't work out the underlays though, adding them in New() doesn't seem to work.</s> Edit2: I was doing it wrong, as per usual. Got it working 100%. Thanks for your help, Jp.
In response to Jp
Im working ona similiar type of idea and i only have one problem hwo did u get the pixel_z to work using that code?
In response to Cruor Everto
One thing to watch out for with lists for elevation values is that you can only have so many lists in the world. Don't just make all the turfs have a list of elevation values - let them have an elevation number or an elevation list, and only give the list to turfs that need it (You can check if it's a number or a list with istype(whatever, /list)).

You also might want to be careful with low bridges - if you've got a bridge at one elevation value higher than the ground under it, does the player want to jump onto the bridge or walk under it? That's closer to an interface problem.
In response to Alec94
Set the pixel_z value based on the elevation. When you change the elevation of an atom/movable, change its pixel_z.