having a bmp as a monster?

ID:179496
 
Dec 16 2001, 4:06 am
I am wondering if it is possible to have a bmp as a monster
since the icon is to big for dm
cuz i have tried but it doesnt work, i cant make it so when a random fight happens it spanws a bmp that you can hit
Thanx
Dec 16 2001, 4:35 am
i'm sure there is a lib for this, but like make the file ya want and add this coding.

turf
monster
icon = '???.bmp'
Dec 16 2001, 4:45 am
In response to Deadman Walking
Deadman Walking wrote:
i'm sure there is a lib for this, but like make the file ya want and add this coding.

turf
monster
<font color="white">icon = '???.bmp'</font>

Little wrong there Deadman

It should go like this:

mob
    monster
        icon = '???.bmp'


Lee
Dec 16 2001, 5:05 am
In response to Mellifluous
Well i tried that and all it does is cuts up the bmp into sections and only one section shows for the actuall monster
so is there any other way?
Thanx
Dec 16 2001, 6:15 am
Greg wrote:
I am wondering if it is possible to have a bmp as a monster
since the icon is to big for dm
cuz i have tried but it doesnt work, i cant make it so when a random fight happens it spanws a bmp that you can hit

I think the only really viable way to do this is with multi-tiled mob. It might be possible to use the .bmp as-is with certain changes to the icon_state for each mob, but you're probably better off splitting this into chunks.

Basically the general way you'd handle something like this would be to give your monster a list var that holds the other objects that move with it; designate one section as the "head", the master section that controls all the others. All movements should move not just the head, but every mob in the list. (Movements also have to check which directions are blocked for other mobs in the list.) The mechanics of all this can be kinda tricky.

Just to get you started, here's a general overview of what you have to do:
mob/monster
  icon='monster.dmi'
  icon_state="0,0"
  var/list/sections
  // if another segment is north, connectedto=NORTH.
  // if there are segments west and east, connectedto=WEST|EAST.
  var/connectedto=0

  // set up this monster
  // let's say this is a 3x2-tile monster
  New()
    ..()
    // this is the bottom
    connectedto=NORTH|WEST|EAST
    // upper left corner
    new /mob/monster/section(-1,1,src,EAST|SOUTH)
    // top
    new /mob/monster/section(0,1,src,WEST|EAST|SOUTH)
    // upper right
    new /mob/monster/section(1,1,src,WEST|EAST|SOUTH)
    // lower left corner
    new /mob/monster/section(-1,0,src,EAST|NORTH)
    // lower right corner
    new /mob/monster/section(1,0,src,WEST|NORTH)
  Del()
    for(var/mob/monster/section/M in sections)
      del(M)

  proc/CanMove(_dir)
    if((connectedto&_dir)==_dir) return 1
    var/turf/T=get_step(src,_dir)
    for(var/mob/monster/M in T) if(M in sections) return 1
    return T.Enter(_dir)

  section
    var/mob/monster/parent
    var/relx
    var/rely
    New(_relx,_rely,mob/monster/M,connect)
      relx=_relx
      rely=_rely
      loc=locate(M.x+relx,M.y+rely,M.z)
      parent=M
      M.sections+=src
      connectedto=connect
      icon_state="[relx],[rely]"
    Del()
      parent.sections-=src
      parent=null

    CanMove(_dir)
      if((connectedto&_dir)==_dir) return 1
      var/turf/T=get_step(src,_dir)
      for(var/mob/monster/M in T)
        if(M==parent || ((M in parent.sections)) return 1
      return T.Enter(_dir)

Notice I didn't include a Move() proc. You'll need to define that yourself. The CanMove() proc I provided should help, since you can call it for all the mobs in the list to see if they can walk a certain direction. If they all return 1, you're good to go. Move() calls that don't involve simply moving in a particular direction, but instead use teleporting or something, would need to check every possible destination tile the monster would cover before teleporting them.

Lummox JR
Dec 16 2001, 7:00 am
In response to Lummox JR
Lummox JR wrote:
Basically the general way you'd handle something like this would be to give your monster a list var that holds the other objects that move with it; designate one section as the "head", the master section that controls all the others. All movements should move not just the head, but every mob in the list. (Movements also have to check which directions are blocked for other mobs in the list.) The mechanics of all this can be kinda tricky.

I wouldn't suggest venturing down this road until someone is very proficient at BYOND.

The next thing they will discover is that their mob keeps getting stuck, so they'll need customized pathfinding, etc.

I've been working up the necessary libraries for a few months, and may release them at some point. Though I shudder at trying to provide support for them.
Dec 16 2001, 7:37 am
In response to Greg
No. Look at this post for more help [link].
Dec 16 2001, 11:03 am
In response to Deadron
Deadron wrote:
I wouldn't suggest venturing down this road until someone is very proficient at BYOND.

True; this is a problem. Unfortunately I can't think of any other way to do big monsters without resorting to multi-tile mobs. Still, one of the nice things about tackling such a project is that it kind of forces you to get familiar with the moving parts of BYOND, and could easily be a very instructive project for a novice provided they had the patience to keep at it for a while.

The next thing they will discover is that their mob keeps getting stuck, so they'll need customized pathfinding, etc.

In battle arenas this would probably be a lesser concern. I can think of plenty of game styles that needn't worry too much about pathfinding.

In this case, I suspect this person will either give multi-tile mobs a shot and discover the pitfalls on their own as they work along, or else they'll decide to go a different way.

Lummox JR
Dec 16 2001, 11:19 am
In response to Deadron
Though I shudder at trying to provide support for them.

In my opinion, don't bother.

I'm planning on adopting a no-support policy for some of my higher-end top-secret libraries (s_help and s_tracker are two examples).

If someone gets themselves into a mess from using it, it's not my fault. If they don't understand what's happening with the library when things go wrong (despite the documentation explaining it), I can't really be responsible. Now, if something wasn't explained in any documentation, it would be a valid support case, but I wouldn't hand off code for that sort of thing.

(Analogy: How much professional support can one find on the internet for conio or stdio or whatever? You certainly won't get help for it from Microsoft or Borland, unless it's a bug in the compiler!)