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?)
ID:273379
Mar 12 2010, 1:47 am
|
|
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.
|
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:
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.