Audeuro's site

DreamConfig Pre-release Testing

Sat, 19 May 2012 04:47:02 +0000

Years ago I wrote and released an application called "DreamConfig". It's intended purpose was to provide an easy-to-use command for adding/deleting hostbans that didn't make you think about flags, line formatting, and all that jazz. It had what was probably all of one user (myself).

With the most recent update, hostban.txt now gets reloaded (in 30s intervals) if a change is made. This allows for us to actually use session-based bans. Because of this, I decided to re-write DreamConfig and open-source it this time. I wanted to get some pre-release testing done, if I could, to make sure I didn't miss anything. I've already done some testing myself, but there's no real test better than normal usage.

You can grab the binary that I compiled and packaged with tar here. There might be some issues with glibc versions, so let me know and I can re-compile it with an earlier version. If for some reason you don't want to trust my compiled version, or you can't get it to work and want to compile it yourself, the source can be found here. Once you have git installed, it's as simple as:

git clone git://git.audeuro.com/dreamconfig.git

And some usage information:

DreamConfig [action] [options]
        action:
                ban
                unban

        options:
                -a
                -key banKey
                -ip banIp
                -type banType
                -reason banReason
                -message banMessage
                -pid sessionPid
                -time expirationTime

        banType: (Optional) Must be one of: 'sticky' or 'key'.
        sessionPid: The PID of the Dream Daemon process that this ban should apply to.
        expirationTime: The length of time (in seconds) from now that this ban should last.

* If the -a flag is set, only sets options that are present.
* banMessage and banReason must be enclosed in quotes.
* banMessage is displayed to the user.
* If expirationTime is not expired, the ban will be permanant.

I removed the friends functionality that was in the first version for now. Any suggestions or feedback you're welcome to post in this thread.

Forum search?

Fri, 06 Apr 2012 21:58:58 +0000

I noticed on the changelog that the "More Info" links link to two different searches- one in the 'Bug Reports' forum and one in the 'Feature Requests' forum. Is that just coincidental, or are searches in individual forums supposed to act more like the "forum:5 resolved" behavior from the previous iteration?

Looking for old thread from developer forums.

Sun, 19 Feb 2012 00:27:13 +0000

There was an old thread from the developer forums about compiling shared object files on Linux that DD would actually be able to read. The exact title of the thread was "Linux DLL's aren't working; possible byond bug?" and it was post ID 755319 by I believe Android Data. It appears to have been completely lost in the transition, as I can't find it anywhere with any searches.

That propagation issue

Thu, 26 Jan 2012 07:06:16 +0000

Tom, Lummox- I'm not entirely sure whether you actually messed with the nameserver or not other than changing the record data, but next time you might consider dropping the TTL to a lower value (It sits at 86400, which is 24 hours, by default) a day before the update so that the propagation in the worst-cases you've seen won't take so long.

Conclusion

Fri, 06 Jan 2012 06:39:16 +0000

The title has nothing to do with this post other than that it's probably going to be my last one on this blog. I've got a personal blog that I'm going to be trying to use more often than I do now to show off projects that I have going on.

Before I go off on a tangent about my current projects/set of projects, I have my own personal set of mini-rants about the site updates and some things that have stemmed from it.

The first mini-rant is about this 'cash shop' idea people keep trying to throw out there. Cash shops are a good idea, but it's not something that should be integrated into the BYOND site and software.

From a design perspective, it doesn't make much sense to have a cash shop for your game created by the people that wrote the software you made your game in. From a player's perspective, it's also confusing to have to use this third party system for a cash shop. From Tom/Lummox/BYOND's standpoint, it's an implementation nightmare. It's easy to tell them that they would do well with adding a cash shop for micro-transactions, but when it comes to actually implementing that and integrating it with the software it sort of blows. There's so many different scenarios that you have to consider such as items with one use, items with multiple use, lifetime items. Then you also have to consider how it actually behaves, if it should be broadcasted to all servers, one server, a polling method.

The only realistic way to implement it would really be just offering the items and then making the developer poll for that information, keeping track of real uses, and also making them responsible for 'clearing' the purchase in that the item is no longer available to the user. Even then, that's sort of ugly and you're better off just implementing it yourself.

My second mini-rant is about the update itself. It's awesome. As someone that's had to deal with problem users on the front page and as someone that tries to keep up with recent going ons, it provides a much more organized method of doing so. Instead of traveling back and forth between the members page and the forum, I can instead stick to one place. That's all on that topic.

The rest of this post is dedicated to my recent project. I'm working on a 2D renderer so that I can participate in the next Ludum Dare. It's actually a three-part project, the renderer, the scene (map) editor, and the sprite editor. I had done quite a bit on the renderer to the point where I'm pretty happy with it.

This is the renderer itself. Basically, it has three categories of renderable objects: Scene objects, dynamics, and overlays. The scene objects are managed by the Scene class itself. Dynamics are drawn next and include what would typically be implemented as a /mob or an /obj in DM- anything that can move. The third category is overlays, which would be things like the command console and any sort of HUD. The picture is about how far I've gotten on it so far.

The second part of the project is the sprite editor, SpritED. It's not a sprite editor in the sense that it edits images, it's a sprite editor in the sense that it takes 24-bit bitmap spritesheets and makes sprite definition files out of the information I give it, including state names, bounding boxes, and animation information. It is complete, as of now (except when I started writing the next section I realized I forgot to add in a density toggle :\):

(Clicking does not open thumbnail viewer)

The final part is the scene editor, ScenED. It loads sprite definition files and allows them to be placed on the map. There's not much more to it than that.

(Still no thumbnail viewer)

Oh, and a picture showing off the command console:

That wraps that up. Happy 2012, y'all, and I'll see ya around. Maybe.

[EDIT]

To clarify or shorten up my point about the new layout, it's basically lurker's paradise and it makes me happy.

Doing Stuff Badger

Mon, 19 Dec 2011 06:45:20 +0000

Sorry, there's no badgers here- I just needed some filler for the title and that was the first word that popped into mind. I thought I'd drop by again to mention a project that I recently started.

Years ago, I started out on BYOND messing around and never actually accomplishing anything. (For a mostly complete auto-biography of my BYONDlife, see a few posts back) To this day I still haven't really accomplished anything other than, alongside Tiberath, helping bring up one of the greatest guilds BYOND had in those days.</bias> Recently, I came to the realization that it wasn't that I just wasn't satisfied with where I thought BYOND was going (which I've recently reformed my opinion on), I just wasn't really satisfied with BYOND itself (through no fault of BYOND's, mind. I guess I just started losing interest?).

So, I started working on a game outside of BYOND.

This is the first bit of real progress that I made. Not only was I able to load the multi-colored squares from a sprite sheet, I re-used that functionality for the text and managed to get my terribly-drawn font on the screen. Oh, also, FPS counter.

The next bit of progress I made is evident in this picture. I set it up to limit the frame rate from the 1300 fps I was experiencing in the first picture to 60 fps and added a render queue to it. Rendering a new tile on the screen was as simple as deriving from IRenderable and adding that to the renderObjects vector in the renderer's class. The black square is a result of 64 squares being created and added to the renderObjects.

This next one was taken during a time of much frustration and sadness. I set it up so that it didn't render objects that weren't in view of the camera (I messed up part of it in this screenshot, don't judge me), but in doing so I ran across a strange bug where my primitives (the black square and the console) were flickering whenever my text at the bottom was updated at a quick rage. After four or five hours of debugging, I determined that that was a direct result of keeping 2D texture mapping on when I drew my non-texture mapped primitives (whoops!)

The last picture is about where I'm at right now, having been at work since I fixed the problem with not turning off 2D texture mapping. The point of this post wasn't really just to point out that I'm actually doing something for once and pointing out a bunch of screenshots of nothing interesting at all.

A few posts back (the auto-biography one), I expressed much discontent with BYOND that might've come off too incredibly negatively. That wasn't really my goal of that post, it just sort of turned out that way. Last Thursday and Friday, I decided I was going to actually try writing a game in Java to show the people I've come across saying that I dislike Java because I don't 'know' Java why I hate Java. I spent a few hours on it and wrote exactly 8 classes before I realized that I hate Java and gave up.

After that, the Ludum Dare took place (Saturday and Sunday). Watching various people work on their games and listening to the great music, I was inspired to start working on a serious game again (except not in Java).

Some time between the second and third screenshots, it just sort of hit me. Here I was, working on (eventually, ) a game in C++. Just working away, thinking through my problems. Getting frustrated in the process, but managing to get by. I started out with BYOND long ago and slowly evolved into lower-level languages. If it wasn't for BYOND, I would no doubt be a crack-addicted gamer monkey hiding in a ditch somewhere. Alright, that was an exaggeration, but I wouldn't be where I am today if it wasn't for the effort put into BYOND by Dan, Tom, Lummox, and everyone else that's put in work on the project over the many years.

So I suppose this is mostly an apology post of sorts. My last on the BYOND subject was sort of harsh and overly-judgmental, and I didn't really want it to come off that way. I hope BYOND lives on forever (one can dream, right? Surely Tom or Lummox have achieved immortality) , as this is where my roots are.

That is all.

Savefiles - Buffered I/O

Wed, 14 Dec 2011 07:13:39 +0000

I'm sure I've had a previous post about DM's /savefile's before, but I figured I'd go ahead and make another one for this feature of DM that so many people over-look when using savefiles.

Let's look at this snippet of code:

var/savefile/F = new
F.cd = ckey
F["Hi"] << "There"

What is this doing? The first line creates a new savefile (with no explicit name, so a temporary file). The second line navigates within the savefile to the `ckey` directory. The third line writes the string "There" to the "Hi" directory in the `ckey` directory of the savefile. Now let's say "Hi" was our variable, and now we want to store an "MP" variable.

F["MP"] << 6

This is how one generally goes about storing separate variables- one directory is delegated for each variable. This is, by default, how Read()/Write() do it. Why? I can only imagine because it's incredibly flexible. If you add or delete a var from the object, none of your other vars are affected.

That's good, from a developer's standpoint. They don't want to have to do that much work to ensure that stuff doesn't break, but what about from a server's standpoint? What are the implications of having a one-to-one directory-to-var relationship in your saving?

Bloat. Without going into too much detail, every directory you create adds on another 14 + length(directory name) bytes to your savefile. This may not seem like a lot when you only have a few vars, but what if you have, say, 10 vars? That's an additional 140 bytes + the lengths of all of the names. 140 bytes? That's not too bad. What if you want to allow the character to have up to 3 characters (seems reasonable) per key? That's a good 140 * 3 = 420 bytes. That's not too bad, right?

Well, let's switch back to the developer's standpoint for a second. Upon processing one header, DS is given a parent ID for the node that it has to look-up before it can even read the data. This is organized in a tree structure, so generally this won't take that long and shouldn't ever be considered a bottleneck. If it is, you might revamp your design.

So what's the point of all of this? Well, there are ways to squeeze every last bit of performance and size out of savefiles that you can. This is done by using them in one of the ways that they were actually intended to be used. Let's look at the following snippet:

var/savefile/F = new
F << "Hi"
F << "There"

What would this savefile look like if we used ExportText() on it?

. = "Hi","There"

Notice that we have stored two strings in one directory ("."). This is because when you open the savefile or change the directory using 'cd', a buffer is created to write the current directory's data, starting at the beginning of the directory. This means that if we were to change directories and then come back to this one and start writing again, the new data will over-write what was already there. Let's look at the entirety of the snippet from above:

var/savefile/F = new
F.cd = ckey
F["Hi"] << "There"
F["MP"] << 6

The second line creates the new buffer for the `ckey` directory. From there, the third line essentially creates a new buffer for the "Hi" directory within, writes "There" to it, then stores it in "Hi", overwriting any data that was there. The same goes for the "MP" line with the number '6'.

But how can we use this knowledge of DS/DD creating buffers for the current directory and appending data to our advantage? Well, we can avoid creating new directories for every single variable and instead store them sequentially in the savefile. The pitfall of this is that if you make any changes to your saveable vars, you need to add that to your code manually and allow for backwards compatibility, usually by having the first entry be a version number for the format, so you can do your reads based on the version number.

I wrote up a small datum to assist in easing into the buffered IO mentality:

BufferedIO
    var
        filename = ""
        savefile/save = null
    New(fname)
        filename = fname
        if(filename) Open()
    Read()
        if(!save || save.eof) return null
        var/ret = null
        save >> ret
        return ret
    Write(data)
        if(!save || istype(data, /savefile)) return 0
        save << data
        return 1
    proc
        Clear()
            save.eof = -1
        EOF()
            return (save && save.eof)
        Open(fname = "")
            if(fname) filename = fname
            if(!filename) return 0
            if(save) Close()
            save = new /savefile(filename)
        Close()
            if(!save) return 0
            del save
            return 1
        cd(dir)
            if(!save) return 0
            save.cd = dir
            return 1
        File()
            return save

Let's say you want to store HP, MP, and ATK vars:

mob/var
    HP = 40
    MP = 30
    ATK = 20

mob/proc/Save()
    var/BufferedIO/IO = new("player.sav")
    IO.cd("playername")
    IO.Write(0)      // Version number
    IO.Write(HP)
    IO.Write(MP)
    IO.Write(ATK)

What does this look like in the savefile?

playername = 0,40,30,20

Now, how would you read this?

mob/proc/Load()
    var/BufferedIO/IO = new("player.sav")
    IO.cd("playername")
    var/version = IO.Read()
    HP = IO.Read()
    MP = IO.Read()
    ATK = IO.Read()

Say you delete the MP var. Remove IO.Write(MP), increment the version number, then if(version < 1) in Load(), you can simply call IO.Read(), like so:

mob/var
    HP = 40
//    MP = 30
    ATK = 20

mob/proc/Save()
    var/BufferedIO/IO = new("player.sav")
    IO.cd("playername")
    IO.Write(1)      // Version number
    IO.Write(HP)
//    IO.Write(MP)
    IO.Write(ATK)

mob/proc/Load()
    var/BufferedIO/IO = new("player.sav")
    IO.cd("playername")
    var/version = IO.Read()
    HP = IO.Read()
    if(version < 1) IO.Read()
//    MP = IO.Read()
    ATK = IO.Read()

Most people won't find this a very useful feature, and more won't ever use it, but if you're really interested in squeezing every last bit out of the /savefile format, I'd give it a shot.

GEE (Getting Excited Easily)

Sun, 11 Dec 2011 10:07:36 +0000

Acronyms might be the new trend. Anywho, I've been working on this project that I briefly mentioned in the last post. It's basically a server/client setup that handles versioning and distribution on the user-level for a project. It's generally meant for use with applications that have a launcher-type setup to download more efficient updates by only downloading exactly what's changed from version to version.

This is a picture of my testing of the basic functionality of the patch client. Up until this point the client didn't actually do anything but send the server some information and the server output it. However, tonight I set it up so that the server not only received that information but it processed and would guess the right version if the serial wasn't given and THEN it would even go so far as to figure out what's changed exactly and send information to the client about the latest version's serial, whether it needs to update or not, and a list of modified files with their CRC32s. This picture represents this all working (save for a minor misconfiguration between one or two of those executions).

The moral of this story, I suppose, is that I put in a lot of effort (the project is almost complete) to get nothing more to show for it than those three lines from the console, but it got me so excited to see that output that I nearly cried. Do YOU have a Black Triangle-ish story?

Conway's Game of Life

Fri, 09 Dec 2011 22:02:05 +0000

Breaking the trend of two word titles, I took a few minutes out of working on my patch server to write and "release" this BYOND Version of Conway's Game of Life (Download link first, wikipedia link second). It's interesting to experiment with.

To use it, first use Create and specify a map width and height. From here, you can either Generate the cells (You can specify a seed here or leave it 0 which won't seed the PRNG at all any further than it's already done by DS) or you can just click on cells to toggle the "alive" state (white = dead, black = alive). Once you've generated the cells or got it set up how you want it, hit "Start" and watch it go. Once it reaches an end, it'll automagically stop and tell you how many ticks it took. It won't stop if it hits an oscillating pattern and you have to Stop it manually or just Create a new map (no need to Stop it in that case).

Public Opinion

Tue, 06 Dec 2011 07:48:52 +0000

Next week is finals week and then it's Winter break. As it is, my list of things to accomplish during Winter break is relatively small and slowly diminishing. As such, I need something to keep me preoccupied during those long winter days where I find myself absolutely bored.

So I've decided to do a public survey of sorts. The idea is that I ask you what I should work on over the Winter break, then you write in the comments of this post something relevant to the question, preferably answering it to some extent. Restrictions for answers:

Must be programming or technical design related
If it's a programming project, it should be language agnostic unless it's DM-specific
May or may not be relevant to BYOND

The first two are restrictions, the third is more of a statement. I'm terrible at anything that isn't programming, and the thing I'm least terrible at in the other group of items is technical design. I will take a weighted average of the serious answers and determine from there what I'll be spending my spare time on.