Forum_account's Shoutbox

Page: 1 2 3 ... 15 16 17 18 19 20 21
May 22 2012, 3:08 pm
In response to FIash Speed
Try this:

mob
    can_bump(obj/bomb/b)
        if(istype(b))
            if(px + pwidth <= b.px) return 1
            if(py + pheight <= b.py) return 1
            if(px >= b.px + b.pwidth) return 1
            if(py >= b.py + b.pheight) return 1
            return 0
        else
            return ..()

I'm not entirely sure what the difference is, but this seems to work.
May 22 2012, 3:48 pm
For some reason, I got the same result. The thing is that if I create a bomb on the map using the map.dmp it works out perfectly with your new code, but when I try it on newly made bomb, which uses this code:

mob
    verb
        Bomb()
            var/obj/H = new/obj/bomb
            usr.usedbomb++
            var/d=round(src.x)
            var/e=round(src.y)
            H.loc=locate(d,e,src.z)
            H.power=src.power
            H.icon_state="exploding"
            src.done=1
            sleep(30)
            if(H)
                ExplodeBM(new /Effect/BasicBoom(H.loc,0,H.power))
                usr.usedbomb--
                del(H)

It seems to fail me. Am I doing something here in the code that interferes with your library?

I'm terribly sorry for asking this many questions.
May 22 2012, 4:04 pm
H.loc=locate(d,e,src.z)

That might be doing it. The Pixel Movement library uses the px and py vars to determine an object's position. When you change an object's loc, those vars don't get updated. Try this instead:

mob
    verb
        Bomb()
            var/d=round(src.x)
            var/e=round(src.y)
            var/obj/H = new/obj/bomb(locate(d,e,src.z))
            usr.usedbomb++
            H.power=src.power
            H.icon_state="exploding"
            src.done=1
            sleep(30)
            if(H)
                ExplodeBM(new /Effect/BasicBoom(H.loc,0,H.power))
                usr.usedbomb--
                del(H)
May 23 2012, 7:36 am
Ah, Thank you so much! That solved the problem.
Edit: Sorry, I apologize, but do you mind if I ask one more question?

    BasicBoom
    {
        Apply(x,y,power,dir)
        {
            var/i
            var/turf/T
            T = locate(x,y,orig.z)
            if(T.density)
                return 0
            i = image('fire.dmi',locate(x,y,orig.z))
            world << i
            spawn(10)
                del(i)
            for(var/obj/M in T)
                if(istype(M,/obj/bomb))
                    var/D=M.power
                    var/O=M.loc
                    del(M)
                    ExplodeBM(new /Effect/BasicBoom(O,0,D))
                if(istype(M,/obj/map/wall))
                    for(var/obj/item/D in M.items)
                        D.loc=M.loc
                    spawn(1)
                        del(M)
                    return 0
                    break
                if(istype(M,/obj/item))
                    del(M)
            for(var/mob/M in T)
                M.frozen=1
                M.icon_state="frozen"
            return ..(x,y,power-1,dir)
        }
    }

After using this library, the mob is unaffected by the explosion. Am I doing something that goes against your library here as well? This Apply proc is called everytime the explosion moves a tile.
May 23 2012, 8:04 am
The line for(var/mob/M in T) should get all mobs that overlap T. If you put an output statement in that for loop you should see it.

The Pixel Movement library sets the mob's icon state to show if they're standing still or moving. If you set their icon_state to "frozen" it'll just get changed back. What you can do, provided their frozen var is being set, is override the set_state() proc:

mob
    set_state()
        if(frozen)
            icon_state = "frozen"
        else
            ..()
May 23 2012, 8:10 am
Ah, I understand. Thank you very much.
May 24 2012, 4:44 am
 
mob
    Login()
        ..()
        src.camera.minx = 689
        src.camera.maxx = 10335
        src.camera.miny = 486
        src.camera.maxy = 6318

In my 15x13 map, after I set these values, for some reason, if I walk about 8 steps to the middle (x) or 6 steps to the middle (y), the camera's position follows my character. I have tried extending maxx and maxy to ridiculously high values and it still does the same thing. Am I missing something here?
May 24 2012, 4:59 am
I'm not sure what you're trying to accomplish. The camera will follow your mob until it reaches the bounds defined by minx, maxx, miny, and maxy. If you want the camera to stop following your mob, you'll need to lower the maxx and maxy.
May 31 2012, 1:49 am
Please see this post regarding your Interface library.
May 31 2012, 2:58 am
I am also running into issues with code not being executed. It seems the world locks up, I can't even use the input bar anymore.
Jun 6 2012, 10:01 pm
There seems to be an issue/bug in pixel_movement where two different Areas side by side will spam the Entered() proc when a player passes between them.

This seems to happen since Entered is normally called when the entirety of a mob enters a panel, whereas in this case it's called every time a mob moves while overlapping an area. If two areas are side by side and a mob walks over the line, both areas will spam the Entered() procedure.
Jun 7 2012, 2:30 am
The next update changes how the Entered proc is called, so I'll just make sure this isn't happening there. These things were much easier to handle before BYOND had pixel movement since I could control what your loc was. Now BYOND tries to tell me what your loc or locs are.
Jun 8 2012, 6:03 am
Greetings,

I had a question about the pixel movement on BYOND. I understand that pixel movement is more memory intensive than tile movement. That being said, I'm working on a project which implements pixel movement. It works 100% perfectly if I run it locally, but the moment I host the project there is a considerable amount of lag. The network delay skyrockets to well over 15, and the movement of the character looks like it's rubber banding. The moment I turn off the pixel movement, however, it runs perfectly with the network delay only climbing up to 1 or 2. My question is the following : Is this due to the system limitations of BYOND, or is it because the shell I'm hosting the game on isn't powerful enough to deal with the increased memory usage of pixel movement?
Jun 8 2012, 6:25 am
The difference will be in CPU and bandwidth usage more than the memory usage. To have smooth movement when you're using pixel movement you have to increase the game's framerate, which can increase its CPU usage and network usage - instead of sending updates to the player 10 times a second, it sends updates 30-60 times per second.

Still, such a drastic difference in performance is probably due to problems with your server. I've played many BYOND games that use pixel movement just fine over the internet with people hosting on their home computers. The performance was not as smooth as running the game locally, but the games were still very much playable. Maybe they'd run between 28-32 frames per second instead of the 35 fps you'd achieve locally.
Jun 8 2012, 10:03 am
Tanx ran fine when I hosted on my own computer. It's definitely an issue with the shell you're using. What're the stats on it?

If you're using it for pixel movement games then you want at least 2.5ghz processor (multi-core doesn't matter as byond is single threaded) and the network speed should be at least 1 mbps. If the shell connects via DSL (256kbps/512kbps) it's way too slow.
Jun 8 2012, 2:01 pm
In response to Bravo1
Bravo1 wrote:
There seems to be an issue/bug in pixel_movement where two different Areas side by side will spam the Entered() proc when a player passes between them.

This seems to happen since Entered is normally called when the entirety of a mob enters a panel, whereas in this case it's called every time a mob moves while overlapping an area. If two areas are side by side and a mob walks over the line, both areas will spam the Entered() procedure.

I just posted v5.5 which fixes this: http://www.byond.com/forum/Forum_account/PixelMovement
Jun 8 2012, 2:27 pm
Awesome I'm testing asap!
Jun 9 2012, 3:18 am
Greetings,

It's a standard silver DBZenhosting shell. Here are the specs on it :

-50 GB Disk Space
-1000 GB Bandwidth
-512MB RAM

Unfortunately, I don't have any information beyond that.

Kind Regards,
Hishido
Jun 9 2012, 11:01 pm (Edited on Jun 9 2012, 11:10 pm)
For some reason I'm having an inconsistent error with your overlays library. Basically when somebody presses entergame it calls the drawhud proc which does

            src.chat_log = new(src, 20)
            src.chat_log.pos(20,50)
            src.life = overlay('health.dmi',"[src.lives]")
            src.life.PixelY(-24)
            src.namelay = overlay()
            src.namelay.Text("<text align=center>[name]")
            src.namelay.PixelY(-16)



For some reason though, It randomly doesn't work for certain people entering. I cant explain it.

As in, (For testing purposes ill use 5 keys) Ill join on the first itll work. Second works. third wont. forth wont. fifth will.

restart server completely
first works second dont third does forth wont fifth works
Jun 10 2012, 4:26 am
In response to Chris_110872
Are you use that code is getting executed each time? It could be that the overlays are being added and just aren't visible, or it could be that they're not getting created. Are you using world/map_format = SIDE_MAP or ISOMETRIC_MAP?

The only thing I can think of is that it's a layering issue. If you create two objects at the same layer, I've noticed BYOND sometimes handles them differently (sometimes the first object is always higher, sometimes the second is, sometimes they switch for no reason while the game is running). Try taking out the calls to PixelY and see if the overlays are at least visible (though positioned incorrectly). You can also try calling their Layer() proc to force them to have a higher layer.
Page: 1 2 3 ... 15 16 17 18 19 20 21