Theodis's BYOND website

Tiny Priority Queue update

Tue, 13 May 2008 21:32:02 GMT

Just updated my priority queue library and added in two simple procs.

List() - Returns a list version of the queue leaving the original queue in tact

RemoveItem(i) - Finds and removes the item i if it is in the queue.

http://www.byond.com/developer/Theodis/PriorityQueue

Racing Game update

Mon, 31 Mar 2008 23:20:15 GMT

Just made an update. Give it a shot if you have version 414 of BYOND. If you aren't running Windows 98 or Windows ME you should be pleased(and if you are it'll probably crash :P). I also wanted to see how horribly laggy multi player is but couldn't find anyone to test with. If you can test this please comment.

http://www.byond.com/games/Theodis/RacingGame

[Edit] For some reason a few junk files ended up in the cars folder. And unfortunately updating can only add/replace files not remove them. So if you want to get rid of the bad car entries so random car doesn't select blank cars delete the zero length files in the cars folder. Also I'm phasing out the maps not made by Foomer since they just aren't at the same level of quality. You can keep them around if you want but they won't be included in the game package anymore.

Took 5+ years...

Tue, 25 Mar 2008 06:23:10 GMT

Took over 5 year but I finally got the feature I wanted for Racing Game! Anyway just added 2 lines of code to have it set the client pixel offsets and it looks wonderful. If anyone wants to see an example of the new client pixel offsets you can check out Racing Game.

http://www.byond.com/games/Theodis/RacingGame

[Edit] Actually almost 6 years now ID:102345.

Wow

Thu, 03 Jan 2008 02:30:23 GMT

When I was 8 I received a junky old TI computer from relatives from which I taught myself to program BASIC. While talking about old computers I was reminded of it and did a bit of searching and found the wiki entry on it. And looks like it is roughly as old as I am!

Anyway a few years after after getting it the part that hooked up to the TV went bad. I tried to take it to Radio Shack and see if I could get a replacement but apparently the part was too old and couldn't be replaced though the guy there was nice and opened it up and gave a shot at fixing it which did get it running for a bit longer.

While talking about it I joked about finding the part on ebay. But apparently it wasn't much of a joke and I ended up finding it. Only 5$ too though an extra 6 or so for shipping. Being a pack rat I still have the computer and managed to dig it up. I tried to power it up but then realized how hard it'd be to tell if it was actually working without the TV hook up since there are no lights on it and no moving parts inside to hear spin up so it's pretty darn quiet if it is working!

I'm real tempted to just blow the 11-12$ on the video modulator just to see if it works since I actually still have a TV that it can hook up to laying around as well.

Another interesting thing I found when searching on ebay was someone selling the whole computer and received this awesome question
"Q: Can this computer run Office 2007?
A: I don't see any way this computer could run current software, but I'm not a computer guy."

Stupid URW region save file

Thu, 06 Dec 2007 07:20:10 GMT

Warning: Unless you happen to be Jtgibson you'll probably have little idea what on earth I'm ranting about and if you are Jtgibson prepare to be appalled!

Anyway for those that don't know I made a character/map editor for the game Unreal World(http://www.jmp.fi/~smaarane/urw.html). A while back the game had a major update and the structure of the save files changed ruining compatibility for my editor. Recently I've been digging around the files in a hex editor cataloging the file format which is nice and easy given the author of the game simply dumps arrays into files making them super easy to figure out. I just figure out the length of a struct by finding the distance between the same strings in two different elements of the struct and then set my hex editor rows to be that length and I got a nice pretty view which each line containing an element of the struct. The full array is dumped into the save file including all the blank entries. So for example a local map(50x50 map chunk which is represented by 1 tile of the world map) can have up to 10,000 objects, NPC, and various other things total. The struct which provides links to these things is 36 bytes in length. Which means the save for every localmap is 360000 bytes + 2500(50x50) bytes for the map tile data, 2500 bytes for storing what tiles you've seen, and 8 bytes of positioning data for where the local map is on the world map for a grand total of 365,008 bytes for every single local map. Since each of the 1024x1024 world map tiles could potentially eventually get one it's a bit frightening to think about. As gargantuan as that is the stupidity of how region name data stored is even worse since it's got a bone head simple solution.

The world map in the old versions was split into a grid of smaller rectangular chunks with clearly defined borders. In a file called globnfo.nfo contained a neat list of names for every one of these chunks. In the new version the borders were done away with and the world map is just one big 1024x1024 map(though in the save file it's actually 1025x1025 with the right most and bottom most column and row being junk).

Opening up the largest save file(when just starting at least) called marker.dat at 42MBs and with a quick glance it's easy to see it was just a list of fixed length strings with lots of repeating, each looking like the region names of the old version. So I set my row length in my hex editor to 42 which was the apparent length of each string max. Next I divide the file size(44,040,192 bytes) by the size per entry(42 bytes) to get a number of entries, totaling at 1,048,576. That's a lot of strings! And being a programmer I quickly enough recognized that the number seemed familiar. So I took the square root and boom got 1024. Then it clicked, the region name of every single tile on the world map was being stored in a correspondingly dimensioned 2d grid. This is just bad in system memory and downright terrible to store it on disk this way. However at the very least it should allow for non rectangular more natural regions right? So I programmed my new map viewer thing to draw a line between any two tiles that have different regions which should produce a nice outline of the borders between regions. This was the result.

@#$%! Every 32x32 chunk of the map is a region. Why the heck did the author have to store that information for every tile!? If he would have just made it a 32x32 array and did some simple math to figure out which tiles belongs in which region the file size would be a mere 43,008 bytes! An even 42KB rather than 42MBs. Loading that stupid file in my editor stalls it for 5-10 seconds on my machine and I bet it does similar things to the game itself when it loads a character.

This game is fun and all but this really shows the lack of programming talent the author has. I might actually have to get around to doing something similar only data driven but I'm not too much for handling researching and filling out all the data necessary.

Up for a project Jtgibson :P?

Pathfinder for C#

Thu, 13 Sep 2007 21:32:18 GMT

Well I needed to do some path finding in one of my C# projects so I ported my Pathfinder library to C# which you can grab at http://members.byond.com/Theodis/files/AStar.cs . It uses generics so at least .NET 2.0 is required.

The algorithm and logic are pretty much exactly the same so any functionality should work exactly the same including any bugs if any. The only difference is some syntactical stuff for parameters and I store the bestF in a dictionary rather than directly on the node like in BYOND. I did this for several reasons. First off if I want to tack on information to the nodes themselves then I need to make the nodes being search either derived from one of my classes or they need to have an interface. This could be a problem if you're working with a data structure you don't have access to the code for or for any other reason can't change. Second reason is that storing information about the search on nodes prevents running multiple path searches on seperate threads since each would end up conflicting by messing with and using each others values tacked on the data structure. By doing this with a dictionary in theory it should be safe to run simultaneous searches(though I haven't tested this yet).

The downside is that it is potentially slower. How much slower depends on how the C# dictionary is implemented and its random access time. If it's good and has logrithmic or constant access time it shouldn't be much of an issue which is likely the case.

I don't have any demos on how to use it but it should be similar to how you'd do it in BYOND except that you'd be using delegates rather than passing in paths for the parameters to the functions needed.

Pathfinder update

Fri, 18 May 2007 10:12:41 GMT

As alluded to in my last post I've added some additional functionality. There is a possibility it'll break code but hopefully that won't be the case.

The Dijkstra proc has been modified so that it can get many paths in one search with no extra cost as it doesn't have to repeat any work. In your finished proc simply return P_DIJKSTRA_ADD_PATH and it'll add the path to that location to the return list and continue searching for more paths. However be aware that the return value of finished is no longer a bool. 0 still indicates not a finish point and 1 indicates a finish point and to stop searching so I'm hoping this won't break any code as those are the common values for true and false people use. Though even if you use them and they work I'd still advise switching to the consts P_DIJKSTRA_NOT_FOUND and P_DIJKSTRA_FINISHED in case I need to change the values in future versions so your code won't break. Also an extra parameter called compatibility has been added and is by default on. This is to help ensure less code gets broken from this update. If only one path is generated and compatibility mode is on the function will simply return the path rather than return it as a list of paths containing one path. If you're expecting the new functionality it'll probably be easier to turn the compatibility mode off so the return value is always consistent.

This should be quite handy as previously to do the same thing would require several searches resulting in a massive amounts of testing the same tiles over and over with the same conditions. Before if you wanted a monster to say chase a player you could have used the proc to find the closest one however for AI reasons that might not have been the best choice. Now you can generate paths quickly(as quick as a single path to the farthest player if done right) to all the players and then have the AI compare the paths or test them to maybe find the nearest clump of players to go at. The same could be done for any other number of scenarios in which you want several destinations and use path lengths/weights to decide on an optimal target which may not be the nearest. This could also be used for detect skills in MUDs. Just set the maxnodedepth to the range of the skill and don't stop adding paths until you've got paths to all the things you are sensing and return a list of the stuff the player sensed all in one quick search! Or maybe you have an RTS game and want to pregenerate paths to all the nearby resource nodes from a given drop off point. Piece of cake and quite fast to do now!

Well hopefully this update helps a bit for path finding. And given how powerful and efficient this library is no AI should ever be lost unless it is intended to be!

Annoying DM list merging

Thu, 17 May 2007 21:40:39 GMT

While debugging a new feature to my pathfinder library I ran into an annoying problem. When using list.Add() and passing in a list it merges them and the same thing happens when using the + operator(which after reviewing the reference happens to be intended :P) this behaviour however is very annoying if you don't want a combined list rather a list of lists. Or in my case a list of seperate paths. Anyway if anyone else is trying this my solution to forcing the add rather than merging is this

var/L[] = new()
var/L2[] = list(1,2,3)
var/L3[] = list(4,5,6)

L[++L.len] = L2
L[++L.len] = L3

Which will result in L containing 2 seperate lists rather than one merged one if add were used. This feels a bit ad hoc so if anyone has a cleaner solution please comment :P.

Yet another Pathfinder update

Tue, 15 May 2007 10:07:16 GMT

A minor bug was found in the last version. Basically when checking for adjacent nodes it also checks to see if the adjacent node is the finish and if it is it just darts to it completing the path ignoring the cost of the transition. If all directions leading to the finish are the same(which is I assume most cases anyway) then this isn't a problem. However if they are different then the last version was generating incorrect paths. Now I'm putting the node on the queue even if it is finishing and performing the check to see if a node is the destination after dequeuing it. So it should handle these cases fine now. If the new version breaks something for you just leave a comment.

http://developer.byond.com/hub/Theodis/Pathfinder

Where's my kingdom?

Sun, 22 Apr 2007 12:55:35 GMT

On a somewhat related topic I got around to updating my pathfinder library implementing a few suggestions made by Iain. This version should help significantly speed up cases in which you don't want any long paths generated in favor of speed.

The maxnodedepth lets you specify the max length of the path and if you set a minnodedist proc you'll be able to eliminate testing of a huge number of nodes.

However one thing to be aware of is that even though you may get a path it may not be the "shortest". For instance if you let your characters wade through lava and you're on one side of a lava river, the destination is on the other and a bridge is a good distance away. If you set the maxnodedepth to a small value your path will go straight through the river ignoring the bridge in the distance if it takes too many nodes to use even though according to the dist proc passed in it may be shorter to use the bridge due to the high weights of the lava tiles.

http://developer.byond.com/hub/Theodis/Pathfinder