Turfs vs Objs

ID:154702
 
Jan 14 2012, 2:31 am
So I am knee deep in the middle of a very complex new tiling system I am writing from scratch in my project which allows for more complex map editing and movement rules. The problem I am running into is putting new turfs in a location will remove the old turf. Using objects instead of turfs (because they can stack for more combinations by overlapping and transparency) doesn't get an Enter() or Exit() call when mobs move around on the objects.

I am searching for an elegant way to draw the floating type tiles on top of turfs (and having the movement rules for the tile change as a result) while keeping the remaining turfs underneath, OR using an object only solution that has really quick movement checks like enter and exit.

Any ideas?
Jan 14 2012, 2:46 am
Maybe you could try something like this:
obj/proc/canEnter( mob/m )

turf/Enter(m)
    for( var/obj/o in contents ) // objects initialized on that turf 
                                 // will be in its contents list
        if( !o.canEnter(m) ) return
    return ..()
Jan 14 2012, 2:48 am
In response to Metamorphman
Yeah, I've given this thought. But I wonder how this will scale performance-wise... How well will this work if 20,0000 mobs are calling it.

One of the main reasons I ask is because you can stack turfs in the DM map editor, but you can't do it at run time.
Jan 14 2012, 2:53 am
In response to FIREking
Well, give it a test drive. It shouldn't be too taxing, given that something similar already occurs with density checks. :)
Jan 14 2012, 2:55 am
In response to Metamorphman
True, I will have to think about it.

I think the more efficient way is to write an algorithm that calculates and modifies each turf tile based on a set of conditions. For example, if you are drawing some vines over a cliff top: instead of adding a vines tile to the cliff top, we just add it as an overlay.

Then, if the vine allows player movement OVER the cliff top which would normally be blocked, then the turf's actual density property or movement bits are adjusted accordingly.
Jan 14 2012, 3:07 am
In response to FIREking
Sounds like a plan. Make sure you use some caching though.

Also, be careful with too many overlays. iirc, there's still a cap of 65535 on the number of individual internal lists you can store for one DS process. ( overlays, underlays, screen, images, etc. )
Jan 14 2012, 3:25 am
In response to Metamorphman
There would only be a handful of overlays at most...

At any rate, I think my plan is going to be flawed... because I am testing saving and loading of 256x256 turfs right now, and it is very slow. Considering I would have to save the object its self (to retain its overlay list, and other specialized modified properties)...

I don't know. Do you suggest I just save each specific property as well as each overlay in some sort of text format, then just unroll it at load-time??
Jan 14 2012, 3:52 am
In response to FIREking
The overlay limit applies to overlay lists. Meaning each atom with anything in its overlays has an overlays list. Meaning only 65535 individual atoms can have overlays.

As for saving and loading, try something like this:

list(
/turf/wall = list(1,1, 2,1, 3,1, 4,1 etc ) // x and y values
/vines = list(1,1, 5,1 )
)

And then at runtime, you can create new atoms of each type at the selected locations, then apply your algorithm to each turf that gets stuff in its contents. But I still think you would be better off and have more flexibility using checks in Enter()
Jan 14 2012, 3:58 am
In response to Metamorphman
Hmm, this gives me a lot of ideas...

Like, instead of using overlays, just creating a new icon state and assigning it some unique ID.

I will have to give this a lot of thought!