UnrealAdminWiki

A while ago I finally finished some work on the wiki for the UnrealAdmin page. It's an modified version of the MediaWiki wiki engine (the same one as is used for WikiPedia). One of the more important things I modified was to hook up the user system with our main site that was powered by vBulletin. It's isn't as easy as it looks. Because MediaWiki is quite limited in the username format, only alphanum and _ are allowed. But vBulletin allows pretty much everything. This create a very annoying problem. How to hook up those users. I could imply convert the username to MediaWiki style, but this could create name clashing. So instead I ripped out the whole User namespace support and changed the way usernames where parsed. Username will now foward to the vBulletin profile page for users that exist. Some of the changes required modifing original files (which I don't like). So right now when a user type ~~~ (for a signature) it will be replace with a new tag [[profile:uid|Username]]. The username is ignored in further processing, it's only useful when editing a page and still being able to see the actual username. All links to the user namespace, [[user:Username]], will also be rewritten to an url to the vBulletin profile page (if the username can be found). Now this creates another problem, some usernames can contain characters so that [[user:Username]] doesn't work well. I fixed this by adding some magic: [[User:?|Username]] will work for these usernames and still allow me to look up the actual info.

If you are creating a new site with MediaWiki (or any other wiki) and vBulletin simply limit the characters that people can use to alphanum and the underscore (or space). This will save you a lot of work.

Besides the vbulletin integration I also made a couple of other extentions, pretty much all are available. While working on extentions I found out that MediaWiki doesn't really make it easy to develop extentions. Sometimes you need to change stuff deep inside some routines, or at least on certain places. Then you'll find out there are not enough hooks available to get to the right place. vBulletin 3.5 did it much better. For example simple things as adding ACL for pages isn't possible without modifyin the original code. But then again, MediaWiki is one of the nicer PHP powered wikis I've found so far, and their text syntax is nice too (much like the syntax UnrealWiki uses).

UsUnit

There you've got it. The second more mature release of the UnrealScript Unit Testing Framework. A few minor changes to the real framework. More important is a working WebAdmin module.

So far UsUnit contains some graceful code, some somehwta hacky code and some scary code. For the webadmin module I tried to create a better PlayInfo to HTML converter that the one that was already present. Actualy, the existing one couldn't be use in arbitrary places. My converter current supports just check and text types, but also arrays. My initial idea was to auto detect arrays, but because of a bug in PlayInfo's validation code for TEXT render types this can't be used. Instead you will have to use a CUSTOM render type which will figure out of it was suppost to be rendered by the TEXT type. For the TEXT type I also made a special case of numeric values. If the extra data contains range information it will be used to show a specialised text filed with a plus and min button and it will respond to certain key events (up, down, home, end, pgup and pgdown) to modify the value.

An other tricky issue I had to solve was to add some logic to cope with possible invalid test classes. The test class configuration uses strings. It might happen that a single entry isn't a valid name for a class. But during configuration I don't want to remove those entries, or change them at all. Therefor I added a displacement array that keeps track of the array index differences between the two arrays.

More information about UsUnit.

UnrealWiki Developer Journal 17-09-2005

It has been a while since my last dev journal entry (again). First a little update about my last entry. I'm no longer actively working on a VisualStudio AddIn. The features I wanted to add required me to write a VisualStudio Package instead of just an AddIn. Writing a package isn't as simple as writing an AddIn. I hit an issue while implementing the basic framework that I haven't been able to resolve (devstudio gives me an error when I want to load a few things here and there). So that project has been put on ice.

As for other projects, a while ago I continued some development of LibHTTP and got a bit annoyed on my testing class. So I decided to make a testing framework based on unit testing. That's how UsUnit came to life. Because I wanted to include the source file and line where a check failed I had to write an UnrealScript PreProcessor, and I also wanted a few other features that a precompile could accomplish. And that's why I created UCPP. Well, UCPP had some releases, and it quite mature and finished right now. So I've gone back to working on UsUnit some more. I've already made one release so far. But this was mostly to put out the first binary package for people to play with. You could consider it a beta release for now. I want to complete just a few more things for the next release, it can be summed up into: finish the webadmin module.

Also, today barnEbiss contacted me if I was interested in helping him with a weapon mod. His idea is quite interesting. He wants to create a weapon that allows you to create a line of gasoline and set that one fire (the fire ofcourse will hurt people). It's quite an interesting weapon to create, with some interesting implementation issues to solve. So I will also be working on that project.

Well I guess that's all I have to say about that for now.

Readonly UnrealWiki mirror

BeyondUnreal has been offline for a couple of days now. And because the UnrealWiki is hosted on the same machine so is that site. It kinda sucks, because now nobody can get any information from that site, unless they have a copy of the offline unrealwiki. I've created a UnrealWiki mirror using the offline copy. It's not perfect but at least you can still view all documents. The offline copy isn't great to use as a mirror because the case of the characters in the page names have been lost and subpages don't exist on-disk. So a direct link back to the original wiki page isn't possible (unless when you use the link at the bottom). It would be nicer if there was some way of distributing the unrealwiki over multiple servers, but I guess the wiki engine must be designed for that or else you would get annoying edit conflicts.

UsUnit + UCPP

Well I laid my plans for a VS.Net Package aside for a while, kept getting annoying errors outside my source code. I'm been working on a UnrealScript Unit Testing Framework, somewhat similar to DUnit and JUnit. It's called UsUnit. It's almost done, but UnrealScript doesn't allow me to do certain cool things (like point out what check() failed). For this I started to create a PreProcessor for UnrealScript: UCPP

UCPP stands for UnrealScript (Class|Code) PreProcessor, the extention for UnrealScript classes is .uc so therefor UCPP, I'm not sure what the 'c' stands for. So far I've implemented quite some useful features:

• #define NAME VALUE
• #if EXPR (#else) #endif
• UpperCase words in the code are replaced with thier definition according to a previous #define statement

The expression in the #if is quite extensive, simple boolean evaluations and some basic math functions.

But my current problem is with defining function macros:

#define DUMMY(a,b) DoSomething(a, b)

DUMMY("bla", 12345) -> DoSomething("bla", 12345);

I'm having problems to create a nice way to implement this feature. I don't want the definition list to be depended on a parser, but how do I process the definition to replace the arguments. a should be replace, but aa or "a" shouldn't be replaced. A simple replace text routine won't work. I could write an event
OnParseArguments(args: array of string; func: string; var OffsetList: TListOfSomeSort)

args

the argument names as specified in the name; this is simple to parse

func

the function part of the definition

OffsetList

Will contain the positions of the of the argument names in the function string; length isn't required since it's known.

The user will then have to assign a function to this event that will do the real parsing. However, this doesn't solve the magic entities in the macro definition (e.g. # and ##).But I guess that can be hacked in to the offset list in someway. Or I can add self and give direct access to the object that is actually being parsed.
The function definition only needs to be parsed the first time it's used. I can throw an exception when a definition can not be parsed because the event is not assigned.

UnCodeX releases

I think I need to make my release schedule for UnCodeX a bit shorter. It has been almost 1 year since the last stable release. And I've only had a few major stable releases since the beginning. So right now, I'm going to finish all tasks that have a priority of 7 or higher and then I'll release a stable version.
Ofcourse I also need to update quite some documentation, specially the PascalScript part requires a lot of documentation work. I'm not really looking forward to do work on that part of the documentation. But there's not much choise.

I hope to release a new version before the last one is a year old, I think two weeks, but maybe a little more.

UnrealWiki Dev Journal 27-09-2004

UnCodeX Tribes:V ponderings:

Interfaces

Currently, there's only one root for the class tree. I'm going to add a new root item "Interfaces" that contains all interfaces.

Interfaces don't have parents, so this would be the best choice.
Things to think about:

• auto expand Object works differently with more than 1 root node
• no create subclass menu item for interfaces

Defines

I may have to redesign my complete parsing system. Maybe have to move it to a single pass parser. Right now I first construct the class tree, after that I analyse all the classes. This might not be possible anymore because of the #if ... #endif macros.
I'm pretty sure it's not possible to have a different class name, however, it might be possible that the parent class can be changed using these macros. So I would have to construct the tree and analyse the packages at the same time so all #defines are catched. The best method might be to mimick the way the unrealscript compiler does it: per package. This ofcourse would re-introduce the package order mechanism. This would be the nicest solution.

The other solution would be to extend the package scanner to parse through the whole source file every time just to capture the #define, #if...#endif macros.
Another thing I need to know is if the #define macros are system wide, or only for the subclasses. Most #defines are afaik in the Object class, so that would automatically make them system wide.
Also I would need to implement a expression evaluator for the #if macro.

Imports

Depending on what the import directive does I might have to implement this too. Mostlikely it's just identical to the #import macro, which will simply import type declarations. In this case I don't need to change anything (except to ingore the import lines).

UnrealWiki Dev Journal 24-09-2004

LibHTTP 3 is getting pretty solid. I've added a test class to perform various requests. I already found a few minor bugs using that test class, bugs that have been in there for quite some time.
The build is currently 133KiB, I'm not going to strip source from the package because of the simple reason that you can no longer use the package during compile time, only run-time. Stripping the source would reduce the package to 54KiB.
I've been thinking about creating a better source stripper. It doesn't strip the complete source, only the function and state body. The result would be that the TextBuffer (that usually contains the source code) only contains the declarations. This should be enough to use the package for compiling, and have a minimal size. I would add a comment to the top of the TextBuffer explaining that the code was removed to reduce size and stuff. However, creating such a tool isn't every easy. You can't simply replace the TextBuffer with a new one, you will have to update all the offsets in the file. Note that this tool is not for code protection, because you can still decompile the package. It's just to reduce the size.

UnrealWiki Dev Journal 19-09-2004

Well found some time to work on LibHTTP version 3. So far I've made the following changes:

• Improved easy of use: get(), post(), head()
• Support for multipart/form-data POST data
• Two different transfer modes: Normal and Fast (tries to download as much data as allowed within a single tick)

Previously you had to use HttpRequest to perform a request. I made this function protected and added functions for each HTTP request method. The HttpRequest function wasn't really a nice way to perform requests. Now you will have to set the cookie data before doing a request. You can't include it with the request function (was kinda useless).
As for the POST request, now both x-url-encoded data and form-data request bodies are supported. I've added some easy to use functions to add form-data fields. Using multipart/form-data you will have much more control over the posted content, for example it's possible to use Base64 to send binary data.
I also added a additional transfer mode: Fast. This will try to download as much data as allowed (defined by a couple of variables) within a single tick. This is usefull when you need to make sure certain data is downloaded as fast as possible and system impact isn't a big issue.

That's pretty much all the ideas I had to put into the new LibHTTP version, if you have requests, let me know ASAP.
Also LibHTTP3 will be shipped with the source code stripped from the binary package. This is to reduce the file size (87 KiB vs 33KiB).
Ofcourse the source code will be included seperately with the package so you don't have to download it via CVS.

downloads.UnrealAdmin.org

Ok, finished the new download section for the UnrealAdmin page. It's a rather gloryfied directory listing. With a couple of nice touches.
It will automatically include the README file, if it exists, in the directory listing. This is useful for directory descriptions.
Also if the file has an MD5 file (filename.md5) it will be added below the filename on the listing.
Additionally, when there's a text file attached to a other filename it will show a like [toggle info]. This link will open/close the text file inline with the entry in the directory listing. This feature can be used to display the readme file per file. Very usefull for patches.

To protect the download page from being abused by other site, deep linking directly to the files so it will look like they host the file, I've added checks on the referer. If a browser doesn't send a referer, or adds bogus data, a cookie will be used to check if the user saw the notice that UnrealAdmin.org hosted the site. Ofcourse this check will only be done on full featured clients like Mozilla, Opera and MSIE. Clients like lynx, links or wget will directly download the file. So when server admins can simply download the file directly to their server from a shell.
I don't really like this protection, but it's needed because there are quite some assholes out there.

Future additions to the download page will be at least:

• search feature
• stats? (or maybe just Webalizer Output)

Also we could use some mirrors (hosts that mimick hour directory structure and files so we could link to them directly). I haven't thought out yet how I'm going to add the links to the directory listing, but I'll figure that out by the time we have a mirror.
I was also think about giving Epic and Ryan Gordon an account on the machine to upload beta patches directly for an instant mirror. The last beta patch for linux failed completely because Ryan's "0day" server was overloaded.

UnrealWiki Dev Journal 09-09-2004

I've been rather busy with school the last two weeks. So I haven't done much.

Unreal Kart: nothing much has been done, I need to "re-activate" the team, they have been slacking. In the meanwhile I've been experimenting with bot AI and path finding (to understand it better). This experimentation will result in a new gametype: Deluder

Deluder: this new gametype is a tribute to the Developers of Incredible Power. It's a rather nice gametype from an old FPS game (you might now it). This gametype might be the first step on converting more of that old game. Right now I use it for experimentation for Unreal Kart to better understand bot AI and path finding. The most important part of this gametype is a roaving token that runs away from the players, so it has a somewhat reversed hunting AI. It's rather interesting, usually you want pawns to go somewhere, but in this case I want to pawn not to go somewhere. Right now the pawn tries to move away as much as possible. However, quite often it runs past the current players, and I don't want that to happen. So, in one of the test levels (Albatros) it get's stuck on AIMarker8, the AI script of that marker doesn't do anything usefull, and the pawn doesn't just jump off the ledge for some reason, so I have to figure out what it should do there.

UnCodeX: haven't done anything since the HTML Hints for the the application. Soon I hope to implement PascalScript in the documentation generation. But my motivation for this project isn't that high, for some reason it's not really recognised, maybe I just expect too much of it. UnDox received a shit load of attention, but UnCodeX is pretty much not present, or maybe I just don't see it. However, I did receive an email from Bruce Shankle a long time ago, he was quite impressed with it. I really wonder how many people use UnCodeX.

LibHTTP: I'm working on a new version of LibHTTP, version 3. This version won't be completely backwards compatible, even tho it has the same base code. This version will ofcourse contain a couple of bug fixes (actually, just one at the moment, and it was only a bug for the UT2003 build). Some of the new features will include: easier usage via get(), post() or head() functions. Also a faster download mode when download speed is ciritcal, this will try to download more data each tick (ofcourse with setable thresholds). I'm also going to implement a document cache, and maybe some some binary options. Anyway, if you have any feature requests, let me know.