FIREking's site

500's might be getting back to feature requests; So, what do you want to see?

Mon, 17 Jun 2013 06:07:41 +0000

This is just a fun post, let's not get too crazy. The feature requests forum is overflowed when a billion gajillion feature requests and I'm sure it probably is a place Tom and Lummox like to often avoid (rightfully so, they have much more important things to worry about).

Just for the sake of having a fun and light conversation on the topic at hand: What features would you most like to see in Byond version 500?

Here's my current list!

atom/angle and atom/alpha - these added variables control an atom's current state of rotation and rendered transparency... Both of these would cause appearance updates so they are some-what expensive to add... But currently, if you want to achieve these, you have to do server-to-client icon operations which is SLOW AS HELL... If the BYOND team upgraded DreamSeeker to understand a atom rotation and atom alpha packet command, this could be added fairly easily and extremely useful to developers.

debug trace - the ability to trace a list of proc calls in order from oldest to newest... This is the closest thing I think we'd ever get to having a steppable IDE (BYOND will never have that, I don't think). With this, you'd be able to debug some complex code very easily. Its possible to create your own trace with a TON of work but it would result in a TON of overhead. This would only be available in DEBUG compilations and probably a profiler function... not intended to slow down performance on production builds or anything like that.

particles - Just watch this entire video: http://www.youtube.com/watch?v=Fy0aCDmgnxg and you'll see why this is important (listen to the crowd at 13:27 and 13:55). This has been avoided in fear of "feature creep" as Tom put it, but honestly its 2013 and there's not much of an excuse to not have a simplistic particle engine built in...

And some less important ones:

ability to get full file path from input() - currently its impossible to write really useful utilities that do batch processing without the ability to grab a full file path from an inputted file.. I'd also like an "as directory" type for input() so that you can select a "folder" to look for files in or to do stuff with files.

server request api - basically the ability to integrate your website with your game world. show people logged in, grab simple stats, etc... maybe just a simple way to get an HTTP response from the world server with some pre-defined world ?topics.

prevent the suppression of error messages - a compile time flag that lets you see every error message in all its glory, for people with some pesky problems that are unsolvable otherwise.

forced line break for maptext overflow - if you type the letter a with no spaces enough times in a maptext value to extend past its maptext_width, the engine makes no attempt to force line-break or cut off the text at the width.

pixel_projectile

Sun, 16 Jun 2013 23:37:07 +0000

Just wanted to plug my new library, the most efficient I've been able to make a fixed angle fixed velocity pixel_projectile for tile-based games:

http://www.byond.com/developer/FIREking/pixel_projectile

recursive spawn() vs while() sleep()

Fri, 14 Jun 2013 11:17:24 +0000

Just searching for some clarification here, I would like to know what happens under the hood for the following code:

proc/test_while()
    while(1)
        x++
        sleep(1)

proc/test_spawn()
    x++
    spawn(1) test_spawn()

It is my understanding that the test_while() will never return, but test_spawn() will return after every spawn(1) call. test_spawn() is scheduling a new call every 10th second but is also returning within the tick its called. Also, the object that test_while() belongs to can't be garbage collected unless there's a break case or a return.

I would like to know a little more about the stack specifically. I've tested situations where recursive spawn() is actually more efficient than while() which is strange considering I think spawn() should have more overhead with the constant stacking.

It is not clear to me when to choose to use one method over the other.

find the angle (in degrees) between two points without atan2, atan, acos, arctan

Tue, 11 Jun 2013 20:26:55 +0000

How do you find the angle in degrees between two points without using trig functions?

I can't, for the life of me, figure out how to compute this raw without trig functions.

Donation Club

Fri, 31 May 2013 02:59:48 +0000

I am going to donate $50.00 each month to BYOND for the rest of the year because I appreciate what I can do with the development tools, and without it, I'd be writing really boring stuff like packet protocols.

That said, I'd like to know who else is willing and able to make a commitment like this?

It's not much but combined, it all helps!

Working towards fastest possible pixel projectile

Mon, 27 May 2013 02:27:35 +0000

I'm trying to create the fastest (most efficient) possible pixel projectile in DM

Here's what I've got so far:

#define WORLD_ICON_SIZE 64
#define WORLD_HALF_ICON_SIZE 32

var/tmp/projectiles = 0

atom/movable/proc/set_pos_px(px, py)
    //this sets the tile (x, y) and the pixel(x, y) from absolute coordinates
    src.x = px / WORLD_ICON_SIZE
    src.y = py / WORLD_ICON_SIZE
    src.pixel_x = px % WORLD_ICON_SIZE - WORLD_HALF_ICON_SIZE
    src.pixel_y = py % WORLD_ICON_SIZE - WORLD_HALF_ICON_SIZE

proc/atan2(x, y)
    //a quick atan2()
    //I think lummox jr wrote this somewhere deep in the byond forum
    
    if(!x && !y) return 0
    return y >= 0 ? arccos(x / sqrt(x * x + y * y)) : -arccos(x / sqrt(x * x + y * y))

proc/get_angle(atom/a, atom/b)
    //returns the angle between two atoms (in radians)
    var/res = atan2(b.y - a.y, b.x - a.x)
    res += 270//right hand conversion
    while(res > 360) res -= 360
    while(res <= 0) res += 360
    return res

proc/get_dir_angle(atom/a, atom/b)
    //converts an angle into a direction, for projectile facing
    var/n = get_angle(a, b)
    if(n >= 337.5 || n <= 22.5)  return EAST
    if(n >= 22.5  && n <= 67.5)  return SOUTHEAST
    if(n >= 67.5  && n <= 112.5) return SOUTH
    if(n >= 112.5 && n <= 157.5) return SOUTHWEST
    if(n >= 157.5 && n <= 202.5) return WEST
    if(n >= 202.5 && n <= 247.5) return NORTHWEST
    if(n >= 247.5 && n <= 292.5) return NORTH
    if(n >= 292.5 && n <  337.5) return NORTHEAST

pixel_projectile
    parent_type = /obj
    animate_movement = NO_STEPS
    var/tmp
        angle = 0
        px = 0 //the true pixel location of the projectile
        py = 0
        last_x = 0 //the last x/y coordinate of the tile we were in
        last_y = 0
        velocity = 10 //speed of the projectile
        atom/owner

    New()
        ..()
        owner = usr
        if(!owner) return
        if(!owner:target) return
        projectiles++

        loc = owner.loc

        if(owner.target == loc) del src

        //set initial position
        px = x * WORLD_ICON_SIZE + WORLD_HALF_ICON_SIZE
        py = y * WORLD_ICON_SIZE + WORLD_HALF_ICON_SIZE

        //calculate angle
        angle = get_angle(src, owner.target)

        //begin!
        spawn update_loop()

    Del()
        projectiles--
        ..()

    Cross(atom/movable/a)
        //if something happens to cross this tile while we're sitting in it, which would happen after initially entering the tile
        //we should check for collide!
        if(a != src && a != owner) collide_with(a)
        return ..()

    proc/update_loop()
        //update position
        src.px = src.px + src.velocity * cos(src.angle)
        src.py = src.py + src.velocity * -sin(src.angle)

        //check if new position is valid
        if(!check_bounds()) del src // ?

        //update x, y, pixel_x, pixel_y to reflect new location
        src.set_pos_px(src.px, src.py)

        //did we enter a new tile?
        if(last_x != x || last_y != y)
            last_x = x
            last_y = y

            if(!loc) del src

            //collide with everything in the tile
            for(var/atom/a in loc.contents - src - owner)
                collide_with(a)

        //do it all over again, unless the world is slow, then wait a little longer
        spawn(world.tick_lag * (world.cpu >= 10 ? world.cpu / 10 : 1)) update_loop()

    proc/check_bounds()
        //checks to see if a pixel is in bounds of the map
        if(px < WORLD_ICON_SIZE || py < WORLD_ICON_SIZE || px >= (world.maxx + 1) * WORLD_ICON_SIZE || py >= (world.maxy + 1) * WORLD_ICON_SIZE)
            return 0
        return 1

    proc/collide_with(atom/a)
        //generic collide
        if(a.type == src.type) return
        //world << "[src] collides with [a]"
        del src

pixel_projectile/test
    icon = 'demo/gfx/mob.dmi'
    icon_state = "bot"

Assumes:
-all atoms have a target variable which is equal to another atom at the time of firing. not necessary but I use that to calculate the angle at which to fire.
-assumes the owner is a mob, not a turf or an obj
-assumes the person who created the projectile is the owner
-this is a very basic projectile, there are many other cases where you might want the projectile to die (like if it runs into walls). those aren't handled here for simplicity sake of just making the fastest possible pixel projectile.

What I would really like to do is put delta_time in there somewhere so that as the loop updates get further apart from over-processing time... the projectiles actually move along at a frame independent speed.

Anyways, other than that, I don't see room for improvement. Anyone here be my guest and make a suggestion for improving the efficiency of the pixel_projectile!

Why you should NOT post about ads being removed.

Fri, 24 May 2013 23:10:16 +0000

Let's just make it very clear to a lot of people who don't spend a lot of time on the forum and aren't fully aware of the situation...

The ads are here to stay, and if they don't earn enough revenue, BYOND is being shut down indefinitely. If BYOND shuts down, that means no more BYOND games, no more live servers, no more master servers, no more key servers, no more passport checks, no more scoreboards, etc. etc.

Instead of complaining about the ads, try buying a membership to make them go away. Instead of whining about having to watch a 30 second ad while your game downloads, tell your friends about BYOND because the more people who come to visit, the more chances BYOND has of gaining new fans, developers, memberships.

If you are too young to understand; the world revolves around money, and nothing is free. The servers that BYOND runs on aren't free, the programmer who fixes the bugs and adds the feature isn't free, food isn't free, rent isn't free, web space isn't free. If you aren't willing to pay for these things, then sit back and watch those lovely ads who are keeping this alive for you.

This is actually a desperate act on behalf of the developers, and the more you moan and groan about the situation the more apt they are to just give up and leave this mess of a situation behind them.

So you decide!

How will developers be able to handle server transitions?

Wed, 22 May 2013 16:57:18 +0000

Please see video: http://youtu.be/b7ubZ2C0Vn8

I am asking, what functionality will BYOND enable to developers to make server-to-server player transfers smoother / more game-related and themed? I would be concerned if we were not given the ability to intervene with at least a splash screen during this process.

Thanks.

Let's talk about transferring players from server to server

Wed, 22 May 2013 15:21:11 +0000

Let's talk about transferring players from server to server

Most basic implementation:

mob/var/last_x
mob/var/last_y

mob/verb/start_server(t as text)
    var/server = startup("realms.dmb", t, "-trusted")
    world << server

mob/verb/go_to_server(t as text)
    src.last_x = x
    src.last_y = y
    world << "[last_x],[last_y]"
    var/savefile/F = new("players/[ckey].sav")
    F << src
    world.Export("[t]?transfer", F)
    src << link("byond://127.0.0.1:[t]")

world/Topic(T)
    if(T == "transfer")
        world.log << "importing a mob!"
        var/savefile/F = new(world.Import())
        var/mob/m = new
        F >> m

mob/Login()
    ..()
    if(last_x)
        src.x = last_x
    if(last_y)
        src.y = last_y

mob/Logout()
    del(src)
    ..()

Issues to discuss:
1. Security. How do we only allow transfers initiated by the server, and not by malicious users
2. Interface seems to work great here, in the past there was mention of the problem that the dream seeker on the client end would close entirely, and then reopen. I don't think that's the case now, as tests on my local machine have produced smooth transitioning.
Edit: Remote testing revealed that the client does indeed fully close during transitioning.
3. Waiting... It says that these Import() calls are blocking... does that mean the local server will be frozen while the file transfer occurs?
4. Features. How do we expand this to offload specific areas of the map to be hosted in separate instances, how do we allow AI creatures to inter-server travel, what other type of functionality should we pursue? How do we extend this to allow private client instancing but still keep an eye on anything the client might be trying to modify...

Cheers!

Still being shown ads even though I'm a member

Mon, 20 May 2013 13:31:59 +0000

Wish I had more info for you but I have no idea how the ad system works... Sometimes it still shows me ads even though I am a member.