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.

Open Source, it's nice.

I'm not going to stay Open Source is the way to go, or that everybody must switch to open source (altough it would be very nice).

I'm working on a fully Open Source programms (UnCodeX), and while working on it I sometimes use other open source tools (FreePascal compiler) and components (RemObjects' PascalScript). Both the examples are open source (and free software, in a way).
PascalScript didn't compile for FreePascal out of the box, but because the source was available I could apply the changes required to make it compile. I mailed my changes to the developers and they applied them to their SubVersion repository. Now everybody can enjoy PascalScript in FreePascal.
As for FreePascal, the ini file classes provided by Borland in Delphi 6 didn't meet up to some of my requirements, and because of the private vs protected shit I could override some functions. FreePascal provided similar classes, and because the license of FreePascal is compatible with the license of UnCodeX (both are LGPL) I could use the FreePascal implementation and make my adjustments. While I was making some adjustments I discovered a few bugs in their implementation (the Delphi memory leak detection script by Vincent Mahon helped me to find one of them). I reported the bugs I found, and the fixes for it, and they have been applied to the standard distribution of FreePascal.

So, for at least two projects I found some issues, was able to fix them and contributed the fixes back to the creators. They helped me, I helped them in return. Sure, there are a lot of people that don't help out. But why shouldn't you? What would be the reason not to help others out that helped you at the first place. Please that report bugs are great, people that report bugs with correct patches are just awesome. And you can't create patches when you don't have source access.

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