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
ID:261596
Aug 14 2002, 1:23 pm
|
|
Aug 14 2002, 4:08 pm (Edited on Aug 15 2002, 4:45 pm)
|
|
Here is the system, i tested it, and it works
|
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.
|