ID:261596
 
if i want to have more than just a head say for example if i split the icon in 6 would i have to make each of them an overlay? is there a simpler way
mob
player
icon = 'player.dmi'
icon_state = "ml"
New()
..()
move_AddFOBJ(icon(usr.curicon,,icon_state="mr"),"mr",1,0)
move_AddFOBJ(icon(usr.curicon,,icon_state="tl"),"tl",0,1)
move_AddFOBJ(icon(usr.curicon,,icon_state="tr"),"tr",1,1)
move_AddFOBJ(icon(usr.curicon,,icon_state="bl"),"bl",0,-1)
move_AddFOBJ(icon(usr.curicon,,icon_state="br"),"br",1,-1)
_______
| |
| tl tr |
| ml mr |
| bl br |
|_______|

tl tr ml mr bl br are all states. if i put em together when a mob starts u can only see the iconstate "ml" is therfe another way to display them rather than just overlay
Here is the system, i tested it, and it works

turf
        grass
                icon='land.dmi'
                icon_state="grass"
        tree
                icon='land.dmi'
                icon_state="tree"
                density=1
mob
        icon='blah.dmi'
        icon_state="man"
        verb
                makemob()
                        new /mob/parentmt/bob(locate(src.x,src.y+1,src.z))
mob
        mt
                var
                        xoffset
                        yoffset
mob
        parentmt
                density=0
                invisibility=101
                var
                        list
                                childs
                Move()
                        //all of this is the pathing, its not great, but it works
                        var/list/movers=list()
                        for(var/mob/mt/o as mob in src.childs)
                                var/atom/ttmp=locate(src.x-o.xoffset,src.y-o.yoffset,src.z)
                                if(!isnull(ttmp))
                                        if(ttmp.density==0)
                                                movers+=o
                        if(movers.len==3)
                                for(var/mob/mt/o as mob in movers)
                                        o.loc=locate(src.x-o.xoffset,src.y-o.yoffset,src.z)
                        ..()
mob/parentmt/bob
        childs=list(new/mob/mt/b1,new/mob/mt/b2,new/mob/mt/b3)
        New()
                world<<"[src] was created!"
                ..()
                walk_rand(src,2)
mob/mt
        b1
                icon='blah.dmi'
                icon_state="a"
                xoffset=1
                yoffset=0
        b2
                icon='blah.dmi'
                icon_state="b"
                xoffset=1
                yoffset=1
        b3
                icon='blah.dmi'
                icon_state="c"
                xoffset=0
                yoffset=0
In response to FIREking
Thanx I'll try that
In response to Soori-99
Another solution would just be to have obj/overlays/(mobname)/1, 2, 3, etc. Then, when the new mob is created, add typsof(obj/overlays/(mobname)) to it's overlays. Make sure the overlay objs have their pixel_x and pixel_y set beforehand.
In response to FIREking
you defined parentmt as an object if i want to make it a mob is it ok to change it from obj/parentmt to mob/parentmt?
In response to Soori-99
yeah, you can change it to a mob
In response to Garthor
overlays is not the answer, with my solution, you have control over actual objects, or mobs, or atoms, or datums even. This gives you more of an option, such as each child can contain an inventory, for whatever purposes you would need. Having these actual objects gives you more control, and more options, when it comes to expanding. Plus it gives you control over density of the multitile mob or obj.

The only problem I have found, is writing a really good algorithm for pathing. You gotta check for each object, otherwise, youll find that your 4 x 3 dragon is walking over people and trapping them(cuz each child is dense), and they cant move.
In response to Soori-99
one little note, you might want to think about how you configure the children. if you have the following, for instance:

______________
|            |
|    ABC     |
|    DEF     |
|    GHI     |
|____________|



Where E is the parent, if E is dense, and ABCDFGH and I are dense too, your multi mob wont be moving, because the parent is the controller, and he wont be able to walk through the dense objects. Youll have to make E have density set to 0 in this case...

Consider the next example:

______________
|            |
|    ABC     |
|    DEF     |
|            |
|____________|



Where E is the parent. If ABCD and F are dense, and E is dense, the multitile mob will only be able to move down-left, down, down-right. The multitile mob wont be able to move left, right, up-left, up, and up-right. The reason is that E is dense, and so are the surrounding children, therefore the E parent cannot move through them. If you made E non dense in this example (like the last example) ,you would see that players would be able to walk through E, which would not be right in a gaming environment.

So you might want to take some careful planning as to how you arrange the children around the parent. Or, you might want to take a different solution, where the parent is never visible, and is never dense, and he controls a mass of children objects. This seems to be the best solution.
In response to FIREking
On your first point: having seperate objects means they WILL be out of sync. Your 4x3 dragon will crumble to pieces when he moves. My system works perfectly, because you have invisible objects that can do everything your visible objects can do.

On your second point, it's very simple. Make a proc that checks for any objects, mobs, or dense turfs in the direction that the parent is moving in. If there are any, return one. Otherwise, return zero. Then, if any return one (easy way to do it: add all the procs together if(A.PROC() + B.PROC())) stop the movement, and simply face them in the direction (which you probably will have done in the proc.)
In response to FIREking
It seems to be that the best solution would be to simply move all the child objects beforehand. That way, they aren't there to bump into. It's not that hard to delay a Move() proc until the other Move() procs have been run.
In response to Garthor
I don't think the 4x3 dragon will crumble if you use the animate_movement var (I think that's it) correctly.