Worst-case scenario: the UEd Goblin wipes the map and burns down your house.

Legacy:El Muerte/Developer Journal

From Unreal Wiki, The Unreal Engine Documentation Site
Jump to: navigation, search

Journal History[edit]

  1. Legacy:El Muerte/Journal History 1
  2. Legacy:El Muerte/Journal History 2
  3. Legacy:El Muerte/Journal History 3


New phase, clean dev log.

Started working on Unreal Kart (like I said). Now the difficult part will start, the actual development. Could use another mapper to help with creating some initial maps to improve the development of the tracks. I hope AlphaOne will be able to use the experience he get got while making StrangeLove on the karts. They don't move like I want. I also need to write a little tutorial on how to map for UKart, this should be pretty simple (use our Track volumes to define the track, and how to use the player positions).


MSUC Phase 3 Tools finalists have been announced :(

Mychaeel: Yeah :-/ – I can only guess that they focused on tools for end users or those which directly benefit end users... the only reason why I can imagine that umod Wizard is a finalist and UnCodeX is not...


Well, I was planning to keep regular updates on the progress of my new mod: UnrealKart, both the actual development and project organisation. But so far nothing. So here's a short recap of the past.

This is my first mod where I take the lead for organisation, so I have no idea if it's going well or not compared on how other mod teams are doing. We started slow, in fact the mod idea exists for at least 2 months now, I think, but the real implementation work was only started recently. We had a little "break" until phase 3 was closed, so that people could finish thier other creations to enter. UnrealKart is not going to be a mod to be entered in the MSUC, it's going to be a mod made for fun and because we like it. That doesn't mean I won't submit it for Phase 4 (it's a good PR opertunity if you get in the honorable mentions), but only if we have a release candidate. Back to the project organisation. Recruiting people is quite difficult, sure a mod team doesn't need to have a lot of people on it. But even getting a few members that can dedicate them to the project is quite difficult. There are a lot of people interested in doing something for the mod, but not on a semi-dedicated level. By the time we have a release candidate I expect quite some people to contribute to the project (e.g. Create a track or maybe even a kart), but currently we are not on that stage yet, so it's useless for the moment. Right now 6 people dedicated for the project (2 programmers, 1 vehicle modeler, 1 2D artist and 2 mappers).

As I said, getting people to work on a mod is a though job. You want people that have some experience, so it's easy for them to quickly addept to the dynamic of mod development. The guy (SithLegend) that did the current kart model wanted us to help him with a couple of creations of him, I didn't have any problems with that. Specially not based on his previous work. Our 2D (Zeh) artist can handle himself, he made some very nice concepts for the HUD. Our mappers however need some guidance in their process, this isn't bad. Our mod is a team effort, the team makes the mod, not a group of individuals.

That's all for now, have to feed the kat+kittens of a friend of mine, when I'm back I'll tell something about some programming issues.

part 2[edit]

So far there have been a couple of programming issues I had to solve. The first one was to keep track if the races where either on-track or off-track. An easy solution for this would be to use volumes to tell what the track is. When player enters the volume to set the current volume to that volume. When a user leaves a volume you will check if the volume that was left is the same as the current volume, when they are the same then the user left the track. So when volumes overlap you will first enter a new track volume, this will set the current volume. When you then leave the previous volume the above check fails, so the user must still be on track.

Well that was easy, but now, how do you check a player was following the track. An obvious solution would be to use checkpoints or to check if a user entered each volume. The check so see if every volume was passed won't work because I want the racer to be able to race off-track for shortcuts, or just be a terrible driver. So check points it is. For our mod the checkpoints would be invisible. There are different ways to implement checkpoints, since we already have volumes to define the tracks we can use the volumes as checkpoints. These checkpoints should then be place on places where a racer has to go through. The racer must not be able to pass this checkpoint off-track, this just sucks becuase the racer would then have to go back to pass the checkpoint. Now there are two ways to check if a user passed the right checkpoints. You could keep a list of checkpoints available and check if a user passed them. But this has a couple of issues: alternative routes or shortcuts, where to go. So I added a variable to our volume class that contains the next possible track volumes, usualy this would be only one volume but in case of short cuts or alternative routes this can be more than one. Now every time a user enters a volume it will check if this volume is in the list of "next volumes". The list of "next volumes" is stored for each player seperately, when a user entered the "next volume" the current list will be reset with the list of the next volume. This way you will always know where to go to. Ofcourse the mapper will have to set up the volumes correcty. Every track requires to have a finish volume, this finish volume must be the checpoint first volume. When a user enters this volume it will be checked if the volume was "queued", if the volume was queued the player completed a lap. The finish volume is the only checkpoint that players could miss by racing off track, simply because this checkpoint is always visible. Because we know what volumes should be next we can also direct the racers where to go.

Now that we know how to follow the track we can also keep track of player positions. For this a list has to be contructed that contains the volumes to follow in order (e.g. the next volumes). Now all we have to do is sort the players based on their lap count, next volume, distance to the closest next volume (in that order).

T1: In the mod I'm working on (Momentum Control, a wipeout-ish racing game.), I was planning to use the same method that the bombing run goal uses (An invisible smesh in the center that does the scoring when it gets Touch()'ed.). But volumes are an excellent idea, because you could detect if the player just goes around a checkpoint. Do you mind if I use that idea in Momentum Control?

El Muerte: published ideas are there to be applied/used/etc. (I think). Anyway, I don't mind, that's why post stuff on the wiki, so that others can find a use for it.

T1: Thanks. I just was asking because some people are strange and would get mad or something like that over it.


Report from yesterday.

Worked out the racer position calculation. At the beginning of the race, when the racers are placed on the grid, I will do a complete calculation of all positions, during that I set for each player the next and previous player in their PRI. After that each PRI will check if the racer passed the next player, if so it will update the linked list and broadcast a message to all players about this position change. I plan to use this LocalMessage to update the HUD of each player to notify the player position change.

I had a couple of issues testing this, with 3 clients the positions where incorrect. It appeared that I made a stupid mistake for the start position calculation.

When players join they will get a start position assigned, first to join will start on the last position (depening on the number of players/bots and stuff). Note: we will also ship a gamerule that will save the last finish positions for each player and use those to remember the start position (e.g. finish last will grant you to start first in the next MP game). Anyway, I made the following stupid mistake:

n = StartPositions-1;
while (n < 255)
	for (i = 0; i < idxs.length; i++)
		if (idxs[i] == n)
	break; // found position

idxs is a list with already in use start positions, the continue was ment to have effect on the while and not the for statement. So the 3rd client would get the same start position as the 2nd :)

Another issue I'm working on is the power-up selector power-up. It's a special power-up that contains a list of real power-ups that will cycle. After it has bee activated (or timeout) it will slow down the cycling until it stops and give you the selected power-up. I want this thing to run mostly client side to reduce the server load, there's no need for it to run server side. So it will become kind of a replication nightmare, I have to replicate the dynamic array with available power-ups, then start the cycling client side, have a timeout on the client, go to the activated state and set another timeout and notify the selected power-up to the server and give it to the player. Right now the server crashes when it get's notified about the selected power-up, pretty odd. But not very important right now.


Ok, so I had an intresting issue. The PowerUpSelector is a inventory item that cycles through a list of powerups until one is selected. Then this powerup is given to the client. The way I programmed it it worked perfectly. But on a client-server setup it would crach the server as soon as the actor was destroyed. What I did was, I called Destroy() is a function that was called from the client on the server (client –> server). Apperently this is not allowed, I solved the issue by using a dirty hack: I set the LifeSpan value to a very low number. This would cause the actor to be destroyed pretty much the next Tick.


Because the tracks in our mod can break a lot of gameply stuff I decided to add a map check routine to the gameinfo class that will check quite some thinks of the current level. These checks are then saved to an external log file so that the mapper can easily find the issues. For example a bad design track will get a broken Track Volume list, after the track list has been created it will be checked for "dead" ends or invalid used tracks. All the assumptions made in the game code that the Track should have should be checked. Sure it would be nicer if I could directly implement it in the editor, but too bad the editor isn't really scriptable.


Ok here was another issue. Our powerups as inventory classes, there's a lot of base code for handling an inventory since Unreal 1. But unlike all the previous Unreal games, we don't want to lose the powerup inventory item when a user dies/recovers. So, for that I could do two things, either move the complete inventory code out of the pawn or create a hack. Moving all the code is just a real pain in the ass, but ofcourse adding a hack is something you shouldn't do. I went for the hack, since the hack wasn't even that terrible. When the pawn dies I move the selected powerup instance to the PRI, then on respawn I will give the powerup back. This way the powerup selector will keep working (cycling through the list) even when you are dead. The reason why I use the PRI is because the PRI is the only common place for both AI controllers and real players. So most of the common stuff I do in the PRI.

WOTGreal ... aaaarrrggh ... the last couple of nightly builds of WOTGreal are really broken, it slows down my development speed. Switching files is very slow, code insight is slow. It's a real nightmare. I need the nightlybuild and not the last stable release because a couple of important issues have been fixed in the current unstable release. If anyone has a WOTgreal build from before july 20th, or at least a nightly build that still working as it should, please notify me.

I changed the plug-in stuff for UnCodeX again, no longer will I support two module versions. I added a function that returns the a revision number (from one of the most important file), and based on that uncodex will accept the plug-in. Because everytime I change a little thing in the uclasses unit the older plug-ins will break, and all it needs to work again is a rebuild with the new unit. So I added an exporter function to the uclasses unit that returns the revision number. I'm also thinking about hooking up RemObjects' Pascal Script to UnCodeX so it's possible to add scripts. This way you'll get even more control on the HTML output, and other program features.

part 2[edit]

Argh, ok, Pascal Script is rather interesting, there's no documentation or hardly any. I'm not really sure how I want to implement it, and how to hook it up into the system(s). If anyone has some requests/ideas of the things you want to be able to do via the Pascal Script interface please let me know.


This Pascal Script is pretty cool, it's rather easy to add functions and types to the scripting language. It's also possible to link variables from the program to the script environment.

For example the following this will be possible:

ShowMessage(Format('Class %s has %d properties'), [SelectedUClass.fullname, SelectedUClass.properties.count]));


There's a little downside to adding PascalScript support. I also need to document each function and class that is available in PascalScript. This is actually kind of ironic, I'm writing a program that can create documentation from documented source code files, but the source code of the program itself isn't well documented.

I guess a simple dump of the syntax of the functions and classes would be enough to start with. There are still a couple of things I have to figure out how they work with Pascal Script. For example it's possible to create units in Pascal Script, but I don't know how to use them. Anyway, I hope to be able to release version 209 soon, it'll have the basic Pascal Script support so that people can tell me what they want, etc.

part 2[edit]

Actualy, working on this PascalScript implementation is quite boring and uninteresting. There's not much to do, just add functions and classes. Maybe I should start looking at the PascalScript hooks for the HTML generation, but still, that's a minor thing to do. I think it's no so motivating to work on because I know I have to spend quite some time on documenting it all.

I wonder how many people are actually using UnCodeX, I know some people are using it. Looking at quite some questions asked on irc and forums a lot people should start using it, or some other method to actually browse the code. Apperently it's easier for people to ask a question and wait until somebody answers it that to search through the code to find the answer. Usually it takes me a couple of minutes to answer that question (depending on how well my regual expression was). People just want the easy way out, because of that they might mis some interesting stuff. While going through a couple of classes to set the external comments I found some interesting variables I never saw before, maybe I'll use them, maybe I wont. But when somebody asks a question that might have something to do with those variables, at least I know how they are called. Enough ranting about that.


Woohoo, Dean fixed WOTgreal, now I'm able to work on UnrealKart again.

Those vehicles remain difficult, still nobody has written a single document on how the ONSVehicle classes really work. There are so many variables, and it's very unclear how they all relate. Maybe I should figure it out someway and write a little program that'll calculate the output or something like that. Plouj told me that the vehicle tick sucks in one way or the other and needs to be rewritten for our purpose. Is there anyone that has a clear picture how the ONSWheeledVehicle works, so that I can get a clear picture or easy method to change all the variables just to influence the final MPH of the vehicle.

I also still need to figure out how to prevent players from moving at certain points, setting bMovable to false or changing the physics type doesn't have the right effects and also break for online play. I need some kind of "park" gear. But apperently the engine RPM is based on the rotation of the wheels, or something, I don't know.

Ah well, another thing I have to look at is the input, I want to be able to use a simple gamepad to play the game. So I have to figure out how those gamepads in the UnrealEngine.


I think I've said this before, writing documentation sucks. I have to document every little thing that's available in PascalScript, it's a lot of boring work. Writing normal documentation like a simple manual for a mod or an article on the UnrealWiki isn't that bad. But this is just boring as hell. I can't really release version 209 without even the most basic documentation, because it's useless unless you dig through my code.

I already have a great use for the PascalScript feature. I added a function to preselect and execute a profile from the new "Run" dialog. When I execute the script it will first ask me how many clients I want to start. After that it starts a server, and at set intervals it will start the requested number of clients. This makes it very easy to quickly start a client\server testing environment for UnrealKart.


Still working on the initial PascalScript documentation for UnCodeX, it's sooooo boring. Ah well...

Yesterday I was messing around a bit with the default input control configuration for UnrealKart. I have it now configured to have the Joystick support enabled by default, and it's configured for a 4 button gamepad, I only have my old Gravis Gamepad here. I wonder how the game behaves when no joystick\gamepad is connected but the Joystick support is still enabled. Playing UnrealKart with a gamepad is much nicer that using a keyboard. I think I'm going to implement profiles for various gamepads\joysticks, ofcourse I will include a nice config window to configure joystick\gamepad. There's still one issue I need to look at, I want the GUI to respond on joystick input, so that you can use your joystick/gamepad to navigate through the menus. So far I've been unable to capture the joystick input in the GUIController.

As for NoMut, I've added an exempt list and safe check so that gameplay important actors won't be removed. I still need to add the bRecurse feature for ReMut. After that all I need to do is finish the documentation :/ and release it.


Wee, finally pushed out the new UnCodeX build. I've only reported all classes/functions/etc that are available through PascalScript, I didn't document it (yet). Also, the doc generator doesn't use PascalScript yet.

I've also finished NoMut, but haven't announced it yet, it's something for the next couple of days.

This morning in #unrealscript on ETG Solid Snake presented an interesting project idea, it's a SP project based on short stories. Anyway, this gave me an idea about interactive conversations through the game, and stuff like that. UT2004 has text to speech and also speech recognision (for Windows through the Microsoft Speech API). This feature hasn't really been documented, so I'm going to take a little look at how this stuff works, and create a little test case of this (just for fun). Ofcourse I will report m findings on the UnrealWiki.


Well this some messing around with the voice recognision. But it look like I have to spend a lot of time training my speech profile before it works like it should. Anyway, I did discover some interesting things that might be usefull. Although I also encountered an issue. It looks like the speech recognision only works when running a listen server or joining as a client. That's odd since it looks like the speech recognision is independed from the voice channels (or maybe not). I will have to look into this.

Also I just rewrote the diff page handler for the wiki for UnrealKart, it now uses GNU Diff to give a nice overview similar to UnrealWiki. I'm trying to make that wiki engine behave pretty much like the UnrealWiki.


For my "cool speech recognision" thing I have to implement the MetaPhone algorithm, and damn what a terrible algorithm. I'm sure Asian languages have a much easier algorithm for MetaPhone. Ah well, as soon as one person has implemented it a lot of people can use it (woohoo, spell checking for ingame chat ;) )

Holding off other development till thursday, after that i have more time to do stuff for UnrealKart and a secret simple, but cool, gametype (it will be a tribute to the "Developers of Incredible Power"). I need a modeler\skinner to make one thing for that gametype.

And before I forget again, mental note: ask BU for hosting a forum for UnrealKart (I hope I will read this in the future).


I was doing some improvements to the unrealwiki mozilla sidebar. But I've hit a couple of walls. For example, it's not possible to open the links in a new tab (ah well). But also, for some reason the pop-up blocker sometimes blocks the "new window". This only happens when opening a page via the menu, or when hitting enter in the search field. In any other case it simply works, the weird thing is that they all use the "oncommand" event.

Anyway, this is the improved sidebar http://unreal.student.utwente.nl/mozwiki/mozwiki.php (still under construction)


Woohoo, finally finished the DoubleMetaPhone algorithm. Almost time to work on the cool Speech Recoginison things.

I've decreased the loading time of the mozilla side bar by caching the "side menu". By default it will updated only once an hour. Also the "update" now only updates the RC list, not the complete list. Also fixed the wrong initialization of the "show minor changes". All I have to do is read the RC file backwards, instead of using PHP's file() function. I have no idea how I can spead that up.


Made some major performance improvements to the new mozilla side bar. It now also accepts very large RC log files. It now get the last megabyte from the RC log file and uses that. This prevents the max memory usage security from kicking in. Also I added a check to see if the local copy of Wiki_Sidebar has been changed since the last cache, if it can find the file. Otherwise the previous timeout method will be used.

I think I also figured out and fixed the sidebar method where it retreived the file localy instead of using a HTTP request.

The only thing I don't like at the moment is the pop-up blocking. I haven't found out why this happens.


Ok, the pop-up blocker is a bug in the current stable mozilla releases. It's fixed in mozilla engine 1.8, however, in that version the context pop-up menu is broken. *sigh*

Update #2

Ok, found out why it didn't work in 1.8+. They changed the way getCellText worked. Now the new sidebar works best with mozilla engine 1.8+ or higher (because of the above bug). I'm going to take a look to see if 1.8+ does allow tabs. Otherwise the new version is pretty much fixed. I think.

Made a couple of other changes, the pop-up window now shows more info and also allows you to open various other links, like: editor's page and history.

If you have any other feature requests for the new mozilla sidebar let me know asap.


No feature requests for the Mozilla side bar? Ok, then I'll forward the code soon.

I've been working on the new Hint Windows for UnCodeX so it'll accept HTML code (to be used for the documentation of the variables/etc.). I'm having a couple of problems to get the window size updated correctly. Most of the times it works correctly, but once in a while it's completely messed up. Can't figure out why.


Finally, I've got the new hint window working. Here's an example of the hint window showing info about an item in the property inspector.



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.


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.


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.


UnCodeX Tribes:V ponderings:


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


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.


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).


Well, long time to entries added. Didn't feel like writing pieces of text because I already was writing and reading way to much the last couple of weeks.

I'd like to point a piece of I wrote on my general blog today, it's relevate to UnrealScript as well. It's about member visibility (private vs protected): http://elmuerte.blogspot.com/2004/12/private-vs-protected.html

I wrote it because I'm updating UnCodeX on some points and I'm running into private walls for some things I want to change.


Current status of activities\projects

  • UnrealKart – dorment, still plan to finish this mod in one way or the other. I want/need somebody to take the role of project manager (or something like it); e.g. make sure people do stuff, recruit new people, etc. I did a terrible job in the beginning, maybe the reason why the mod didn't took off the way I wanted. You simply can't do everything (programming, design, management).
  • Deluder – dorment, not even sure if I'm even going to finish it. I have major issues with getting a nice AI\pathing implemented.
  • UnCodeX – semi-active, need to implement a few things and polish quite some things. I hope to have a new stable release before UnCodeX reaches it's 2nd birthday (couting from the first stable release).
  • Charon (the UnrealAdmin.org download script) – active, bit by bit more get's implemented, no rush really. There are a couple of things I want to add (bittorrent support (tracker and protected seed); mirror support)
  • LaoZi (code repository) – active, currently development is behind curtains. I hope to get it hosted on BU in the end. LaoZi perpose it to provide a nice way to post\organise code samples or even complete packages. The UnrealWiki isn't a very nice place for hosting (example) code. So that's the reason why I'm working on this (as addition to the UnrealWiki).

Ofcourse there are also the other things, like work (1, 2, 3), college stuff, experiments and the usual server administration work.


Got a few minutes before the coffee is ready.

Well the results for the grand finals of the MSUC are in. Red Orchestra won, not much of a surprise. They won quite some prizes in the other stages, but still the mod doesn't tickle my interest (that's why I declined their offer to join their project a long time ago).

However, what is surprising is that the RO team is going to use the UnrealEngine license to publish their mod (filefront interview). I don't get it, why would you "waste" the license you got to publish the mod you made. When they do this they will also turn their back on everybody that supported that mod. Hoewever, on the other hand, many of their team mates left during development, and by releasing the mod as a retail game their get their fair share of it (or do they).

If it was up to me I would use the UnrealEngine for a new project. You already have got a license for an kick-ass engine. So the cost of development is greatly reduced, easier for a publisher to pick you up.

Coffee is ready.


A long time since the last update. I guess I should give a heads up on what I've been up to lately.

Besides the usual work (UDN updates and work for a company called Micronic) I haven't done much on other projects besides UnCodeX. A while ago I released a new stable release for it (version 227) and I expect to release another stable version soon, found some bugs but also made a few improvements. I also started to port UnCodeX to a VisualStudio.Net AddIn, it hasn't been easy to do so (check my blog for some of the details). But with enough time I should be able to create a killer AddIn that not only contains most of the UnCodeX features but also make VS.Net a editor for UnrealScript (code-insight, intellisense, whatnot). Ofcourse this is all in the future.

This doesn't mean the SA (standalone) and CL (commandline) versions of UnCodeX won't be further developed, they share most of the base code so in the future there will be three versions of UnCodeX: SA, CL and VSA.


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.