Foxpaw/Archived Developer Journal

Most of the personell/boarding actions stuff is completed. The AI is a little lousy, but since I haven't finished the ships the bots lack any real direction. They just roam about, blowing the living crap out of anything unfriendly that gets in their way. I noticed that having dozens of karma ragdoll carcasses littered about had an effect on the framerate, but then again, my computer isn't that grand.. it doesn't even meet the "minimum" specs for UT2003. The combat patterns of the bots are also relatively predictable, but I believe this is a result of the shoestring path network I made. I was going to add a couple of gametypes for just the "on foot" stuff and try to get that polished up and working perfectly for phase 2 of the MSU contest. I may instead forge ahead and make the ships, but I am worried that I will not have them ready in time for phase 2, and I'd like a shot at some free money.

On an unrelated note, my ability to make good textures for particle effects does not appear to exist. I may try to recruit someone to do this when the mod is more complete. For now I'll be satisfied with ugly bars for laser beams and abrupt squarish things for the "coronas" created by said lasers. Fortunately, the Kinetic Rifles look pretty decent, making fancy hollywood style plumes of debris and dust expelled from the walls/floor/etc. on impact. I'm somewhat disappointed that FPS' just use sparks for this. They've obviously never seen WWII movies. Impacts are supposed to cause a plume of dust, (in games and movies) darnit!!!

An ironic note: A while ago I abolished and removed the "actions" system, preferring to use my "inputs" system for everything, since the two can be converted to each other fairly easily and inputs take less processing to generate initially. However, "actions" is definately more tangible to the AI, now that I've come to writing the AI with more complexity. Actions also replicate marginally better because sometimes "inputs" have no effect, while "actions" always do something.

I almost forgot: I'm having difficulty deciding whether or not to use Karma for the ship physics. On the one hand, it will definately be better than whatever system I would use to replace it. That's the upside. The downside to Karma is that it drains resources if used with lots of simulation. If each ship has one engine, generator, a cockpit, loading ramp, a couple of guns, plus extraneous armor plating, etcetera, that's looking at 10 or more Karma simulated actors per ship.. more for larger ships.

Also, though UDN claims that there is a hard limit of 200 on the number of Karma simulated actors, however I have performed an experiment and found that this is NOT true.

Initially appearing to be a bad thing, a change that I made caused all havok with the rest of the code. After tracking what the problem was I revealed a dormant bug that had been released through the expansion of the code. I'm not exactly sure why that didn't cause crashes before, but it had something with no KParams attempting to block Karma objects. This has now been fixed so I can get back to finishing up redoing the input stuff or alternatively working on the vehicles.

Replication is being a nightmare. Specifically, the notion that things may arrive out of order. I figured this would be easy to work around.. I can just put anything that must arrive in a given order in a struct along with a timestamp and they can be sorted by their timestamp so they are recieved in the correct order. However, this actually will not work on a network with latency because the packets recieved out of order will be processed before the other packets arrive, thus they will already be gone by the time we want to sort. The only way around this would be to place a delay on incoming packets, but that would make the network appear slower. An example of the problem I'm having: Player A strafes left, strafes back right, then stops. Seems simple enough. But the movements arrive out of order. Player B percieves this as strafing left, stopping, and strafing right. Though Player A is standing still, the pawn continues strafing right endlessly on Player B's machine. For obvious reasons, this is a problem.

Wrote up some code for triggers inside of vehicles so you can assume control of the vehicle by walking up to the wheel/joystick/buttons/whatever kind of controls it has. Also added the keybind to leave the vehicle and one for self-destruct, though that one was mainly just to test to see if the controls were working.

A perpetual thorn in my side, two parts of the walking physics need to be redone: stairs and the surface detection. It turns out that the surface detection does not work very well on TerrainInfo surfaces. It "works," but sporadically flickers on and off, so the pawn more or less just stumbles and trips as they walk. The stairs need to be redone as I've found that they allow you to "pass through" sloped walls to an extent. Fortunately each of those things is contained to a single function each so there's no loose ends that need to be tied up once I've figured out a better way to do them.

For the remainder of the day I'm probrably just going to try my hand at making a nicer ship model.. one that isn't just a cone with a subtracted cube.

The UnrealEd Goblin has bitten me in a way I never suspected. FClamp has ceased working properly. I didn't think something so simple and so commonly used could simply cease working for me. It still works in other classes, just not MY classes. FClamp is acting the same as FMin, that is, it will return the first value if the second value is lesser than it, however, it totally disregards the third value and will gleefully exceed it. I could just write my own FClamp function, but really, this is rediculous.. I can't see how a function like FClamp could suddenly just go wrong like that!

FClamp still doesn't work. I can live without, I suppose. Now that I'm not on vacation anymore I don't have as much time to code. On the upside, however, I'm going to be going part-time soon so in theory I'd have more time. However, that will be short-lived as the reason I'm going part time is to go to University in the fall.

Wrote my own coordinate rotation operators because the native ones weren't cutting the mustard. They didn't seem to be particularly accurate, although they were still half decent. I'm in the process of cooking up a scheme for the controls of the ships and whatnot. Jets are back in so the flying warehouse is a bit more mobile. I'm going to get the controls going smoothly and then I'll add weapons back in. The modularity is really starting to shine through, which is good. When I wrote the code for walking personnell I put in all of the hooks I would need for vehicles, so the going has been swift.

Not much to say so far since I just got home from work and I'm headed for bed, but I thought I'd put this note here anyways. I just had an idea but I'm probrably going to forget it when I go to sleep. To that end I'm putting a note here. A hypnotist taught me a neat memory trick. Because I am thinking of my idea while I write this, when I read this tomorrow I will recall that idea. Let's see if it works.

It worked. While reading CorDharel's BioRocket? page I got an idea. Originally I thought that the intent was to create a rocket launcher with a biological warhead, IE it flies like a rocket and on impact splatters the bio goop. That sounded like a neat idea but after reading the page it turned out that wasn't quite what he had done, so I decided to make the "BioWarhead Launcher." It's a bit of a diversion from my main project but it only took an hour to make so it can't be too bad. It effectively extends the range of the secondary fire of the biorifle, so it might present a balance issue, but the secondary fire of the biorifle is only really useful for charging up before a confrontation or during a lull in the action anyway. With high speed rockets it may be useful as an alternative sniper weapon.

Things have been very slow going with the vehicle code for today and yesterday. Why, oh why did Epic not include a KConstraint that just sticks things together? One would think that the simplest type of contraint should be one that allows no movement and basically just attaches two KActors together. Unfortunately there is not only no constraint that does this, but no constraint that is easily modified to do this. Strangely enough, though the KCarWheelJoint constraint demonstrates that the engine supports it, there are no linear constraints, like springs or just string type constraints. These could be custom coded, but unfortunately due to the highly native nature of constraints, custom scripting constraints is limited.

Following is the code I have written for a rigid constraint. With the latest update, it appears nearly flawless. It's a bit hacky, but a clever solution if I do say so myself, which I just did.

///// Rigidly affixes two karma simulated actors together.
///// Written by Foxpaw.
///// If you use this, please give credit. If you do not, I may eat your children*.
class KRigidJoint extends KHinge placeable;

var KRigidJoint Slave;

simulated function PostBeginPlay()
{
  if ( KConstraintActor1 != None || KConstraintActor2 != None )
    Initialize( KConstraintActor1, KConstraintActor2 );
  Super.PostBeginPlay();
}

simulated function Initialize( actor A, actor B, optional bool bIsSlave )
{
  if ( Slave != None ) Slave.Destroy();

  SetPhysics(PHYS_None);
  KConstraintActor1 = A;
  KConstraintActor2 = B;
  SetPhysics(PHYS_Karma);
  
  if ( !bIsSlave )
  {
    Slave = Spawn( class'KRigidJoint', self,, Location, Rotation + Rot( 16834,0,0 ) );
    Slave.Initialize( A, B, true );
  }
}

simulated function Destroyed()
{
  if ( Slave != None ) Slave.Destroy();
  Super.Destroyed();
}

defaultproperties
{
  bKDisableCollision=true
  bKForceFrameUpdate=true

  bStatic=false
  bNoDelete=false
  Physics=PHYS_None
}

This can be set up in a map or spawned in real-time. If you spawn it in real time, you must call the initialize function and pass references to the two actors you want constrained. For the time being this does not allow for constraining things to the world, though that would not be difficult to do. (However, I would question the value of constraining a Karma actor rigidly to the world, since then it wouldn't be able to move or rotate at all anyway.) The bKForceFrameUpdate will make you life much, much easier if you plan to set up the constraint in real-time. If you will only be using it in a map you can leave that false. At some point I may make a bunch of Karma constraints and package them so we won't have a myriad of custom constraints floating around embedded in maps taking up space. If you do use this in a map or mod please credit me for it and please ask if you would like to use it in a commercial application.

Earlier today I was attempting to make a wrapper for KTire to use with my mod. Though KTire would have been better implemented as a subclass of KarmaParamsRBFull, it was instead implemented as a subclass of KActor, meaning that if you, for instance, wanted a pawn that rolled along the ground like a tire, you can't use the native tire simulation. This is curious because the Tire simulation is simply a special type of simulation and as such should belong in the KarmaParams, instead of having it's own class. Regardless, it was not coded that way. I was attempting to wrap the tire and basically use the tire wrapper to maintain compatibility while using the actual KTire for physics simulation. This did not pan out due to the fact that I cannot have an invisible, non-blocking Karma object, and if the wrapper is not designated as using PHYS_Karma, it will not recieve the configuration for Karma physics, which it needs to pass on to the tire. Instead of wrapping the tire, I've decided to make my own. I don't know how well it will work, but time will tell I suppose.

I haven't done anything with my mod for a few days, unfortunately. I started playing with the tires again and I've decided to axe them for the time being. They have an acute tendancy to get "lodged" in the ground. The native tire simulation does not have this problem, of course. I'm likely still going to have "tires," but they will not use a physically accurate tire model, and rather be powered purely by impulse.

Aside from that, I'm still working on a good method of controlling. I've got it working half decent, but it still isn't really what I wanted it to be. I'm hoping to put up screenshots once I've got a test vehicle that isn't so ugly. It's been transformed from a flying warehouse to a flying warehouse with warp nacelles glued on the side and a big cannon glued on top. While testing the wheels, it also had wheels on the side.

Hours later... brain is burning. I need to come up with a scheme to control the firing of various thrusters on the ship to attain the desired orientation and velocity. The problem being of course that said engines can be at ANY angle, ANY location relative to the center of mass of the ship, and the desired orientation can be ANY angle relative to the center of mass of the ship as well. As you might imagine, trying to compute which engines should fire to create the desired angular velocity is.. trying, to say the least. I believe I have a partial solution, or rather a partial visualization of how I need it to work. I am going to need to use some kind of a plane that represents the cutoff of where the engine will be able to produce useful output. This plane needs to pass through the center of mass of the ship and I believe that it's orientation will be in some way related to the rotation of the ship. A vector made from the desired orientation can then be measured to see which side of the plane it falls on. The only problems being:

• I don't know how to determine what side of a plane a given point lies on. I think I could make a coordinate system from the plane and use coordinate rotation to do this, but that's a pretty big "I think."
• I don't know how to determine the heading of the plane. I believe it needs to be parallel to the vector rotation of the engine, but that's just what seems right to me.

My current idea is maybe a bit easier and maybe more efficient. I think that I can find a line perpindicular to the vector rotation of the engine that will intercept the vector rotation of the engine when centered around the center of mass of the ship instead of the engine. I can then take the normal of that first (perpindicular) line and use it to find if the vector of the desired heading is within a 90 degree cone from the normal of the perpindicular line. I'm pretty sure I learned some formula to determine where two lines will intercept in Grade 9, but I don't remember it, so I'm trying to think if there might be an even easier way to find the normal. Since all I really need to trace the intercept for is to determine that I actually have the correct perpendicular normal, I may be able to forego that entirely.

Engines and turrets are going nowhere. Something simple is eluding me, but I can't put my finger on it. They both "work," but the control system that I was planning to use has to do some kind of computation, and I don't know what it is. I'm positive it's somehow involved with coordinate rotation, but I can't put my finger on it. Of course, it's kind of hard to play around with stuff when your engines can't do anything except propel you straight forward. I may write a short "hack" to handle the flight controls until I can figure out the proper functionality. I really want to have something to show for the MSU Phase 2.

A friend of mine saw the movie, Freddy vs. Jason, and now he's obsessed with the idea of me making a mod for him based around serial killers/horror icons. Once mine is fairly stable it wouldn't be a difficult extension, but still, that's not my bag, baby!

The controls are still.. yuck. I wrote the hack to get the engines to work. (not properly, I'm still figuring that out, but it works for experimentation) I can now see why astronauts have to train so much. My attempts to fly resulted in much spinning, and me being tossed around in the cockpit trying to maintain control. I think I may need seatbelts or some type of restraints. Eventually the thing was spinning so out of control I got flung into a wall really fast and jibbed. I guess it's a better way to go than getting thrown out the open hatch.

First day back at University. There was lots of foxy ladies there, but unfortunately, none of them are in senior level computer science. In other news, I've been spending the last week racking my brain trying to figure out why the engines weren't working right. Turns out that the vector I was using that was supposedly the desired rotation.. wasn't actually the desired rotation. I don't know why, since it's code is seemingly identical to that of the targeting reticle, but if I use the actual location of the targeting reticle it works. Go figure. The cameras still don't work though. I went over the vehicle code again and found that it doesn't even reference the camera, except in superclasses, which work fine. It's possible that I forgot to call a Super function in one of my functions, so I'll probrably take a look for that later.

Figured out what was up with the camera. Turns out I had the operator precedences messed up. I wrote a custom operator a while ago and it turns out that it was getting evaluated after +. This realization happened while screwing around (a good way to find bugs, in my opinion) and I noticed that the camera actually was moving, (it was hard to notice, what with being in space and all) just not in the way it was supposed to. A set of brackets later, the camera and the jet's controls seem to be working.

UPDATE: I spoke too soon. The jet's controls actually don't work properly, they worked in that configuration but don't work in all other configurations. It's quite frustrating. Stupid rocket science.

In other news, the turrets now appear to be working, which is cool. Turrets can also be "stacked" to provide greater freedom, though this can look a bit odd. This could probrably be rectified but I don't know if it should be. Right now each turret attempts to face as close as possible to the "desired" heading. In a sense this is better because it means that your guns are better aligned while the other turrets get into position. However, it does lead to some backtracking which could mean that the turret would take longer to get into it's final position. It also doesn't look as cool. As soon as I get the jets working 100% I'll be able to start doing "fun stuff" again and maybe make a better looking ship model.

While experimenting, I found something that worked extremely well. Unfortunately, however, it doesn't work the way I actually intended it to. It works better. In a way that's good, however, it's probrably not good that I don't understand how it's doing what it's doing. The part I'm referring to is the engine controls. They now seems to be firing as if they somehow magically knew what to do. Though that was kind of the idea, the notion of having "overlap" where an engine would still fire even though technically it was outside the zone that it should (to produce smoother manuevering) seems to be operating despite the fact that I didn't yet implement it. :roll: Tomorrow I'll throw in some debug statements and see where it's going wrong.. or going right, however you look at it.

I found out what was going on with the engines, and got them working pretty decent now. Decent enough to do some manuevering anyway. I want to make the manuevering a bit gentler, since right now the engines will only toggle between full throttle and no throttle. I'll likely add something proportional to the engines, but the only issue I can see there is that "thrusting" engines require the opposite proportionality as "manuevering" engines. Manuevering engines should taper off as the ship approaches it's desired heading, while the main thrusters should start to pick up at that point. Thrusters should also be less discriminating about when they fire, because the rotation they impart to the ship is less critial. To resolve this I'm going to assign a "manueverability" value to each type of engine to dictate it's behaviour.

The jets are running a bit smoother, and I changed the controls up a little bit so they are a little fancier too. I think there might be a slight bug in them but I don't know if I'll fix it or not. The view kind of "drifts" around the ship when you aren't moving the mouse pointer. It shouldn't be hard to fix, but it looks kind of cool anyway so I might not worry about it.

I've been feeling that so far I don't have much to show for my efforts because most of the stuff I've written so far is abstract. To that end I've slapped together a stationary pillbox to show off my fancy vehicle technology. Although the pillbox doesn't move, it does have the full benefit of the vehicle code that I've written, so you can do cool stuff like.. well, stand inside and shoot out the windows. It also has a gun turret on top and you can stand inside that as well. If you like you can peek out the hatch and shoot at people without leaving the turret. However, seeing as it IS a gun turret, some would question why you would want to do that. It's mostly for the "look cool factor" at this point. Although a vehicle would probrably have been way cooler, I'm not much of a modeller and a pillbox doesn't call for a particularly complex model, so that's why I decided to make one. Considering that it's texturing is just one texture plastered over the entire model I think it looks pretty half-decent.

Figured out what was causing the drifing of the view. Though cool looking, it was a severe pain in the butt trying to aim at distant targets, plus the "why" of the bug could have led to problems in the future. It resulted from an earlier "bug fix" that I've now fixed in a different way so as to avoid that problem.

I'm also going to remove the MeshController on vehicle components, but keep it for people on foot. It is a system somewhat equivalent to having various player models using the same class for all the code. However, my mod has some information attached to the models, much like the species code. To that end, I made the meshcontroller class which sets your mesh, and takes care of all that goodness. It also handles the fancy skeletal aiming, so you could freeze gameplay and trace a line (barring inaccuracy inherent in the weapon) to predict where the shot would land. Basically it's just eye candy. The ships, however, don't really need that functionality because what with their Karma parameters and the fact that a given mesh isn't likely to be reused by different components, I decided to move that functionality back to the actual component classes. I found it quite a pain to have to make two classes for each component.

I've also refined the controls somewhat and made a few assorted improvements to various classes. I also crushed a simple bug that I hadn't gotten around to fixing, and streamlined the function it was in while I was at it. I expect to put up some screenshots soon.

I meant to put this up last night, but I was having some problems with either the UnrealWiki or with my ISP, I'm not sure. At any rate, things were going super slow, so I decided to leave it until today. I took a few screenshots, but then I realized that most of them weren't particularly relevant, so I just left the one screenshot to show off one of the fancier features of my mod.

Unfortunately, although I made this pillbox/turret combo mainly for the purpose of showing the configurability feature of my mod, when I made it I found that I couldn't really make much in the way of variants from that system. That is to say, there's not much USEFUL variation you can make. Because it's stationary you need a turret if you're going to hit anything with it, and you can't really get away with taking off the guns. To that end, I'm making a new spacecraft model that should be somewhat configurable, and I'll try to come up with a way to configure the pillbox differently to show off that feature of the mod. It is kind of like the premise, after all.

Made a few miscellaneous improvements, adjustments and so forth. I moved the turret calculations out of the turret constraint and into the turret actor itself, removing some redundancy, and I also made the driving code a bit more abstract so it was more amiable to being driven by different types of actor. The aiming stuff for turrets was a bit flaky before, (though theoretically it SHOULD have been sound, it didn't work that well in-game) so I've improved the aiming to make it smoother.

Unfortunately, however, I'm wondering what I should do next. I need to make a new ship model to thoroughly test the configurability, but that's bogging me down a bit. I made the model but now I need to make a change to it, and making that change appears to cause havok in Rhino. When I made the original model (well, okay, I more or less ripped it off of homeworld, but still... ) the glass over the cockpit was rigid. I want to separate it from the cockpit itself so I can make it swing open and close so that people can get in.. Unfortunately when I split the solid object that is the cockpit, Rhino ceases to recognize it as separate solid objects and now does not agree with me that the two objects are actually closed polysurfaces. Arr..

I wasn't sure what to do next, so I thought I'd do the front end for my mod. I want to make a new front end from scratch, but I'm not sure how to do that. Some GUI stuff is referenced from the .ini file, but I don't know if it has native significance or if it's just a reference to make things easier for the coders. I understand that UWindows was built off the console - so maybe I have to override the console and replace the console reference in the .ini file. Basically, I don't want Epics GUI windows to come up at all. Getting my own GUI to appear when I want it to is easy enough, but I don't know two things about the GUI:

• How it is loaded up initially when you start the game. Does the "startup level" (the nVidia logo) load the GUI somehow or is the GUI loaded by the engine through some entry point that I don't know about?
• When you hit escape, it brings up the "quick menu." Is this simply a result of the GUI intercepting a console command bound to the escape key, or something else?

I decided to take a fresh stab at making tires. A discovery that I made along the way I thought would help me out: that is that a karma simulated object can have a static mesh for simulation and a different type of display. This allowed me to make the wrapper "tires" invisible, and use the KTire for the tire simulation. I was also going to use the KRigidJoint above to basically make the vehicle component be the wheel, and the KTire be the tire on it. This unfortunately, did not pan out, because apparently KTires are quite picky about what things are constrained to them. Instead, I decided to try my own proprietary tire physics and so far it seems to be working pretty decently. The tires start to bounce around a bit on the ground at higher speeds, but I think this can be fixed with tweaks to the suspension.

Yowza, it's been a week since I've updated this. I've been busily making my own GUI, which has been slowed because I'm not much of an artist so I don't have any fancy textures to work with. I've also come upon a realization, which I found quite bizarre. Epic's GUI code is native, so one would think it would run quite a bit faster. Yet, my custom code, made in Unrealscript, runs WAY faster and UT2003 loads up in about half of the time too. This leads me to believe that not only is Epics/DEs GUI code loading up a LOT of stuff when you first load the game, but it also seems to be swallowing a lot of cycles somewhere. From clicking the UT2003 icon to the GUI appearing, ready to go, takes less than 2 seconds (including splash screen and all that jazz) on my computer.. which doesn't even meet the minimum specs for UT2003. Loading using the standard GUI takes over 5 seconds. It's not that big of a difference, but still nice when you're loading up UT2003 once every minute or so for tweaking the location of interface bits.

I'm hereby expanding my Pawn rant to the GUI class as well. I've hit a major roadblock in trying to make my own UI. Apparently all the classes that deal with metaclasses (the map list, weapon list, character list, mutator list) are all 100% bonafide native and firmly lodged in the GUIController class. Now I'm going to have to pollute my fancy AI with a hacky workaround to access those lists by creating a dummy GUIController. To add insult to injury, UT2004 promises a new UI which will probrably be incompatible with the current system.

Having said that, I have managed to wrangle the GUI system into having a "dummy" GUI that creates my real GUI. It was quite difficult because although the GUIController is an interaction, it does not get ticked even if you have bRequiresTick set to true. Further, it is created pretty much before anything, and in most of the events called on it, a viewport hasn't even been created yet! This causes an obvious problem, as if the GUI is going to draw anything, it needs a viewport to draw it on. Fortunately there is one event that is called just after the viewport is created. Unfortunately, there's still no controller attached to that viewport, and no level, pretty much no nothing. I've worked around this by having the GUI create another interaction (which will get ticked) and have that interaction do the actual initialization in IT's tick function, allowing me to do the initialization after everything is already loaded up and ready to go. DE works around this by distracting you with a video of Gorge. The CinematicGame gametype of that gorge into (and the various replacements I've seen floating around the internet) calls back to the menu when it completes and the menu then goes into full-blown operation.

In other news, I've been having to get back into programming in C and Java lately what with school and all. It's then that you really appreciate UnrealScript. When I went to University initially, all you had to do was make a source file and compile it into an executable. Nowadays, they've got all this garbage with "solutions," "projects," and settings that don't actually exist anywhere in the source, only in menus from the IDE. I think that's all senseless. I really don't need 4 files to make a hello world program in C. Even Java won't compile cross-platform without complaint anymore, thanks to individual IDEs storing their own garbage in with your source. I wish there was a way to compile Unrealscript to standalone executables.. Mmmmm, that'd be fancy. Did I mention NetBeans hijacks portions of your code and will not let you modify them under any circumstances, instead preferring to use it's own generated code (on which the formatting is yucky!)

The GUI system is my unwitting slave. Muahahahaha! My GUI can now load maps with a selected gametype, and all the hooks are in there for me to speedily write the other junk, as soon as I decide what other junk there is to be written.

The future of bots for my mod is up in the air. There will definately be AI controlled pawns, but I'm not sure if I want them to have fancy names and specified accuracies and all that "personality" junk that UT2003 tries to inject into it's characters. I might not use any of that stuff, but I'm still deciding. On the one hand, it doesn't really hurt anything to have it there. But on the other hand, it does add complexity and clutter to the interface.

Also, I've had a crazy idea but I don't know what to do with it. I was thinking maybe I'd just do away with people being in the ships altogether, and have them be like remote controlled fighter drone thingies. On the upside, that would be easier to make ships for, because they wouldn't require an interior. On the downside, it might not be as cool. Maybe I'll just include support for both.

Further, I think I'm going to need to find some real optimizations for the ship physics, because I'm not sure the system can feasably handle that many karma actors. At first I figured it would just be the ships for the players, which is manageable, but now incorporating AI ships and whatnot, the numbers grow quickly: Suppose a simple outpost consists of 15 components. Some structural components, turrets, a few guns, some generators, and maybe a few bits for constructing other ships. Simple drone ships from it have a foreward chassis, rear chassis, engine, two stabilizers, two jets, a pair of guns, a fuel tank and a generator. That's 11 right there. (I think.) Now suppose there's 5 of those fightesr flying in formation. (55 + the 15 for the outpost.) The outpost has 3 formations garissoned and another 2 on patrol. That's approaching 300 karma simulated actors, about the limit of what my system can handle. Now suppose there's 5 starbases on a large map. Granted, it's not likely every starbase would have a garrison of that size, but still. The potential exists for their garrisons to grow that large if the players are particularly bad at the game.

Added an implementation for fins today. Though one could argue that a fin/aerofoil would be pointless in space, (and it more or less would) I added them because it makes the game so much simpler. You can rotate to face any direction with a mere 8 thrusters, but for smaller ships, I doubt players are going to want to place every tiny manuevering thruster. To that end, I've added a new type of vehicular component: astrofoils. They act kind of like a rudder in space. (there's no real physics behind that, they just do. ) There's a bit of strategy to using them, of course, the faster you go, the greater force the astrofoil can exert to rotate the ship. Conversely, the faster you go, the greater drag will be placed on the ship while you turn (so you have to sacrifice velocity to rotate yourself using the astrofoils) Also, if you are facing more or less the same direction the fins are facing, they will act as a stabilizer, keeping you headed straighter. I've finally got a half-decent ship model imported, but unfortunately the textures on it are still ugly. The black chrome that looked highly cool on the target drones is quite unappealing on the fighters, so I'll have to come up with something else.

I've discovered something incredibly interesting in my studies at University. Turns out that eternal youth is not only possible, but quite feasable, so long as you ignore the moral implications. Just thought I'd tease you all with that.

As far as the Unreal world goes, I got the astrofoils running a bit more stasble and I'm tweaking the interface some more. I'm not sure what I should do as far as the view goes. Specifically, if the ship rolls to be upside down, should the camera roll as well? It makes sense, but it can be disorienting. Plus, then your controls are all messed up, unless you also compansate for the controls, but that in itself also means that your controls will be severely messed up WHILE you are rolling.

A GPF has been biting me but with no apparent pattern. It's something to do with a "path" but I don't know if that is a path as in pathnode, or a path as in file path or perhaps the path of an object in some kind of internal organizational tree. It's going to be difficult to fix unless it starts appearing with some kind of consistency. Until then I can't really do anything about it. I also found another error that was introducing a runaway loop condition. How it was doing that I don't know, but I've put in a safeguard so it won't happen again anyway.

I found a way to speed up the Karma engine dramatically. It's internal collision engine runs EXTREMELY slow compared to a simpler collision system. This is very good considering my mod is very Karma-intensive. I sped it up by having the script determine what things are potentially colliding, and then disabling collision for everything else. This leaves the Karma collision detection with a lot less to consider, making it run much quicker. (My mod has some objects that may be in very close proximity for long periods, but they are in sync so they will never collide. The Karma engine, of course, does not know that.)

The issue with that is: it's a hack. To put it in an appropriate place would require using nested iterators (yuck!) so I put it in the vehicle code instead, because it already has pointers to it's other parts (the ones that are very close but never actually colliding) so I can just disable collision directly. The reason why that's bad is, some parts of vehicles MAY collide with the vehicle (turrets for instance) and thus the disabling should not take effect for those types of objects. However, in proper OOP form, no class should have to know about a subclass of itself. (and turrets are a subclass of the base vehicle components)

I have mixed feelings about that. It does run very fast, but it doesn't feel right. I'll have to see if I can find a reasonably fast way of doing it without requiring that exception.

On the bright side, the mod is really coming together. The ship I've been using for experimenting needs a paint job before I dare to release screenshots, () but it's got most of the finishing touches on it: roaring jet exhaust, muzzle flash on the guns, and, for added coolness, if it scrapes against something a pile of sparks comes off the point of impact. The controls seem pretty decent and the interface seems decent. Things are definately looking up, if I do say so myself. The only catch is, I don't really have much in the way of modelling skills or texturing skills or level building skills or sound making skills. I'll have to figure something out there. I'm a bit leery of trying to recruit people, however. This is my "dream project" and I've been working on it for a long time. This makes me wary of recruiting a team because:

1. I don't want to lose creative control. I definately want people to exercise their own creativity in making parts packs, etc. but I'm still somewhat concerned that others may have a different vision of what direction they want the mod to take.
2. Although it's not my primary goal, I would like to make a commercial incarnation of this mod at some point. That may be a while off, or it may not happen at all, but if it does, and some people on the team want to keep it free, there may be some legal issues around intellectual property. At the very least I'd have to remove their work, but they could likely claim that their work formed a synergy with the rest of the work and could not simply be replaced.
3. Right now I don't owe anyone a mod. If for whatever reason I get busy or otherwise can't continue work on it, or simply decide I don't want to finish it, I can simply drop it and noone can blame me for it. If I recruit a team and they begin working on it, making content, etcetera, I can't in fairness stop working on the mod. So far I've invested a lot of time and effort in making it but it's still MY time and effort and if I should choose to let it go to waste by stopping work on the mod it's entirely my choice. When other people get involved, I would have an obligation to continue working, since I have no right to make their work go to waste as well.

Right now I'm just using models ported from Homeworld, which is fine for testing, but I can't release them for obvious reasons.

Wow. Looks like learning about database systems came in handy after all. I ran into a brick wall momentarily when I found the Unreal engine can't write a single config variable thats more than about a kilobyte in size. Seeing as how the vehicles were a veritable tree of components, I found that I was going to have to build a relational database to store my data in. Mmmmm, USQL...

I looked at a few "previews" of UT2004 and something unsettling dawned on me. Maybe it's just my imagination, but the "Onslaught" gametype seems ALOT like Overload 2k3. Invasion seems very similar to Invasion for UT. I'd hate to level accusations but it almost seems like they might be drawing a bit too much inspiration from successful mods. Not a bad plan from a marketing standpoint, since it's already a proven concept, but still, it doesn't feel right to me. On the other hand I could just be imagining this or it could be coincidence. I'll have to wait and see if the same thing happens with future releases.

I decided to redo the user interface from scratch. Mine was pretty good, but there was a little bit of redundancy which is certainately less than ideal. There was also a lot of settings that I was using in ways other than they were intended. This unfortunately was a consequence of Unrealscript not supporting multiple inheritance. I wanted menus to have the properties of a "sliding page" and of a button, but unfortunately that was getting far too complicated becase the way it was implemented then required a subclassed button and a subclassed sliding page working together in unison. Not so hard to implement, but a pain when you want to make the actual GUI, since you have to manage two sets of settings instead of just one. Now I've changed it to a system that seems to work a little nicer. I reworked it all to work on relative coordinate systems for everything, which makes it alot easier to have "add and forget" pieces to the UI. With the absolute coordinate system I was using before it was still pretty decent, because any calls to move things around were passed down the line so everything got moved by the same amount. (keeping all child objects in sync) This way I prefer though because it makes some computations faster and all around reduces complexity.

I also downloaded the UnrealEngine2 Runtime to see what it was like, but I have mixed feelings on it. On the one hand, being free is neat because you can distribute your mod more. Also, a mod built on the Runtime is likely to be viewed more as a separate game rather than a mod, which might be good in some ways. The downsides to the runtime are that it's not valid for the MSU contest, though that's not that big of a deal; and that you have to rewrite everything. That's not really an issue for me, since the first thing I did when making my mod was make my own pawn classes, etcetera, so I could probrably (not sure if the meshes and whatnot would port 100%) plug my mod right into the runtime and have it work. I do think that it's still an issue though, because I expect a lot of people are going to see this engine and get a little too ambitious, which doesn't really harm me, but it's a shame because I think that alot of the projects attempted on this engine won't reach fruition.

Plus, mine boots in less than half the time of UT2003s GUI, and runs a lot faster.

Overall a pretty productive day. I finally bit the bullet and did some work on the editor. After much progress, followed by frustration, followed by vocabulary expansion, I finally got it working pretty good. First FClamp went on me, then equals went on the fritz. That's right. Equals. The assignment operator. The following piece of code ceased to function:

ViewRot.Pitch = Grandpa.CursorX * Grandpa.PrimaryComponent.XScl;
log( (Grandpa.CursorX * Grandpa.PrimaryComponent.XScl) );
log( ViewRot.Pitch );

Believe it or not, the first log gives the correct result, the second log always is 0. Go figure. I erased the whole thing and tried a different approach, which worked pretty good. I'm glad I didn't start content creation yet, since now there's another bit of information that needs to be set up for each component. (I actually foresaw this from the beginning but wasn't sure if it would be a good idea. It takes away some flexibility from the user, but after a while I realized that if I didn't install a constraint on what sorts of combinations of parts people could use, there could be a great deal of "cheating," in the sense of going against the spirit of the game. (Such as having a ship that's just a supercompressed clump of guns and such. Technically that would make you prone to area effect weapons, but you could cover a massive amount of components with a very small amount of armor, making your ship nigh indestructable.)

I've also been cooking up a plot for the single-player mode. I think it's pretty good. I've decided to stray away from video-game stereotypes and make it more like a real-world conflict, where the "good guys" and the "bad guys" depends entirely on which uniform you're wearing. Of course, everyone has their view of what's right and wrong, and thus which guys are good and bad, but obviously the bad guys have a different view of right and wrong, right? Unfortunately, I don't think that many people would be able to adjust their mindset like that so instead I'm going to have a strong "propeganda machine" to make every race, other than the one you are playing, seem downright barbaric and murderous.

Don't you just hate it when a piece of code seems to be working but actually isn't? Turns out that a piece of code in the vehicle design area which appeared to be working properly actually was not working. It worked fine when I was making sensible designs, but then for the heck of it I tried to slap together the shoddiest piece of junkyard trash I possibly could and it turned out the code actually wasn't working in all situations.

The most annoying part is it used to work 100% but I decided to change a rotator to a vector (since roll did not apply in this situation and a vector would be easier to specify). Unfortunately, however, this seems to have caused all sorts of havok and now it doesn't wokrk that well anymore. The locational attachment seems to work 100%, just the rotational is not always accurate. The issue I'm having is as follows:

I have two actors, each of which has a "socket" on it. That socket can have any location and rotation relative to the actor to which it belongs. These sockets must be lines up so that they face exactly the opposite direction - so that one would "fit into" the other, as it were. The sockets cannot be rotated relative to their actor, and only the second actor can be moved.

I used to have this working, but I replaced that code with new code which appeared to be working fine. (A couple days later I found out it wasn't) Finding the absolute rotation of the first socket is quite simple. Thus, finding the absolute location that the second socket should have is also quite simple (it's simply the inverse of the first socket's absolute rotation) Although it seems like it should be simple enough to then derive the rotation of the second actor from the relative rotation of the socket and it's absolute rotation, this doesn't seem to have been working.

When in doubt, let the user figure it out!

I was going to post up some screenshots of some cool ships I made, but they were a bit over the maximum image file size for the wiki and I didn't really feel like cropping or resizing them tonight. They turned out pretty good considering that they are just the same 7 or so components rearranged. I also think I'm going to need to add in some design aids to make it a bit easier to design the ships. It turned out to be a bit difficult to line up guns on the ship for accurate fire by eye alone, so maybe I'll put in a sort of 3D grid with some axis indicators and maybe a line showing the heading of components, so you can be sure that your guns really are pointing foreward and your engines are facing more or less straight back.

The lousy GUI keeps crashing, and I don't really know how to fix it. It's quite annoying. It crashes fairly frequently and is consistent, but it GPFs before it even reaches my code (the GPF is in the interactionmaster, but because it's repeatable it must be related in some way to my code. This is highly annoying as I doubt the end user will want to be restarting the game every couple minutes. Granted, it takes under a second from icon click till you're in the editor, but still, it's annoying.

AHA! I've said it numerous times before, but when you debug something, make sure the tool you are using to debug it is working properly first. Turns out that the stack trace provided on a GPF is not always 100% accurate, interestingly enough. Turns out there is actually at least two distinct things causing a GPF, but they were actually a consequence of my input system, not a fault in the Interaction Master as the stack trace suggested. (It said that execution never made it out of the interaction master, when in fact it had gone about 6 functions down the line when it crashed.)

I trimmed the number of crashes to about half by simply changing a return false to return true in KeyType. Apparently, KeyType does not like inputs being left unprocessed. My loading function was still crashing but I did some tests and found it's actually something in the vehicle loading that's doing it. (Commenting out the vehicle loading prevented crashes, and I also placed the vehicle loading in the postbeginplay of an actor so I can invoke it on demand, that crashed the game just the same.)

Armed with that knowledge, I was able to trace it to a bug in the native iterator code. A short workaround later, and the bug has been thoroughly stomped to death!

Eureka! I finally got the bots to not have crappy aim, and did it in an interesting fashion too. I was trying to find a formula that would determine the ideal heading of the ship to have the weapons bearing on the target. That seems simple enough until you consider that unless the ship is balanced absolutely 100% perfectly, There is going to be some disagreement between the theoretical "heading" of the ship and the direction it is actually facing and travelling. This is especially the case when a ship is damaged which can cause it's center of gravity to change.

I had a formula that calculated quite precisely where the shots should go, but I couldn't find a satisfactory way to make the bots aim and shoot at that point. After thinking about it for a while, I decided to use a very un-computery method. Instead, the bots aim using a semblance of the way human beings would aim. They use a formula to get them facing in the general direction of the enemy, then track their "crosshair" relative to the target's location "on screen." Armed with that information, they constantly adjust their heading to bring the "crosshair" ever closer to the targets "on screen" position. This seems to work surprisingly well and should also theoretically work regardless of the weapon configuration on their ship.

Been having problems with gimbal lock. The ships don't suffer, and the aiming doesn't suffer, just the camera does. That of course causes problems as the camera whips around 180 degrees frequently if you are flying more or less straight "up" or "down." I've tried a number of solutions but I've yet to find one that I'm satisfied with.

I thought quaternions were the answer but they didn't produce the effect I wanted, at least on the controls. I still want to maintain the "distorted" nature of Euler Angles, but I don't want them constrained to the Z-axis, instead being relative to the ship's Z-axis.

This I managed without too much trouble but the camera still has it's gimbal lock around the world Z-axis so it spins whenever it crosses the world axis. I may try using quaternions only for the camera while leaving the aiming and controls strictly vector math.

I also came up with an ingenious scheme. Originally, I wanted to make the AIs pretend to be players. Then, as I was writing some stability management code, I thought that I really should just make the players a special type of "AI" player. At first it seems like a wierd notion, but really, it makes a lot of sense when I think about it.

I've got the gimbal lock cleared up, temporarily at least. I'm not that fond of the way I fixed it, but it suffices for now. Previously the camera would always stay looking at the ship, but the angle it was viewed from depended on the ship's aim. I have since abandoned this system and gone for a more "chase plane" style of camera. This has a very different feel to it than the previous camera but I'm undecided whether this one is good or not. At the very least, it rendered the existing "crosshairs" useless at best. The old system had a series of parrallax crosshairs to show the path of the weapons. That system is useless in the new system, because there is virtually no camera movement relative to the ship, so the parrallax cannot be observed, and thus cannot be used to infer any information on range.

The new system uses an adaptive crosshair instead that places itself at a distance from the camera proportional to the target's distance from the ship. Thus, the range can be inferred from the size of the crosshair. This has proven to be an extremely reliable and easy way to hit the target, but unfortunately it's a bit lacking in "look cool factor." The parrallax looked very sci-fi, while this system, though a superior system from an accuracy point of view, does not have that same feel.

I also forgot that DT_Sprite does not support materials, so I'm going to have to use a static mesh "card" with the crosshair material on it. Until I do that, I'm stuck with a bland, non-fancy crosshair.

I made the AI pilots a bit smarter, but they're still not all that good. They seem to be joining up and flying in formation when they attack, but I'm pretty sure that's just a coincidence, because the formation code is not yet complete. They still manage to kill me, but it's usually my own fault. I have a bad habit of ramming into the drone fighters, because I wait too long before turning away, and consequently usually lose a wing or other fairly important piece of equipment.

I've also actually grown quite fond of the drone fighters and other ships I made. When I made the original set of parts I didn't expect there to be much variety, I was expecting that that would come in afterward when I started adding more parts. However, interestingly enough none of the ships I have designed look much like the original model I dissected to make the parts. One thing I had not foreseen was that the semi-user friendly method I made to make parts has a fatal flaw in it. Though it seems reasonable to make them by hand in the editor, this results in slight differences in the mass distribution and as such a ship that appears symmetrical is actually not necessarily balanced all that well. I believe that this is why the original drone fighters I constructed (which were predefined in code and did not follow the normal vehicle rules) fought a lot better than the new breed. I'll definately have to put some code in the part editor to search for things that seem like they should be symmetrical, line up things that are more or less coplanar, etc.

I really don't like modern advertising. One of the archetypes I especially don't like is the kind that tries to appeal to your nostalgia, like the "good old days" were so much better. That's why it pains me to say this:

Modern image editing software is so hideous it makes me want to kick something. I recently upgraded my video drivers so Aldus Photostyler stopped working. (It's been out of production and unsupported for over a decade.) This means that I'm forced to "upgrade" to something newer.

I tried Adobe Photoshop first. My first impression was that it's needlessly complicated. Operations that took two clicks in Photostyler now took a half dozen. That's of course AFTER you've gotten "the hang of it." There's all this needless nonsense in it. All I want to do is create and modify images, I can live without so many bells and whistles it shatters the windows in your house when so much as a tooltip is displayed.

After that, I tried Paint Shop Pro, which I liked even less. I kind of figured that a newer piece of software would run faster with more features and functionality. Boy was I surprised! As cute as the idea of collapsing ten tools into one highly customizable one sounds, it makes it a bit difficult when you want to go from a pen to a brush and back. Heck, why bother having a pen AND a brush, when they can just make both the same tool that you can adjust? To add more fuel to the fire, tools that I had in Photostyler apparently have no more place in modern image editing software, as they are mysteriously absent.

Apparently Jasc has a different definition of "alpha channel" than everyone else in the industry. In fact, in Paint Shop Pro, not only can you have multiple alpha channels, but they don't even do anything! They're just a place to store extra image data, just in case they port the program to an operating system that hasn't developed the concept of a file system, I guess.

Did I mention that Paint Shop Pro also personally vomits on anything you try to save in the Targa format? After a few hours I managed to produce an entertaining variety of rotated images and images with the color channels switched around so pink is purple and black is yellow. Just to keep it interesting, it usually also cut the image to ribbons and rearranged it in a lovely collage. If nothing else, at least it keeps you on your toes.

Then there's "layers." What's with that anyway? It's a 2D image, by definition the concept of adding a 2D layer to a 2D object just doesn't make sense. Why should I have to "flatten" an image every time I edit something? I suppose it might help if you wanted to change something later, but Photostyler had that feature licked a long time ago. First you press control, then you press Z. Amazing!

I personally can't believe that corporations that buy this software actually put up with stuff like that. Here's a tip: buy a Pentium 233 without an accelerated graphics card and install Aldus Photostyler. You'll at least double your productivity, and the suicide rate among graphic artists will drop dramatically.

I've been working on the formation code, but it's much trickier than I thought it would be. Flying in formation is actually surprisingly complex when your ships can't strafe, go backwards, or freely rotate. I've gotten them to fly in formation as long as the formation leader only makes gentle movements or accelerates and decelerates very slowly.

I got them to fly half-decently like that by calculating where they "should" be in the formation, and having them aim some distance ahead of that location. In theory, that eventually results in them facing the same direction as the formation leader, and more or less in the correct direction. Then, the throttle is manipulated to fit the ship into it's position in the formation. This system, however, is not particularly amiable to rapid rotation and does not allow fighters to form up to a slow-moving or stationary formation.

Having said all that, I'm not exactly clear on what the benefit to having fighters fly in formation is anyway, other than aesthetics. It does look kind of cool though.

I've been getting a bit bored with working on game mechanics like the ships, so I thought I'd work through some of the GUI elements. They still look fugly, seeing as I use a grand total of 3 textures for the whole interface, with various stretchings and such applied. (4 textures if you could the default textures in the entry level)

However, I've got some stuff made for all of the major areas. I got a start on the video settings area, enough that you can set your resolution and color depth at least. Detail level controls and audio controls will probrably come soon. I've had to struggle with this because a lot of configuration stuff is stored in playercontroller/player/playerreplicationinfo, which I don't use except as a glorified camera. Unfortunately, since there's a lot of native stuff involved with those settings it makes it a bit trickier.

I also had a nifty ambition to make more customizable characters but it's hit a bit of a snag as well. I was going to have it be something like UPaint, only a bit more structured. For instance, you could select, say, a piece of armor, and change it's coloration and markings and whatnot. The original texture of the armor would be preserved, you'd just more or less draw "on top" of it.

Unfortunately, I realized today that skeletal meshes have cylinder collision, so that way won't really work. I've considered making them ragdolls, which would give better collision so I could trace and see where you were trying to draw, but that still might not work that well because I'm not confident that it will return the correct Material from the trace function. I think that might only work on BSP. Maybe I should test it though.

At any rate, it's also an issue because it means I won't be able to use "regular" models. I would like for players to be able to just download a mesh from polycount or wherever and use it, but this system may not be very compatible with that sort of system. One would likely have to have made the model for the mod in order for it to work. Models made for my mod could theoretically still be used in UT2003 with a small mutator, but not really the other way around.

For that reason I've decided to leave that idea on the backburner for a while and just sort out some other menu stuff. I'm a bit unsure what to do next game mechanic-wise. I don't really feel like it's ready for full-blown content creation but yet I can't think of anything that still needs to be done. I just have that feeling that it's not ready yet.

Implemented a neat feature, in my opinion. The effectiveness of a weapon is now related somewhat to it's configuration. IE If an energy weapon is starved for energy because the generators are not large enough or they simply can't (for whatever reason) get the energy into the energy weapon, that weapon will not fire as fast. Weapons also have an internal energy buffer, so they can fire in bursts if fully charged. Basically it works like so:

Every time the weapon fires, it drains energy. The weapons have a very short mandatory cycle time before they fire again. However, they can only fire if they have enough energy to do so. All weapons have an internal energy buffer so they can often fire several times in quick succession without any external energy source, but the internal buffer doesn't hold a lot of energy. Once the weapon fires, and is no longer at full energy, it will start to siphon energy from things around it. The more abundant energy is in the things around it, the more quickly it will be able to replenish it's energy. The more quickly energy can be replenished, of course, the longer the internal buffer is going to last. (the reinforcement of energy helps it in it's "uphill battle" against the consumption of energy by the weapon.) Eventually, if energy is abundant enough, the energy may be able to be replenished faster than it is being consumed, so fully-automatic fire will be possible.

This adds an additional design consideration. The farther the generators are from the weapons, the longer it's going to take energy to get there, thus the weapons will not perform as well. Also, there is a tradeoff between energy and weaponry. If you have too many weapons and not enough generators, your weapons will not perform as well, whereas if you have a lot of generators and only a few weapons, those weapons will be "supercharged" with all the excess energy. Kind of a quality vs. quantity balancing act.

I implemented a shady "hack" to overcome a wierd problem I was having with SetLocation. Hopefully I can find out why it wasn't working as I expected before. The system I have now isn't really a hack, per se, just a system that I don't want to use. Before, I had an actor that was created, and then moved itself to the location where it was supposed to be. This didn't seem to work though, so I implemented a static function that finds the location it's supposed to be, and then it just gets spawned in that location.

It seems elegant in theory, but it's needless duplication, as I also have a non-static version of the function which is almost identical. I don't want to use the static function for both though because it requires some additional parameters. Also, it doesn't fell right, because it's conceptually an "instance" function. In this instance you have to supply as an argument the rotation that it is going to have when created in order for it to give back the results. I also don't feel right about it because it works in the editor, but in the game, which uses the exact same actor to spawn the ships, it doesn't work. It's crazy like that.

I've been "renovating" the code and package structure to move things to where they are a bit more appropriate. There was some stuff kicking around in the base package that was a bit more specific so I moved it out, also I redid the input handler because it was a bit ancient. Originally I had a buffered input system that was going to get sent over the network, but I've since found that that system is not particularly efficient so I converted it so inputs were not buffered and instead handled immediately.

However, that conversion was still that: a conversion of a different system. To clean it up a bit I just rewrote the whole thing. I also moved most of the functionality into the "HumanPlayer" class. (something akin to playercontroller)

Most recently I've been pondering on a way to have two GUIs running simultaneously. Basically I was thinking I could make the HUD and scoreboard just another type of menu, which would allow them to use the same skinning system as the menu. (Which is pretty flaky right now but whatever. ) However, being that it was the GUI I designed it fairly invasively so I'm not sure how well it would handle running side-by-side with another GUI.

I've also encountered a bit of a "problem." It's more a design consideration really. That is, the matter of scale. Realistically, futuristic space fighters would probrably go blindingly fast. This poses an obvious problem as your target would go from the horizon line to behind you in a fraction of a second. Obviously, that would make for rather boring ship combat. However, having the ships at a speed that's "fun" makes them either rediculously slow, or rediculously large. Given that they are scaled appropriately to persons on foot, that makes them really slow.

I'm not sure if that's really a bad thing or not, but it might be. A lot of people complained about UnrealSpeed because the cars didn't go that fast - when the speedometer was reading over 100MPH, your car was moving along at about 40 clicks. (Similarly, the scout in homeworld allegedly travelled at 1050 m/s and the probe at 4km/s, but noone complained then. Then again, the size of the fighter craft compared to the capital ships, and the size of the capital ships compared to the windows on those capital ships, suggest that the fighter craft in homeworld were about the size of an apartment building, while the larger capital ships approximated a city block. )

Anyways, I need to cook up a good premise for why the ships would be so slow, but so far I haven't really come up with a good one. I could say it was masses of ablative armor to cope with the power of futuristic weapons, but that feels like a cop-out to me.

I've been feeling some apathy towards coding lately so I'm trying to get something a bit more polished and professional looking. The game mechanics seem to be mostly done. Or so it would seem. I can't really think of anything that's missing, at any rate.

In my attempt to do that I've been playing around with the scoring system. I'm stuck between two ideas: having fixed ship values or having flexible ones that affect your scoring. IE There could be a limit set for the game, whereby no player could spawn with a ship that was deemed to be beyond a certain power level. This however poses a slight problem in that it promotes reckless agression - the faster you can destroy your ship, the sooner you'll get a shiny new one. This also poses a problem in that you can spawn, suicide your cockpit into something leaving the rest of the ship reasonably intact, then destroy the remainder of your own ship (which can't exactly fight back at this point) and collect the points for it. I could penalize players for suicides, but I don't really want to do that because often your ship will be extremely crippled and there will be effectively nothing you can do, except possibly spin around in a circle with your one remaining thruster. In those situations, suicide is expected.

The other system is geared more to a kills:death ratio, while factoring in the cost of your ship. When you spawn, you lose an amount of points equivalent to the "value" of your ship. When you destroy or damage enemy ships you get a proportion of that ships "value" back in points. Therefore, players who kill about as often as they are killed will have a score around 0, players who kill a lot and are rarely damaged will have positive scores, and players who get slaughtered like lambs will have a negative score. The problem I see with this is, (as some people feel is the case with existing gametypes) a small difference in skill may lead to a dramatic difference in points. Also, evenly matched players will end up in a virtual deadlock, both unable to accumulate enough points to end the match.

I'm thinking I may be able to combat that, however, by having ships worth their value in points, and the player themselves worth something. Therefore, the bulk of the points will come from destroying opposing PILOTS, instead of from destroying the bulk of their ship. This would also help prevent a pileup of crippled ships, as there would be a strong incentive to finish off the cockpit. Presently, the cockpit is a secondary target, as it is relatively low value and fairly heavily armoured. This leads to a strong tendancy to attack the engines, then engage the immobile, (and now helpless) target and rip their ship to smithereens. Once the bulk of the superstructure has been destroyed, however, it requires too precise of shooting to mop up all the stray bits of debris that are left over, and usually one of said bits is the cockpit. This "soluttion" however, poses a new problem - that is, a player could suicide directly before they were finished off, thus denying the would-be killer the points.

I could substitute when you suicide - when you hit the suicide button, instead of self-destructing the cockpit, it could just respawn the player and substitute in a passive AI that just waits to get killed. That way the would-be killer still collects the points. But wait - then we're back to square 1 - a player can spawn, suicide, then kill the defenseless ship they just suicided from and reap the points. Maybe I could make the AI temporarily be on the same "team" so it would count against you if you killed your own stand-in. Hmmm..

I felt that the effect for the lightning gun was a bit lack-luster so I set about trying to make a better one. Unfortunately, I hit a bit of a roadblock: apparently, emitters can't use materials, only textures. That is a shame because I could make a much fancier effect without straining the system if I could use a Combiner as the texture for the beam effect. Unfortunately, that doesn't seem like it will be an option so I'd have to come up with another alternative, or something.

That was a bit of a diversion from my mod, but I'm not really sure what I want to do with that next so it's kind of sitting on the backburner. I think I've been coding too much because it's started to creep into my conciousness at all times. For instance, last night I tossed a plastic bag into the cardboard recycling, but instead of saying "Oops, that's the wrong container," I said "Wait a minute, that's not going to compile."

I also forgot to mention, I'm at a bit of an impasse with the mod AI-wise. The AI sucks, but multiplayer is a long, long way off. (I won't implement multiplayer until the botmatch stuff is finalized.) I need a way to make the AI better, but I'm not really sure how I can go about doing that. The AI isn't bad on larger ships - only on the fighters.

Capital ship combat is not too difficult for the AI. The target is fairly large, and coupled with turreted weapons it is virtually child's play to engage an opposing capital ship. Even attacking fighters is rendered much simpler by the availibility of turrets. Gunships are also generally armed with either turrets or homing missiles, making aiming much simpler.

Fighters are a different story, however. When your guns are bolted to the frame of your fighter, suddenly the dynamics of your craft come into play in a big way. If the ship is slightly off balance, you're going to have to compensate by leaning toward one direction or the other. (the "crab" technique) This of course is massively complicated to the AI. It has to adjust it's aim to compensate for any imbalance on the ship. (which is a given once a few hits have been taken.)

The system that I have now works "decent." It works decent, in that it works. However, the AI is relatively slow at acquiring a target, compared to a human player, and is next to hopeless against a moving target. This is because it's current system works by making minute adjustments to it's aim until eventually the guns are lined up. IE, it uses a formula to determine theoretically which direction it would have to aim, then when it's aiming that direction thinks "I'm aiming where I theoretically SHOULD be, but my guns are aimed below the target, so I need to adjust upward." In theory that system is good, but it's sort of delayed gratification, and difficult to track an evasive target.

Did some various diagnostics to find out why my mod was running too slow, and I found a couple of interesting things:

1. The script uses a lot of time, about 15ms per tick per complete ship. This is of course on my POS computer so take that statistic with a grain of salt. The time taken is directly proportional to the number of ships. Though this is steep compared to the script time for most mods, one must also consider the sheer amount of math that takes place - computing engine thrust vectors and throttle levels is not as quick as one might think when you consider that the system must acommodate thrusters placed in any location and any orientation, even the most bizarre ones.
2. The Karma simulation, which I suspected as being the main culprit of the slowness, actually only takes about 7ms per ship.
3. The static mesh collision checks appear to grow exponentially with the number of ships and appears to be the main cause of the slowdown.
4. My interactions are taking about 10ms of each tick. That is insane, but appears to be an artifact of the way interactions are implemented, rather than any fault in my specific interaction code.
5. About 35ms was spent rendering, except when I riddled a fuel tank full of holes and fuel started streaming out. The particle systems involved caused the rendering time to skyrocket in excess of 100ms just for the particles. I'll have to rework those effects to be a bit more friendly.

I came up with a brute-force solution to a problem I've been having with calculating the correct rotation for things in the editor. The solution actually turned out pretty good. It's essentially a very small scale neural network system. I thought that it would be a bit slow, but it's not noticeable, and it's only used in the editor, where framerate wouldn't be as important anyway. I wouldn't use something like that in Tick, for sure, but this is a "one time" function that gets called only based on a certain user action, and they can't really perform that action frequently enough to strain the framerate.

Later that day...

I fixed another problem that had been bugging me for a long time. The editor is much improved now, in my opinion. My progress has been stifled somewhat however, with the discovery of an engine limit. It turns out that although in theory Unreal Units are all relative, this is not the case.

First I found that lightradius and soundradius are in a certain set scale. That's not that big of an issue however, as static lights are best kept small, and dynamic lights can be made quite large. (dynamic lights operate on a vastly different scale than static lights)

Apparently, the engine automatically clips things that are more than about 60,000 unreal units from the camera. That is bad, because although fighter craft have long since disappeared into the blackness of space by that point, large capital ships are clipped before they could rightly be seen.

I've covered up the clipping by using black fog (I've had it all along, I just had to adjust it to go to the clipping distance) but it's still a bit short. When a capital ship begins to fade into view, it's still pretty far away, for a fighter craft, but certainately not at the range that standoff combat between large capital ships may occur at. It also doesn't look very good against a non-black background because it always fades to black, not to whatever color the object is behind. It would be nice if there was a "fade to translucent" of some sort.

Also, I've noticed a boon to the relative slowness of the fighters: number 1, it makes the capital ships feel huger. number 2, it makes space feel bigger. The maximum size for a map in UT2003 is pretty big, but not really big enough to do a large space area justice. However, because the fighter ships are relatively slow, they can fly for quite some time before hitting the edge of the world. (The heavy fighter I designed has just enough fuel to fly from one corner of the "world" to the other, though since the carriers are closer to the edge you could concievably hit the edge if you flew directly away from the enemy carrier for a while. This can be remedied somewhat, because the map is not as big as it could be. It actually only takes up about half the maximum map size.

I'm not really sure what coding to do next: I feel like everythings "done," but it obviously isn't. I just don't know where to jump in I guess. I guess I'll work on the menu system some more.

It's been more than 10 days since I updated this and I haven't really done any coding. I think I'm experiencing a case of the "winter blahs." I think I'm going to modify the camera code a bit, and then maybe do some ground-based stuff.

I made nifty bullet-style weapons with fancy penetration and everything! I think that various "realism" mods have had something like this in them, but mine's better!

Simply enough, all bullets have a muzzle energy, drag coefficient, hard target penetration coefficient (ships, walls, etc.) and a soft target penetration coefficient. (people) The weapons then does a series of successive traces, and every time it hits something, it figures out whether its hard or soft, and how thick it is. Then the bullet does damage, slows down, transfers momentum, and travels through the target as applicable. It also makes fancy chips and junk come out of the point where it "penetrated" a hard object, and makes blood and stuff come out of the place where it "penetrates" a soft object.

Though it would be very nifty to have dynamically projected "portals" projected on things so you could see "through" the cavity left by the bullet, this would be too processor intensive. To that end, only static "hole" decals are going to be used, and then only on pieces of the world. (Constantly computing projector locations for moving and rotating ships uses too much processing power.

The penetration is mostly going to be relatively weak through hard objects, otherwise a human player could just spray aimlessly at walls and hit people a couple of rooms over. The hard target penetration is going to be sufficiently low that only relatively thin objects (like a railing, fence, maybe a lamp post) can be penetrated. Of course, different weapons will have different penetrations, the human submachinegun has relatively low penetration, while the assault rifle has reasonable penetration. Sniper rifles would be an ideal candidate for this sort of penetration, however I'm going to have the sniper rifle be like.. that rifle in Deep Space Nine. The one that teleports it's projectile to just in front of it's target, so every shot is at point blank.

Apparently my pathfinding code doesn't work anymore. It pulls either an "infinite recursion," (not actually infinite, just more than 250 calls) or a "runaway loop." This is kind of strange since it never used to do that, and it used to run quite fast even with multiple AI players running around.

I have two potential solutions: Number 1, I can have the editor preprocess the path information. This is more or less what Epic does, but I don't really want to do it that way because then you can't have the path network "learn" in real-time. (IE if someone sprays a bunch of napalm around a navpoint, it should be excluded from pathmaking by any bot that knows it's exteremely dangerous.) The second potential system is to have a heirarchial type of path network. Essentially, the path network would be split up into larger areas, and the path would be generated area - area. Then each time an area was entered, a path would be generated pathnode - pathnode to get from that area to the next area. This method would greatly reduce the path length that had to be considered at any one time, however, it requires more effort for the mapper as they will have to set up the areas as well as the individual pathnodes.

I've temporarily fixed the pathfinding system by instituting a hard limit on maximum path length. It's not the ideal solution, but for any reasonably-sized map it should be fine. Unlike Epic's pathnodes, there is no need for mine to be a set maximum distance apart, so you can cover a large outdoor area relatively easily by just placing one pathnode at every place where the bots are going to need to turn. Basically, the bots need to be able to make a beeline from one node to another, but distance doesn't matter.

Having said that I still need to come up with a solution to having multiple sets of pathnodes on a level. Obviously there are going to be some paths that persons on foot can travel, but some vehicles may not be able to make it. Aircraft and spacecraft also should use an airborne set of paths, instead of attempting to follow along the ground. (Though maybe I could just have them fly a given distance above the ground path network.)

I implemented a snazzy path caching scheme to speed up the pathfinding. It's very nifty - but it still has the same problem as before, it's not amiable to changing path values. That part kinda sucks. However, it does result in a 25-50 times reduction in time spent pathfinding, so I guess it's okay.

The existing paths, without caching, were working okay now, but I wanted to do a lot MORE pathfinding. Presently the bots pick somewhere they want to go and pathfind their merry way there. I want them to use pathfinding to pick where to go too. IE:

1. Bot scans availible pickups in the world
2. Bot traces path to each pickup to find approximate time to acquire. (No aggregation of pickups will be considered for now. EG it's worth it to travel twice as far to pickup one health vial instead of another, if there's four more health vials on the way..)
3. Bot pathfinds its way to the pickup.

This of course requires a great deal of pathfinding every time the bot wants to decide what to do. The bots are actually pretty good as it is, even though their AI is incredibly simple. The only real improvements that they "need" are to pick up weapons and such when they need one. Many times I'll loose a three-round burst into a bot and watch it heave over, with it's gun clattering to the floor, only to have it crawl and stagger back to it's feet and hightail it away from me empty handed. (Instead if picking up the gun that it dropped and is mere feet away.)

Fortunately, the whole thing is rather "leet" if I do say so myself. Which I wouldn't. Because I don't use that expression. But if I did, then I would. The mod makes gratuitous use of Karma, which is good for plenty of eye-candy. It's got the Karma injury system brainstormed over on Karma Ragdoll Injury System, and when you get ragdolled in this manner, you also drop the weapon you were carrying. (Understandable, since you've just been sent flying from an explosion or otherwise sent off your feet.) This is super neat because the attachment falls from your hand and uses Karma to tumble away on the ground. So, while you are getting tossed away by a concussive blast, your weapon goes too, but likely will not end up in exactly the same place as you. Sometimes it will land near you, and if you manage to stagger back to your feet you can just grab it and get back into the action, other times it will have gone over a railing into some lava, or landed up on a ledge where you can't reach it so you'll have to find another.

I played a mutator at one point that made you drop your weapon if you got hurt badly, but I didn't like it very much compared to this. In that one, you'd be running along and suddenly your weapon would change. (when you got hit) That I found very frustrating and all around not very fun. In my mod, the feel is much different, since you're sent flying anyway and will be lucky to even survive.

Speaking of which, I'm not really sure what I should do about the deaths. Right now, if you're using the first person camera, the camera follows your head when you're ragdolling. (Some internal adjustments are done to prevent you from seeing clipping should your head end up through a wall or something.) This is quite nifty actually. The same thing happens when you die. My first thoughts were when I implemented it, that it's very reminiscent of DOOM.

Anyways, when you are sent ragdolling, it's basically the same regardless of whether you're dead or just severely wounded. I'm not sure if this is good or bad. The only way you can really tell which it is is if you're dead, you can respawn by clicking fire, whereas if you're just severely wounded, clicking fire does nothing until you are back up. Actually, if you have a secondary weapon you can draw your secondary while you lie on the ground and can sort of half-decently shoot it. Very nifty. Anyways, the other obvious way to tell, of course, is that if you aren't dead you'll claw your way back to your feet after a short time spent wounded. I'm not sure if I should make a way to easily tell between being dead and just being wounded.

I've been making lots of eye-candy lately instead of doing "real" programming, and I'm quite proud of the results. (As you can probrably tell by the amount of rambling about this cool feature and that ) The final part I've made that I also think is super cool, is loads of blood and a more-or-less realistic "combat inspired blood distribution."

Basically, when you are wounded by different things, different stuff can happen. This can be custom scripted by modellers and skinners, or they could use one of the default types. It's kind of like the species code.. only a lot better, because that just defines gibs and blood and stuff. This allows you to script responses to different types of attack. For instance, if a Terran is shot and the bullet penetrates his body and comes out the other side (did I mention I made nifty ballistics and penetration calculations ) blood sprays from his backside. (and he generally dies) These blood droplets then fly through the air eventually landing somewhere. This means A) if you have a decent framerate you can see the blood spray from the body before it gets smeared all over a wall, and B) the blood is patterned on the wall depending on the angle of the hit and such. Shooting a person above you tends to cause blood to spray upwards and lightly coat an area, while shooting someone below you tends to create a dense splatter on the floor some distance behind them. Other damage types have different responses, for instance impact damage (taken from falling too far, hitting something too fast, getting hit by a car, etc.) leave a bloody mark where you impacted, but only if the impact was severe, or the person was already heavily wounded to begin with. If a heavily wounded terran is ragdolled and slides down a ramp or stairs, he'll leave a smeared trail of blood wherever he slides.

All in all I'm very excited about it.

Got Homeworld 2 and Unreal II for Christmas. Programming is unofficially suspended until I finish/get bored of both.

I've been making various visual improvements, but I'm still snagged on the ~60,000 UU maximum draw distance. I tried scaling everything down to allieviate this, but that caused all hell to break loose when things got too small and the loss of precision with integers started causing visual problems that were even worse. Plus, scaling everything down was going to force me to remove one of the cooler features of my mod, (the ability to walk around inside the ship while in flight or landed) which I didn't really want to do. So, for the time being things remain invisible at moderately long distances. I also tried having "stand-ins" for things that were far away that would appear at 60,000 UUs away and scale appropriately to make them look farther away, but I scrapped that when I realized that that would not look good if a player was using a stereoscopic display of any sort.

I decided to make the stand-in actors anyway. This won't look right to anyone using a stereoscopic display, but I'll have to settle for the time being. It will in fact look quite bizarre to them because the stand-ins are relatively close to the camera. (This is to prevent them being obscured by fog.)

Fortunately, the appropriate placement and drawscale was easy - it's a straight linear scaling. IE, something twice as far is half the size on-screen. This seems only logical, but some games use a non-linear scaling so you can make out details better at long distances. (Homeworld is an ideal example of this.. the difference in size between ships is much lesser when zoomed out.) Anyways, this made it very easy to make a seamless transition from stand-in the the real thing and vice versa. There's a few visual glitches that would be difficult if not near impossible to rectify - for like if a missile impacts a capital ship, the explosion will not appear on the stand-in. You could fix that by giving EVERYTHING a stand-in, which would be easy enough to do, but I don't want to have stand-ins for stuff that's REALLY far away. I tried setting everything to use them, but ended up with annoying glittering pixels of fighters that were really far away. I guess it might look okay at, say 65000x40000 resolution though.

This situation normally wouldn't be all that bad, if not for the great differences in size of different ships. That was something that kind of bugged me in Homeworld - the fighters were approaching the size of the frigates. The frigates had little windows painted on them to show that they were real big, but then a fighter would fly by with a cockpit about a dozen frigate windows long. Also the asteroids were pretty puny compared to the size of the ships. I've never visited one, but it's my understanding that asteroids are generally pretty big compared to pretty much anything man-made. Unless maybe you count the great wall of China. I hear it's pretty big. Anyways, my ships have appropriate scaling, so the fighters are relatively tiny compared to carriers. (Though the difference in scale is not as much as I would like, they also have to be scaled appropriately to persons on the ground, and the Unreal Engine does have a maximum map size, ya know. )

Also, I got rid of the environment maps on ships. They looked fancy in the editor, but looked crappy in-game. When it's dark, (as it tends to be in deep space) the environment map (which doesn't appear to be affected much by changes in light level) becomes much brighter than the diffuse texture, and ends up looking lousy. That's the grey with white polka dots you see in the screenshots I posted earlier. Now that the environment map is gone, the ships look a lot better. (Well, not the carriers, because they didn't have environment maps. Only player ships had the crappy environment maps on them.) Speaking of which, I'll post new screenshots soon. I got a new computer, and I'm doing all my programming on that one now, but that one isn't connected to the internet, so I have to lug a hard drive in between computers to transfer files and such. Or I guess I could compress them and use a floppy disk. I don't like floppy disks though.

Heuristastic! Plus, I curse integers again. In lieu of actual knowledge of how to do a coordinate rotation on a Euler angle using another Euler angle, I implemented a theoretically slow heuristic instead. It's not actually noticeably slow and the only time it ever gets called is when a ship is loaded, built, or otherwise spawned. Even so, it runs surprisingly fast considering that it's a nested loop with numerous comparisons and operations taking place. Unfortuantely, due to some wacky loss of precision with integers, it's only accurate to within one unreal rotation unit in the roll direction, but hey, that's still 99.999999999999644728632119949907% accurate, according to windows calculator, which is probrably better far tighter tolerance than the human designer is going to be able to manage anyway.

I also came up with a scheme to have all ships carry liquid ballast. I also have a feeling I wrote this already, but maybe not. Anyways, the liquid ballast can be pumped around the ship (this is handled automatically) to keep the center of mass, well.. centered. I decided I needed something like this because once your ships starts taking heavy fire and a good chunk of it is absent, the center of mass of your ship shifts way off the center and once it shifts laterally past your thrusters, you're going nowhere except in a circle. Once you start getting close to that point you can only fly by shifting the engine balance all the way to one side and using all your vector exhaust to stay straight. This makes it extremely difficult to aim and the AI can't handle it at all. (The AI compensation heuristic only kicks in once it's half-decently lined up.) Granted, by the time you've lost that much of your ship there's not much you can do, since most of your systems are probrably offline by then, but still... Anways, the problem I've been having with the ballast is twofold - number one, more ballast is needed to maintain stability than I had realised. This is bad because it roughly doubles the weight of your ship. Also, there's a slight problem in that the ballast adds a great deal of mass to the ship, which slows it down. Fast "flag carrier" ships may prefer no ballast for maximum speed, and sacrifice the stability instead. Also, placing the ballast closer to the outside of the ship makes more of an impact with less added mass. This is good. However, the outermost parts of the ship are liable to be the first ones destroyed, so keeping your ballast at the end of your wings has it's own downside there, too. However, to keep it more central, where it will be safer, requires more mass to be added, reducing the potential speed of your craft...

In other news, the AI now has slightly more of a clue of what to do. I've been developing so far under the premise of the "carrier attack" gametype, because it offers some of everything, so all of the code can be tested within the same level and gametype, which is good because it spares me from making more levels and gametypes just to test different features. Anyways, the AI now has the wit to attack the enemy carrier, as well as engaging enemy pilots en route to the friendly carrier. However, they don't yet have the brains to avoid ramming into things. Generally, that's not a problem, but the AI from one carrier has a tendancy to crash inside the hangar of it's carrier as it launches. This will be improved in the near future. And new screenshots are coming soon. Soon! They're still on the other computer.

And then some!

I wrote some stuff for collision avoidance. Unfortunately, it turned out to be rediculously slow. Initially I was using traces to detect nearby objects. You can't just take the difference in location between two objects because the location of a large ship may be a considerable distance from the surface of that ship. So I was using traces. This was slow. I figured it was because of the traces. I found out traces aren't that slow after all.

I substituted it for what seemed ingenious. I'd just use a dummy actor with cylinder collision, set it's location to the location of the ship detecting nearby objects, and go through it's touchingactors array. Seems simple and fast. It wasn't.

I was quite shocked to find that this ran at about a third of the speed of the trace method. Why, I have no plausable explanation. I did some optimization but still only got it down to taking about twice the time of the trace method. I don't like either method, however, because the trace method is too slow to use with more than about 8 bots at a time, and the dummy actor method is even slower. To remedy this, I have a couple of pontential solutions. I can reduce the extents of the traces used to detect nearby objects. A zero-extent trace would be ideal but if the extents are too small the ships think they have a clear path when they actually do not - obviously a bad thing. The extents have to be generous because there is no reasonably fast way to determine the extents of a static mesh from within unrealscript. Therefore, there's no real way to determine the extents you need to use except to have a generous preset amount that should cover the majority of ships that that particular AI will be flying.

Jaunary 9th, 2004

I made a super-fancy skybox substitute. Screenshots are coming. Honest! I don't really like the way it looks, in that it isn't black so it doesn't look like space to me. However, it is much fancier from a technological standpoint, and probrably draws faster. I was stuck for a way to draw stuff "under" the world, which could then show through by making a HOM effect deliberately. I didn't have success with that, but then it hit me: the skybox gets drawn first, then the world gets drawn on top of it. So, I could draw stuff "under" the world by simply putting a static mesh sheet in the skybox that would automatically move and rotate so it was always facing the camera. Unfortunately, it's not perfect. There's a slight visual glitch that I'm not sure how I can fix, if I can fix it at all. I didn't want to use a scriptedtexture to update the stuff on the sheet, (since obviously it has to look different when you look differnt directions) because that would sacrifice compatibility with Mac and Linux, which I didn't really want to do if I could avoid it. The glitch is caused by a Gimbal Lock issue which may be difficult to resolve. I'll make a scriptedtexture version for DirectX users, which will be free of the visual glitch. I'll post the screenshots up soon, on account of I have to go to work now, but maybe when I get back. Then people can decide for themselves.

The new screenshots also show off a fugly ship I made. More of a modification of an existing ship. My interceptors were getting chewed up by the enemy carrier and didn't really ahve anything that could cause appreciable damage to it, so rather than go to all the trouble of implementing some more weapon types, I just hopped into the vehicle editor and tacked on 5 of the biggest anti-fighter cannons and another generator to power the whole mess. This was all done without leaving the game, mind you, so hopefully the new screenshots will give more of an idea as to the vehicle design part. Also included are some shots showing some more action. Coming soon!

Quite the frustrating day. I don't know why I didn't think of it before, but I realized that if I moved the "safe distance" from ships out of the ship AI and into the actual ship components, I could make an quasi-trace in Unrealscript. It actually worked quite well, and very fast too. Because I wasn't constrained to the "upright cylinder" collision, I was able to make a custom cylinder collision, where the cylinder is essentially the length of the trace, while the radius is the extents of it. This worked surprisingly well, and also allowed me to compensate for the movement of other ships (no use going around if it's moving out of your way already. Formerly there was a "right of way" system and the other ship was assumed to be getting out of your way if you had the right of way.) as well as compensating for the movement of the ship in question. (Fast moving ships are going to need to predict collision farther in advance than slower moving ships)

Unfortunately, this improved collision prediction system showed a big failing in the avoidance system, specifically that the ships would get kind of antsy if other ships were around, but not moving in such a way that a collision was likely. (IE flying in formation) These ships weren't picked up at all by the old system, so the ships didn't get antsy about it, but that wasn't really that bad, since those ships are virtually never on an actual collision course. This is what I spent most of the day trying to fix.

First, I figured I could use something like the code the fighters use to break off an attack run on a capital ship when they get too close. (This is not related to the collision avoidance, because the range at which they break off and such is not collision-related - it's based on the ship's estimated combat capabilities, as well as those of the target. IE get in close to carriers who can't defend themselves well, stay away from gunships, stay at long range and harrass large capital ships, etc.) Anyways, that didn't pan out, because the collision avoidance operates at much closer ranges and so that sort of gentle course alteration didn't work very well. Making it just plain steeper didn't work well, as the fighters would attempt to make a tight turn and their momentum would carry them into the thing they were trying to avoid.

Secondly, I remembered some stuff from calculus about the surface of a circle and so on. I figured that, similarly, I could find the point on a sphere that was the minimum "safe" distance away from the carrier, and the portion of the circumference that represented the distance the fighter would travel in the time it was predicting ahead by. This didn't work. The fighters overshot the predicted point, then tried to do a 180 to correct, and hit the carrier.

After fiddling with that for a little while, I came up with another idea: I could set the "predicted point" some distance ahead of the fighter: basically, where the fighter is expected to be a second (or some arbitrary amount of time) from now. Then, I could have large objects "push" on the predicted points. So, if you could imagine, it's like magnets of the same polarity, the large objects "push" the predicted endpoint away from the ship. Then, the fighter aims for the adjusted predicted point. This seems to work good and produces a very smoothe avoidance.

After I got that taken care of I've been trying to streamline everything. I think the core functionality is all in now, so there shouldn't be any other major loads placed on the system from now on. (I hope.) Unfortunately, the game can get kind of slow when you get large numbers of ships flying around. I'm not sure where the time is being taken, however, so I've been taking various measurements to try to find the bottleneck. I've been hoping I'll find one horribe error I've made somewhere that's sucking up all the cycles, but more likely it's distributed and can't be easily fixed like that. It's a bit perplexing, however, as there seems to be a great deal of time unaccounted for. The timing measurements that I took don't add up to anywhere near the reported times in stat all. Earlier, it was reporting about 10ms script processing per ship I added to the world. However, my timer only found about 6 to 8 of those milliseconds.

Even 6 to 8 milliseconds per ship, however, is much higher than I want, since I want the ability to have lots of fighter craft. Unfortunately, the code all appears to be pretty much optimal, though I did manage to squeeze 0.05 ms per component out of the resource model. (energy, fuel, ammo, and such) The old model had each component on a ship do it's own resourcing and go through a modest nested loop to compute resource distribution. The new method is slightly different, but theoretically should execute at nearly the same rate: instead of each component doing it's own resourcing with a nested loop, I made only one component on the ship do the resourcing, and it uses a doubly nested loop. So, basically:

Called once per component:

• For each component...
  • Do resourcing between Self and j

became:

• For each component...
  • For each component...
    • Do resourcing between j and k.

Theoretically these should be almost exactly the same. The only reason I was changing it was because there was a single redundant line that only needed to get called once a tick, but was getting called once a component. However, that call was cached anyway, so it was akin to an assignment. But, I was desparate. I was pleasantly shocked to find that the new method resulted in a 25% decrease in execution time! (0.2ms per component to 0.15ms per component) This, coupled with other information gleaned during the earlier timings, suggests to me that there is a considerable amount of overhead involved in every Unrealscript function call. (Rudimentary tests suggest about 0.009ms per function call, which doesn't seem like much, but can add up if you use recursion or function calls in loops.)

To try to gain some speed I've been swapping some of the more time-critical code from Object Oriented Programming to Procedural Programming. So far the results have been favourable, from a performance standpoint anyway. It does sacrifice some readability. I've also been caching anything that gets called even half-ways frequently. (Center of Mass, master component, (the one that administers the resource model) nearest controller. (for ships with more than one pilot/gunner/whatever, this points to the component that houses the controls for this component. On fighters this is generally the cockpit everywhere, larger ships might have a turret controlling some pieces, while the cockpit controls others..) I also cached a dynamic array of related components, which saves me from doing the recursion to find them all as frequently. (ship parts that are a part of the ship in question)

All these improvements have brought the speed to the point that you could concievably have a moderate sized game, by UT bot count standards anyway, depending on your machine and your desired framerate, anyway. I just know that there's still something hiding in the code gobbling up cycles, because I made a test ship that was light a freighter, with just a big stack of bulkheads and no engines or weapons (they time okay, but I strongly suspect they are the culprit) and I could make like 20 of them and still have a decent framerate. So I know that it's not Karma going slow, nor is it rendering, nor is it a problem at the heart of my vehicle code. I just know it's in there somewhere... and I need to make it go faster, since I want to have each side able to have at least a couple dozen fighters.

Apparently, using SetLocation is a fairly costly operation, even on non-colliding invisible things that can't affect anything as a result of moving. Hmmm. Turns out this was causing a slowdown in weapons and engines, since I always had the "firecontroller" (the business portion of the weapon) move to the point where the projectile/beam/whatever should come out of, and this needs to be constantly updated to stay in sync with a weapon that's likely also moving. This was costing many a cycle. I fixed it (a tad bit hackily) by simply changing all references to the firecontroller's location/rotation to "effectivelocation/effectiverotation", and the two "effective" variables are set to the location/rotation where weapons fire should come from, instead of moving the actual firecontroller. This way is much faster. In theory. The framerate felt slower, even though it was actually faster. It's probrably just me. The fighters also started ramming into things again, this was because I forgot to change a reference in the AI to the firecontroller's location and rotation. (It uses this to line up it's weapons) I remembered that while I was writing the above.

I cooked up a scheme while I was at university today, to do faster coordinate rotations. I was thinking about how games use trig tables so they can just look up the result very quickly. Then I thought, why not have a coordinate rotation table? I could just have an array with 65536 cubed elements, and easily specify the rotation as an index into the array and get the result! Ingenious! Unfortunately, the lousy compiler won't let me make an array with 281474976710656 elements. It wouldn't even let me nest structs with arrays in them, and then make arrays of those structs, etc. (the compiler hung when I tried) I may (maybe) try doing it with dynamic arrays, but they might not be as fast because they probrably won't get a contiguous block of 3 or 4 megs in RAM so it'd be skipping around a lot.

The fun never stops!

I was having a slight problem with Karma things "exploding" from trying to rotate too fast. This was only really a problem with the bots, though, because a human can't really turn fast enough for it to be a problem, unless they are getting really low framerates. (Reason's being they can't move the mouse fast enough to turn that fast, and even if they could, they couldn't see where they were trying to turn to since you can't see the rotation cursor thingy once it's past about 45 degress off the rotation of the ship. (though with practice you can wing it around and have it stop pretty much where you wanted it to) The bots however, gleefully do a 180 in their desired direction on a fairly regular basis, such as when turning around for another attack run on a carrier. This was causing a big problem. I tried a couple of fancy solutions, like storing the most recent "good" rigid body state, and restoring it if imminent Karma breakdown was detected, but this didn't work too good. It just resulted in the ship being reset to the instant before Karma broke down, and since it was under virtually identical conditions, it basically entered a loop of breaking down and being restored every couple of ticks.

So, I decided to prevent the problem in the first place by smoothing the rotation of the AI. Basically, the AI's "aim" is metered out to the vehicle over a few ticks instead of giving it an instantaneous change in direction. I tried making them just have a maxmimum 90 degree offset in their "aim," but that didn't work very good, and used more cycles than this way. The new way is super simple and surprisingly effective. Basically, every tick, the vehicle's "aim" and the vehicle's AI's "aim" are averaged. Now, you might say, "every tick you average them? Why, my good man, that will cause synchronization issues on different machines on a network! Surely such methods are folly!" But they aren't. It's framerate dependant for a reason: because the Karma explosion problem is. The slower the framerate, the gentler you have to be, (keep in mind these are futuristic space fighters, doing a 180 in 0.2 seconds is "gentle") and the slower framerate results in less averages and thus a smoother motion. Besides, the AI is only simulated on the server side anyway, and the clients get the vehicle's updated aim, so they'll still be synchronized. So put that in your pipe and smoke it!

I've also been trying to eliminate the visual glitch I was having with the backdrops. Basically it's like, if you can imagine a perfect sphere with the backdrop as it's texture, and you're looking at it from the inside. Because it's a perfect sphere, you get the same effect by panning and rotating the 2D texture and can forego all triangles, which is good, because a perfect sphere would require an infinite number of triangles, which could really bog down the framerate.

However, it's trickier than one might think: It has to pan seamlessly, which means you have to have a seamless wraparound. This is easy enough If your image tiles. In theory. It's actually not so simple. Horizontally, it tiles. That's simple enough. Vertically, it doesn't. It sort of "collapses." Remember this is supposed to be the inside of a perfect sphere, and if you try to fold a piece of paper into a sphere you'll find that one axis tiles, and the other end you just kind of have to scrunch it all together to fit. The inspiration and pioneer of this technique, Homeworld, had it easy. They just gimbal locked at two poles so they never had that problem - because you can't roll when nearly level or "yaw" when pitched all the way up or down, they can just draw it un-scrunched and it still looks okay. Of course, if you were to measure things the view is actually quite distored in places using that cop-out, but you don't really notice, unless you were to bust out a ruler, then maybe you could see that when pitched all the way up or down the scale doesn't agree at different angles.. but I digress.

Point is, I want to use something like the system they use, only better, because I can't have gimbal lock, for obvious reasons. It's very important that the background pan and rotate realistically, because my experience while developing the backdrop system so far has shown me that the background is very important to your sense of direction. When the backdrop was just fixed and didn't pan or anything, I couldn't tell where I was going. When it was going backwards, I could never accurately judge how far to turn, and so on. Point is, it has to be perfect! I want to avoid using a pseudo-skybox approach though, because I want to keep it entirely 2D, because it'll look better.

I implemented a nifty system to help the bots make more intelligent aiming decisions. I had the idea a while ago but I was surprised at how elegant it turned out. It won't get called alot, it'll get cached, and it's not processing intensive anyway, so I can afford to make it elegant. Basically, every ship is issued a "classification," which, interestingly enough, is a reference to a class. These classes form a heirarchy which is very handy. I was able to encapsulate virtually everything in the base classification class as well.

The solution turned out really good. Each "class" of vehicle/ship has two things: a rate function, and a list of subclasses in the defaultproperties. Interestingly enough, "subclasses" don't actually have to be a subclass, allowing for a non-linear descent down the "class tree."

Basically, a function is called on the base class, which iterates through it's list of subclasses, and calls the Rate function of each. Rate returns a float, and whichever subclass returned the highest value get's a function called in it, which does the same thing as this just did. (only, of course, iterating though that subclasses subclass list instead of the base classes list.)

Rate is a simple static function that gets overridden in each class. It takes a struct as input, (for extensibility) which contains a considerable amount of statistical information about the ship in question. (Firepower, armor, manueverability, mass, resource processing capabilities, sensor range, resource storage abilities, etc.) The rate function just has to return some floating point value to indicate how closely the vehicle matches this particular subclass. For instance, let's say the ship in question was a superiority fighter. The process might go something like this:

The Base Class calls Rate in C_StrikeCraft, C_Capital, and C_Station. The vehicle has a relatively low mass, so C_StrikeCraft returns a high value. C_Station returns high if the vehicle passed to it is nearly immobile, which is not the case, so it returns a low value. C_Capital is looking for high mass, so returns a low value.

C_StrikeCraft now iterates through it's list: C_Fighter, C_Gunship, C_Transport. The fighter has no turrets, and a relatively high manueverability compared to it's weapons, so C_Gunship returns a low value. The fighter doesn't have much storage, but it has a fair bit of fuel and energy considering it's size, so C_Transport returns a moderate value. The fighter is very agile, however, so C_Fighter returns a high value.

C_Fighter now iterates through it's list: C_SuperiorityFighter, C_Bomber, C_Interceptor. C_Interceptor likes manueverable craft with lots of weapons, but weapons take priority. Since the fighter in question is more manueverable than it is heavily armed, C_Interceptor returns a moderately high value. C_Bomber heavily favors weapons over manueverability. Because it wants LOTS of firepower, and the fighter only has a moderate amount, it returns a relatively low value. The high manueverability helps the rating from C_Bomber, but not by alot. C_SuperiorityFighter focuses mainly on manueverability. The more manueverable/faster the vehicle in question is, the higher the rating from C_SuperiorityFighter. C_SuperiorityFighter also gives points for weapons, but not as much as C_Interceptor. C_SuperiorityFighter returns a high value because the vehicle is question has lots of manueverability.

At this point, C_SuperiorityFighter would go through it's subclasses, if it had any, which it doesn't. So instead it just returns itself back up the chain to give the eventual result.

That was a bit of an example, but I was having difficulty putting it into words. One advantage of this system is it's easily extendable, and it's heirarchial nature allows for "IsA"-like calls. For instance, if a hostile ship was approaching a transport of some kind, it might do something like:

if ( IsVehicleClass( Incoming, class'C_Fighter' ) )
{
  // We can't outrun it. Is it harmless?
  if ( !IsVehicleClass( Incoming, class'C_Transport' ) )
  {
    // We won't be able to outrun a fighter or a gunship. Best
    // to head for the nearest friendly units and call for
    // backup.
  }
} else ( IsVehicleClass( Incoming, class'C_Capital' ) )
{
  // We can outrun it. Fly directly away from Incoming.
}

In this way it doesn't need to check through the myriad of types, and doesn't need to bother with whether an incoming fighter is a superiority fighter, a bomber, or an interceptor. Similarly, if it's a capital ship, it's a fairly safe bet we can get away. There's no sense bothing which what class of capital ship it is, or whether it's armed with anti-fighter or anti-capital ship weaponry, etcetera.

Another big advantage is it allows you to approximate the role of any ship. Since a player can design a ship in any style and with any combination of armament, etc. they please, the AI needs some way to know what's dangerous to it, what it's dangerous to, etcetera. This way, the AI can transparently pick targets intelligently. Superiority fighters will engage enemy fighters, interceptors will engage bombers, and bombers will engage capital ships, without the user having to specify to the ship or AI what sort of ship it's piloting and what it should do with it.

I had this idea sitting around for a while, but I was getting kind of annoyed when the interceptors I built almost always went straight for the enemy carrier, ignoring enemy bombers launching from the enemy carrier.

It took a while to get the idea I implemented yesterday nicely balanced. The specific problem being, having particularly heavily armed interceptors being mistaken for bombers, due to their sheer amount of firepower. However, these interceptors also had very powerful engines and thus should act like interceptors. I eventually realized that I could figure out what's a bomber and what's just an all-around powerful ship by finding ships with a large amount of firepower relative to their manueverability. This works well, because if a bomber is so manueverable it can fly like an interceptor, there's no reason why it shouldn't do so - and if an interceptor is so clumsy it looks like a bomber, it makes sense to keep away from overly acrobatic movements.

I also uncovered an interesting balance issue. If a ship is armed with missile/bomb/torpedo/rocket launchers, there is a variety of warheads that can go on any given bomb or missile or rocket or torpedo. For instance, you could arm your macro missiles with fusion warheads to get a blast effect, or you could cap your dumbfire bombs with plasma warheads to get extra punch against capital ships. The balance issue that I've noticed is that the plasma warheads are a lot more useful than the fusion warheads. Fusion warheads have a blast effect, in theory making them useful against fighter craft. However, it can sometimes take several hits to destroy a fighter with fusion warheads. I had expected that plasma warheads would not be very useful against fighters since they have no blast effect and therefore would probrably only knock off a fin or a gun. However, I found while playing around that macro missiles armed with plasma warheads are actually very effective if you target the enemy fighters cockpit or midsection.

So, I have a couple of options: I can make the fusion warheads have a bigger blast, to make them more effective. Alternatively, I can pump up the damage on fusion warheads to bring them closer to the damage plasma warheads do. I don't really like either of these options. The reason is really in the scaling. Dumbfire bombs are a very large warhead. They make a big blast with fusion warheads, probrably enough to take out several adjacent fighters. (though hitting a fighter with an unguided, unpropelled bomb is next to impossible) The macro missile packs about a tenth the warhead size. It's blast is thus very small. If I bring up the blast size of the fusion warheads, then the dumbfire bombs will have an absolutely huge blast radius with fusion warheads, which will cause a considerable slowdown with the particle effect used for the explosion. If I bring up the damage of the fusion warheads, I risk unbalancing them with the other weapons.

Maybe what I need to do is "dumb down" the macro missiles themselves. Right now they track very intelligently, even going so far as to turn around and make another "attack run" if the target evades them on the first pass. If I make them explode when they are detected to overshoot the target, this might make the fusion warheads more attractive.

Technically it's the 19th..

I set up the missiles to explode once they detected that they've overshot. They have some leeway, however, basically, once they are close enough to the target that they predict an impact within a second, the warheads are "armed" and will go off either on impact or if the missiles are both headed away from the target and are more than a seconds travel away - clearly overshot. This change worked quite well. The fusion warheads are now definately better versus fighters, (plus the wanton explosions and such is much cooler than the "precision strike" of the plasma warheads) and the plasma warheads are better versus capital ships.

I realized what was causing the funny scrolling with the 2D backdrop. Unfortunately, I'm still scratching my head trying to figure out how to fix it. I had hacked it into a TexOscillator, but I just realized today that the movement of a TexOscillator is sinusodial, not linear. I need to find a way to compensate for that by adjusting the phase appropriately to counter the sinusodial effect.

My backdrop system got a new leash on life when I finally figured out how to get it to pan 100%. Then I realized something else. I need to somehow "warp" the texture as it gets farther away from the center. As it stands right now it works really good at tighter FOVs, but when the FOV gets too large it starts to look funny. I wasn't sure what it was, until I tried going back to using a skybox for a while, and then it hit me. Figuratively speaking. The texture needs to "stretch out" as it approaches the edge of the screen. Unfortunately, I'm not sure how I can go about doing that from within Unrealscript. That may spell the end of the backdrop system in it's current form. However, I may be able to cook something up yet.

Also, I think I need to make another type of AI, essentially a "commander" AI to decide what ships the AI pilots should build. For the time being it's random, but it would be nice if there was an AI "commander" that would decide what sorts of ships were needed and dispatch appropriately.

Also, I think I need a way to "rearm" after launching from your carrier. It doesn't take long for the bombers to run out of bombs, and missile launchers eventually run out of missiles. I may change the way the carriers work a bit to facilitate this. For the time being, you spawn inside the carrier and it launches you out like a cannon. (like the "catapults" on modern aircraft carriers) For now, if you try to fly back into the carrier, it just launches you back out. I may change this and make it possible to fly back in and land back on the carrier, at which point it would resupply you, refill your fuel and energy, and possibly repair damage. That way seems fraught with complications, like someone spawning and getting launched out of the carrier as you are trying to fly back in. Not only will both ships pulverize each other, but they'll leave a debris field inside the carrier, so when both players respawn they'll probrably get blown up from all the debris, and make a big loop. Which would be bad.

So, what I'm probrably going to have to do, is have a volume around the carrier's hangar, and if there's any friendly ships in the volume, no ships will launch. Ideally I would have a big hangar with little stalls you could land in and stuff, but I think that if I scale up the capital ships to the level that that would require, I'll probrably run out of map space. Plus, that would call for some sort of forcefield airlock thingy, which I don't really want to have at this point, but maybe I'll change my mind.

Also, I found out what was up with the scale in Homeworld. While texturing up some of the components I looked at some other Homeworld ships and realized something. A "fighter" in homeworld is about the size of a small capital ship by most science fiction standards. I couldn't even find the cockpit on the Kushan bomber at first, then I noticed a little square about a hundredth the size of the ship, which is apparently the cockpit. The cockpit I've been using for testing was pulled off a Taiidan Interceptor, and when I went to texture it I found that apparently the part that looks kind of like a big glass hatch when untextured, is actually like a whole control room. I tried to texture it a bit different to make it not look so wierd as one big window, but it ended up looking like some kind of robot drone or insect cockpit. However, the retexturing made some things look a lot better. Also, the way the Unreal Engine likes to anti-alias stuff makes the textures from Homeworld look kind of crappy. A lot of those textures use squarish shapes that look fine when stretched, but when they get antialiased they start looking like what they are - a 16-pixel wide texture that's been blown up to a humongous scale.

Wow. Talk about a blast from the past. I found a hard drive while cleaning up a while ago, a Quantum Fireball 270 MB drive to be precise. The date on it says July 94, and it has MS-DOS 6 with Windows 3.1 installed. Computers have sure come a long way in the past ten years...

Having said that, I haven't been doing much coding the last couple of days. Instead, I've been playing games. Specifically, space shooters. The aim being, I don't want to lose sight of what I'm aiming for. Even more specifically, I don't want to pack in a bunch of realism and end up with a game like Orbiter. (Not that I've played Orbiter, I'm making a guess that it wouldn't be very entertaining.) Unfortunately, I was a bit stumped when I realized that there wasn't any recent space shooters that I knew of. The exception being Freelancer of course, but that one basically feels like a stat-building hack-n-slash - basically, Diablo II in space. Granted, Diablo II IS pretty popular, so maybe that's not so bad, but it's not really what I'm aiming for.

Strangely, reviews and screenshots of Freelancer look crappier than I remember watching over the shoulder of people in the senior computer lab at university. In a way this is good, and in a way it's bad. It's good because it means that the level of graphics that I thought that Freelancer had was just my imagination, so now I don't need to compare my game to a seemingly unattainable vision. It's bad though, because I want my game to look like what I thought Freelancer looked like.

So I found a copy of Freespace 2, which is kinda old, but I don't know what's newer as far as popular space shooters go. Even so, I don't think that gameplay has really advanced that much, though the graphics are a bit dated. Anyways, I started playing, with the intent of getting some inspiration of how to make my mod better. The first thing I noticed was, "this game has way too many bloody controls." Plus it didn't support my mouse wheel. So, I busted out the old Thrustmaster Tacticalboard and mapped some keys. Then I started thinking, "maybe I need some more keys."

Right now, there is hardly any for my mod. The control system is a bit more configurable than most games to support the possibility of any ship design. Basically, you've got "actions," which can be defined and mapped onto stuff that happens. (IE, you could create an action "Start Firing" and map it onto all of your weapons so they all fire when the "Start Firing" action is performed. Then, you map keys to your actions. This way, you can have an arbitrary number of actions and assign them however you like. For instance, you might set a weapon to use "Fire Guns" while another weapon uses "Fire Missiles." Then, the keys can be mapped differently. And, if you later want to change your key configuration, you only have to reassign keys to your actions, instead of having to reconfigure all of your ships. So far, on all the ships I've made, I have all the weapons on one key, while theres a few keys to fire engines: right click to go to full throttle, release right click to go to 0 throttle, mousewheel up or down to modify throttle. The up key also applies full throttle, and the down key applies full reverse throttle. (IE retros)

For now, this system has worked well - the ships have only really had one weapon system. However, I can see where having different "banks" of weapons can add to the fun. That brings me to my next point. I think I need missile locks. Right now, the missiles are smart enough that they will automatically home on your selected target. It was kind of fun getting a missile lock for the "aspect" missiles in Freespace 2. So I think I need something like that.

Also, a big one, I need either weaker weapons, shields of some kind, or tougher ships. I don't want to remove the locational damage stuff that I have now, but I do want to make the fighters a little tougher initially. Reason being, the ships start to fall apart once they lose pretty much anything. They don't really have much that they can "afford" to lose. I kind of liked having shields and a central "hull integrity" - this way you can take some damage and "be in trouble" without being totally helpless, whereas on my mod 50% hull integrity basically amounts to 50% of your equipment missing - and you can't do much without an engine. It kind of adds a "desparation" or "last ditch effort" kind of an aspect, which I liked. Unfortunately, shields don't fit in very well with the atmosphere I wanted to have, but maybe I'll just up the hitpoints of some of the smaller components a bit, and see how it goes. That's the only place there's really a problem: your cockpit and major structural pieces can take something of a beating, but smaller (yet essential) things like fins will get torn off the minute they take any serious fire.

Also, the ships in Freespace 2 carry an unrealistic amount of ordnance, but it doesn't really detract from the gameplay. In fact, I think it's good. It retains the feel of limited ammo without forcing you to be a miser.

Anyways, that's all for now, except I looked at the tracefire weapon code and updated it a bit. Interestingly, it almost feels harder to hit people with tracefire weapons than it did with projectile weapons, but maybe that's just a consequence of decreased volume of fire. I'm curious if maybe it's actually the slight "thickness" of projectiles that makes them easier to hit with, but I'm not sure if that's the case or if it's something else. Maybe I'm just so used to leading the target that I'm having trouble with the tracefire weapons. Or something.

Yikes! The issue with the engine not drawing things more than about 60,000 units away has come back at me. I had it fixed more or less by having "stand-ins" to make an accurate semblance of what was going on at great distance. This sytem actually worked surprisingly well. However, I've encountered a new problem: beam weapons and such ALSO get clipped at 60,000 units. Which means that there's a gap between where the beam appears to originate, and the place where the beam first begins to be drawn.

In theory, I could probrably have the visual effects for the beams find the appropriate place on the stand-in and appear to come from there - but I'm not sure how well that would work. The simple reason being that stuff that's really far away is drawn in the skybox. That makes it a bit more complicated to have the two appear to "line up."

Also, the lighting is imperfect on the stand-in system, but there's not much I can do about that. It would be nice if I could disable the automatic clipping at 60,000(ish) UUs, however.

Unfortunately, since that's not an option, I'll have to figure something else out. I'm not yet sure what exactly to do about it. Eventually I may break down and use some scheme to determine the on-screen location of the start of the beam (theoretically) and then manipulate the beam to make it appear to come from that location. That's a less-than-ideal solution, since it would require a fair bit of processing overhead, however.

Most of today's coding efforts was just doing research on assorted things. I had some interesting findings. In my search for more speed for my mod, I considered if static arrays might be faster than dynamic arrays. So, I set up a bunch of loops to test assignment, creation and deletion of elements in a dynamic array, etc. I had some interesting findings:

• The times fluctuated considerably on different runs, even with 2048 iterations. (max size for a static array)
• There were, however, clear trends. Interestingly enough, dynamic arrays were fairly consistently faster. This is contrary to what I had anticipated.
• The values assigned to the arrays does not seem to matter. This suggests there was no caching magic going on as performance was comparable with random numbers as well as with fixed ones. (Except for slight overhead for the FRand() call, but this was the same difference on both static and dynamic arrays)
• Dynamic arrays can add elements faster in a batch than alone. IE, if you have to add 10 elements, increasing the length by 10 is better than increasing the length by one 10 times. However, this difference was relatively small.
• Strangely enough, assignment and creation combined (IE, assigning a value to a nonexistant index) was faster than either! In fact, assigning 2048 individual elements (to non-existant elements) was faster than just setting the arrays length to 2048! This implies to me that perhaps initialization is a relatively expensive operation, though this seems strange.
• The differences in times were obvious, but generally almost insignificant. The vast, vast majority of the time elapsed during the tests was overhead from the loops. Unfortunately, overhead from the loops was difficult to measure because it fluctuated wildly. However, the for loop appeared to consume about 80% of the elapsed time. (measured by executing an empty for loop 2048 times)

While poking around in my UT folder I found some parts of the humble beginnings of my mod. I was hoping that there was enough preserved to post some "1st generation" screenshots, but it was not to be. Going over the code I'm amazed not only at how far it's come, but also at how developed it was. The script for it was about a third of what I have now. However, I didn't really have any AI, except for crude turret AI. It was still pretty neat though. One interesting thing (which is not in the current version) was the ability to super-customize all your weapons and such, like in Freedom Force, if any of you have played it.

Unfortunately I've been really busy with school lately so I haven't been doing much modding. I've considering changing the scale a bit though. Not changing the scale as in literally changing the drawscales of stuff, but changing the focus from fighters to small capital ships. I'm not sure about that though. On the one hand, even with a large number of players the number of fighter present may seem unrealistically small. One would think in a real fleet engagement there would be dozens upon dozens of fighter craft. This isn't really possible of course, due to a lack of players and a lack of processing power for that many AIs. If each player had a frigate-sized capital ship, that would make for a more realistic fleet engagement. However, I don't know if that would be a good move: space combat wouldn't really be the same without fighters. Also, the style of combat between capital ships would likely be very different than that of fighters. It wouldn't necessarily be a "slugfest" as Star Trek games generally don't have much in the way of fighter combat but still turn out okay. Still, it's not really what I was aiming for, so I'll just have to think about it some more and see what I come up with.

Man, the word February looks really wierd when you write it. Anyways, I noticed that my previous "fix" for the beams, of forcing them to less than 60,000 UUs length, did nothing to fix the problem. It seemed logical at first, but then I realized, no matter how show the beam is, if you are more than 60,000 units from it's start but not from it's end, or vice versa, the beam is going to appear broken.

So, I've started considering shrinking everything. If I just scale everything down so the entire space area is only 60,000 units across, that would more or less fix the problem for good. However, there's an inherent problem with that: if I want to scale down everything in space, I'm gonna have to scale down the pawns so they can still fit inside the ships and stations and such. I'm not sure how well that will work, however, since I'll probrably have to scale the world down a lot, and the people will probrably end up being about 2 UUs tall. The problem with that being, I don't know how well it will work with the physics and such. Presently there's an "uber-leet" physics system on the pawns that allows them to walk on any surface within a certain number of degrees perpendicular to the direction of gravity. IE, your feet have to be facing the direction gravity would be pulling you. This is nifty because it allows you to walk on the decks of your ship, regardless of the direction your ship is actually facing. I'm not sure how well that sort of system would bode with super-small pawns. I guess I'll have to bite the bullet and try it out...

No dice on making stuff smaller. That played havoc with the Karma, greatly amplifying the constraint bug I've been having. It appears that that bug must be caused by a loss of precision in floating point somewhere, possibly resulting in division by zero or some other such hazard. Of course, such speculation doesn't help much since I can't modify the source anyway.

Speaking of which, I've been inserting tons of hacks into my code to try to get stuff to appear properly. Specifically, the beam effects. I hate having to work around the engine limit so much - it's turning into a real pain. Unfortunately, I can't even cleanly encapsulate them in many cases because of specialized behaviour of some pieces. For instance, the firecontroller of a weapon (something like the WeaponFire actors in UT2003) never actually moves, so effects can't be spawned out of it, but instead need to get spawned out of wherever the weapon is. However, the code in the superclass for generating special effects goes by the location. Now, this was easy enough to work around, by simply having the function overridden, convert the coordinates appropriately, and feed them into the superclasses function. Unfortunately, I can't do that with trying to work around the distance because now I require not only locational adjustments, but also scaling adjustment. Hence, I now have two nearly duplicate functions, which is not very good programming style. Of course, the perfect place to encapsulate this stuff would be in the renderer, but I can't access it unfortunately. Even better would be if Epic hadn't instituted an arbitrary limit on the distance. The bit of cruel irony is that there's a cull distance variable that does the exact same thing, but it doesn't get used in any of the stock code. (instead preferring the hard-coded limit ) It would have been a piece of cake to set the default culldistance of actor to 60000 or so, and then just use that culling functionality.

I'm still dearly hoping that Mosquito is right and that the 60,000 UU limit on the renderer has been removed. That's one of two nagging problems that I haven't been able to fix - until now, anyway.

Today I think I've sealed the fate of the second problem, the "karma constraint explosion" problem. Originally I had planned to basically have the server fake replication to itself, so if the main version failed, it could revert to the "replicated" version (which doesn't use karma, but instead uses a nifty movement extrapolation system to predict where it should be on the server given ping and such.)

Anyways, that solution wasn't working that good. Reason being, the ship get's "tippy" shortly before "exploding." The tippiness doesn't set off the "explosion" detection, and so the tippiness is recorded as normal behaviour and sent off to clients. This is a problem. However, today I found something that appears to have sharply reduced the incidence of constraint explosion.

You can have fins/wings on your ship which help you to manuever. It's not all that realistic, since there's no atmosphere and all, but fins and wings look cool and if they didn't do anything, I doubt many people would use them. Anyways, they have a semi-sophisticated system to detect how they should apply "rudder" in order to rotate the ship to the desired facing. The greater your velocity, the stronger the fins become. Also, if you are travelling fast in a straight-ish line, they stabilize the craft, making it easier to line up shots.

Turns out that something in their code is putting an insane stress on the mathematics inside the Karma engine. I don't know whether it's the stabilization or the rotation part, but commenting out all the fin code appeared to have more-or-less stopped the constraint explosion dead in it's tracks.

Interestingly, I sort of thought the fins might be responsible all along - like a voice in my head saying "maybe it's the fins. They get more powerful at speed, and so does the constraint problem. Maybe there's a connection." Unfortunately, for a long time I ignored that voice, dismissing the notion as absurd.

So anyways, now I'm going to dissect the fin code and see if I can find out what's causing all the mayhem. I'm also going to continue hoping that the 60,000 UU limit will be fixed in UT2004, or some future version of the engine at any rate. That would save me a lot of script execution time and improve visuals at the same time.

New screenshots ARE coming, they're "simmering" on my screensaver while I decide which ones are the best. I'm also hoping to have something "new" to show off before I post new screenshots - most of the improvements since the last batch of screenshots have just been coding improvements that aren't really reflected in the visuals.

I played the UT2004 demo, and had mixed feelings about it. Some things were neat: specifically I liked some of the emitter effects and such. I also liked the matinee movie at the beginning of the assault map.

I don't like the new sniper rifle. It should have been named, the "slower than death" rifle. I haven't tried any of the space vehicles, but I didn't really like the ground-based vehicle combat that much. Reasons being, they're way too flimsy, the tank feels floaty, and the vehicle combat just feels like a run-of-the-mill tank combat game. Though in theory this is what it should be, since they are tanks and such, it doesn't really have a FPS feel to it. Also, the terrain is appparently just for looks, since basically all the vehicles can go over pretty much any obstacle and can shoot far enough and fast enough that range is almost a non-issue.

They also changed a lot of the weapon meshes, though I can't figure out why. Some of the new ones I think look markedly uglier than their predecessors. (Shock rifle and assault rifle in particular)

Supposedly there was going to be a new UI in UT2004, but I had sort of expected that meant a different type of UI, not the same UI with different graphics and buttons in different places. The AI has also supposedly been improved, but when I played the Assault level the AI just sat in minigun turrets (which are lousy) while me and my team walked right through and hit all of the objectives. At one point I had to hit F1 just to make sure I hadn't accidentally forgot to put bots on the blue team! When they were attacking I saw them, and they zig-zag relentlessly - good from an avoiding incoming fire perspective, but kind of annoying. Reminds me of counterstrike "bunny hopping."

Unfortunately, the whole thing seems more sports-game like than UT2003, which was a complaint many people seem to have had about UT2003 itself. Onslaught is kind of fun, but it's basically just the game Battlezone/Battlezone II with a bunch of the cool stuff removed.

Anyways, having said all that - I got the fins taken apart so the "constraint explosion" seems to be more or less fixed. The only problem is, without the manuevring assistance of the fins, the ships are a bit "wobbly." That is, they overshoot their desired rotation when turning, and then they have to turn back, and so on, which makes it a bit tricky to line up your shots. I'm looking for a solution to this problem, but unfortunately the ideal solution is probrably not a practical one.

I made a nifty "spectator cam" for spectators, which should help in making a movie of a game-in-progress. It's a bit jittery, but I'll put in some smoothing later. What's important is I noticed a couple quirky things. The ships wobble a bit - this is due to the new physics for the jets, which are necessary. I'm still trying to iron out the wobbling though, especially since it makes the bots have terrible aim.

Also, the fighters are now getting into "turning contests" and trying to circle strafe each other, which is not the behaviour I was hoping for. The reason for this appears to be that two fighters attacking each other pass at moderate distance, sufficiently far apart that they both believe that they are far enough away to continue their attack run without getting into this sort of turning contest. I can increase the "break off distance" for the attack runs, but I'd rather cook up a scheme to detect this circle strafing behaviour. I've been working at that, but so far it doesn't seem to work. (sometimes it does, but other times it doesn't...)

Hmm. I could have sworn I wrote an update yesterday. Oh well. I got the ships to cease wobbling. However, this creates kind of a funny feeling, but I guess it's not too bad. Basically, the stabilizers come on strong when you overshoot your intended rotation, with a gentle activation while returning to the desired rotation. This creates a fairly smoothe rotation, but the smoothe rotation gets a bit sharper when you reach the desired rotation. However, this satisfies both conditions required for good controls: it's smoothe when making large turns, without being sluggish when making precise aiming.

I also noticed a bit of a bug that was preventing the "bot cheating" auto-aiming from working. The new spectator camera allows me to track the action much more efficiently and I noticed that the biggest problem with the bots is that they face off at rather long ranges. This is only natural in space, of course, but it makes projectile weapons, with the exception of rediculously fast projectiles, very difficult to hit with. The lead is easy to calculate for any speed of projectile, but the target will often change heading, even if only slightly, during the flight of the projectile, and this makes it very difficult for the fighters to hit each other, except with very fast projectiles.

I'm not sure what to do about this. The problem isn't so much the speed of the projectiles as it is the distance between fighters when they dogfight. (the time the projectile spends in transit, specifically, is the problem.) I have a couple of potential solutions:

Make the projectiles faster

I've tried this but I don't really like it. In order to be effective, the projectiles have to go so fast that you can barely see them in flight. This is not what I want.

Make the ships slower, and reduce projectile range to force ships to fight at closer ranges

I don't really like this one because it involves making the fighters slower. This actually seems to be the norm in space games. For instance, the fastest fighters in Homeworld only travelled at about 150 km/h. (My own guesstimate based on realistic ship size and space travelled relative to ship length) To be completely accurate, they actually went a lot faster, but were just rediculously huge and styled funny. (a Taiidan Interceptor appears to be roughly the size of a Defiant-class warship from Star Trek.) Anyways, if we imagine the Homeworld fighters were actually like single-seater fighters, they'd only be going about 150 km/h - kind of slow for a space craft. Freespace 2 also has pretty slow ships. The fastest ones only go about 100 metres per second, which is only a few hundred kilometers an hour. I want mine to go fast, like a few thousand kiometers an hour. However, such high speeds necessitate combat at long ranges.

Relegate Projectile Weapons to a supporting role, use trace-fire weapons for most things

I don't really like this one, although it is admittedly realistic. The smallest weapon a space fighter is likely to carry would be a 20mm anti-materiel machine gun, the bullets (if you want to call them that, more like a steak knife if you ask me) go really, really fast. So fast they can punch through both sides of an APC from several miles away - and that's including wind resistance, which has a MASSIVE effect on the speed of a projectile. Point being -

modern projectile weapons go really really fast. However, science fiction space craft projectiles typically do not go all that fast, which is probrably for looks more than anything, but still. Looks are important.

Leave it as-is and have the effectiveness of projectile weapons largely determined by how well you can predict when the opponent is going to fly straight and when they're going to turn

This is, on the surface, an ideal solution. However, this sort of prediction is bound to be very difficult for an AI pilot to do. Whether or not a human player is going to turn away or fly straight is, of course, impossible to predict with complete accuracy, though it could be predicted somewhat, there are so many variables that would impractical to figure out, like volume of fire the target is taking, both from the AI in question and others, the targets capabilities, condition (damage wise), presence of friendlies, etc. I don't think that an AI pilot could handle this well without doing a lot of computation.

I do want combat to occur at closer ranges, but I don't want to slow down the ships. Also, there is a considerable difference in speed between different designs, which would make it hard to simply enforce close-in fighting by reducing ranges. One can't really argue the light and manueverable versus slow heavy-hitter argument, since some ships are just plain better equipped. (One design I made has twin engines, 6 fuel tanks, two heavy cannons, two machineguns, and an on-board fusion reactor, but is considerably faster than a lightly equipped superiority fighter I made that has only a single engine and fuel tank, two missile bays and a machinegun. (The more stuff you have, the more points an enemy gets for destroying you - it's kind of a diminishing returns thing since bigger ships are bigger targets.))

As if that weren't enough! (Later that day)

I think I need new music for the level I've made to test stuff in. The current music was okay, but it doesn't seem to fit anymore. Unfortunately, UT2003 came with a relatively inappropriate soundtrack for space-based conflicts. Hard rock seems most appropriate, but this might be better suited to the spectator-cam view. For the spectators it's all about the action, which I why I think that something like that would be best for a spectator's view. However, for the players I'd like something that caters more to the tension of a heated dogfight. Alternatively, I could go for more of a "space ambience" soundtrack with basically just assorted creaks and rattles and beeps and such - various space-craft noises to serve as the background for the sound effects from actual stuff happening.

I guess that'll have to wait until I get an actual team together, but I'm going to wait at least until UT2004 comes out before doing that. (I want to see if the 60,000 UU render distance actually has been removed, as Mosquito suggested. Preliminary tests with the Runtime suggest it may well have been, but I can't say that with complete certainty yet.)

I could have sworn I updated earlier. Oh well. Today I've been just playing around with the UI, making it a bit fancier. I added detail level options to the GUI as well. Basically boring stuff. I also swapped all the weapons to fusion cannons to test to see ifthe projectile thing I suspected above was the case. The bots have no difficulty fighting with instant-hit weapons. (They better not, they have the advantage of auto-aim! ) So the problem is fairly isolated to incorrect determination of lead - I'm fairly certain that this is a result of the target changing heading, as detailed above.

Also I want to do some optimization but I don't know what needs optimization. I haven't written any new processor-intensive code since the last update, in fact I've optimized the resource distribution system even more! Even so, I can only get about 8 players at one time now before the framerate suffers, whilst before I could have twelve. Granted, I have pretty trails now which are relatively expensive effects to generate. Unfortunately, I don't know of any practical way to find out where all the time is being spent. Once again I wish Epic would profide some sort of "execution profiler" that would count and time every function call (should be simple if you had access to the interpreter) so you could see which function calls were eating all the CPU time.

Also, I desperately need a "sloppy clipping" option for Emitters. I can make some killer particle effects, but they use so much GPU time being clipped to fit around polygons whenever a ship passes through them, it causes an unacceptable GPU hit. If there was a way to do "sloppy clipping" where a "sloppy" sprite would either be behind or in front of a given triangle (or even entire meshes), but wouldn't be drawn intersecting, that would allow me to make way nicer effects with less GPU usage.

I meant to write this up last night, but once I got in front of this computer last night I couldn't remember what I was going to write. I remember now, though, so now I'm writing it!

Anyways: I kept hearing about this game Call of Duty so I decided to give it a shot. (This was about a week ago) It was pretty fun, which is saying alot, since I generally don't like world war II games. Later I played Red Orchestra for UT2003, and I remembered what I could from TTR for UT a long time ago when I tried that.

I didn't like Red Orchestra or TTR. This got me thinking. Thinking that, since generally I don't like WWII games, if I liked Call of Duty, it must have something special about it. If I could figure out what it was that made it so good, I could likely make my mod that much better.

The graphics weren't much to write home about: they were decent, but not excellent. If I had to rate them I'd say they are slightly behind the Unreal engine's graphics capabilities. So I knew it wasn't the graphics. I was playing on my mom's computer, and someone had been screwing with the sound settings, and I wasn't in the mood to fix it, so I was playing without sound. So it wasn't the sound or the music. (if there is music)

I'm not a fan of WWII games in general, so I knew it wasn't the theme. The FG42 was cool looking, but other than that I didn't care for the weapons especially. So, still looking for the reason I liked it, I was thinking, it just feels so realistic! Now, TTR and Red Orchestra both appear to have a "realism" element to them too, so what's the difference? Well, the difference appears to be that Call of Duty has realism, while TTR and Red Orchestra had "realism."

What is the difference, one might ask? Well, both have deadly, instant-hit weapons. Both have reloading and authentic weapons and iron sights. (Actually I don't know if TTR had iron sights or not) Both seemed to have reasonably authentic levels and such. However, what Call of Duty had that Red Orchestra/TTR did not, is a realistic AI.

This goes for pretty well all "realism mods" I've seen on the Unreal Engine. I don't really remember if TTR even had bots, but I know Red Orchestra did. Tactical Ops did. Infiltration did too. (But I think they tweaked the bots, so I won't count them.) I'm sure there's others. The problem with the AI in those mods is it's just the standard Unreal AI - good for arena-style combat with mysteriously weak weapons and such, but the Unreal AI is hardly realistic, which is why I think it makes "realism" mods feel unrealistic. (No pun intended there)

Most of these modders have probrably never been in a heated firefight, so maybe you can't blame them. Trust me, you don't zig zag back and forth firing madly. The only time you ever jump is if you have to get over someone else. As far as I'm concerned, realism mods don't need a jump button at all. Trust me. Jumping in a firefight is stupid. The only thing to do is hide behind something solid and take pot shots when you think nobodies looking. Sometimes you might sprint or crawl to a better piece of cover, but that's usually dangerous. More often than not, your boot gets caught on a branch, or the webbing on your tactical vest catches on barbed wire. Then you're a sitting duck, and you get hit.

Anyways, this is exactly what the AI in Call of Duty does. They just cower behind stuff and take occasional pot shots. They barely ever hit. (It's quite possible to empty a magazine without hitting anything despite firing responsibly, because the enemy will almost always be behind dense cover, just like you are.)

Another nice thing, AI related, is that they may not notice you based on various factors. Hiding behind bushes and stuff makes a difference, and muzzle flashes give you away. Other stuff that's going on also serves as a distraction and makes the AI less aware of your movements. (Or at least, it acts less aware of your movements) Also, whether or not the AI hits you is more a question of when, rather than if. The AI appears to start with a really innacurate aim, then "bullet hose" toward you from that initial aim. This I like better than the Unreal AIs straight "chance to hit" style of accuracy.

Also I like that there's no classes or anything. Class selection in WWII games is annoying. I like the way that Call of Duty gives you several weapons, and you can just use whichever one you prefer. If you don't like it, there's plenty of other weapons laying around.

Anyways, just thought I'd post that here. Hopefully some people will read it and maybe it'll help the AI for their mod be that much better. (Not sure of the technical issues associated with detecting whether a view of a player is obstructed by a terrain deco layer, but I'm sure you could find a way.

I haven't done anything with the mod in a couple of weeks, unfortunately. I've been busy with various things such as University and getting a new car and such. Also, I've been cooking up a scheme for pseudo-atomic bomb that wouldn't require any radioactive material or cause any fall-out. Very clean and relatively cheap to build. I've been pondering if that might make an efficient powertrain for an automobile or possibly an aircraft. (Hmm, fusion-powered rocket engine.. sounds dangerous )

Something else I've come up with is an interesting concept for an operating system. As you may or may not be aware, there's a million and one things that operating systems do to prevent programs from messing with each other, control access to devices, etcetera. Also, they switch off control from one process to another every 10 milliseconds, including all of the overhead required to "clean up" the CPU for the next process while preserving the exact state of the CPU, to be restored when the previous process runs again. There's also memory relocation to make all programs believe they are the only thing executing in memory and various other things that I could only describe as "hacks" to attempt to work around the architecture. Many of these things have even been implemented in hardware to reduce the performance hit. Why that's bad is because they're hacky workarounds to begin with. What's really needed is a brand new multitasking architecture in which address translation, protection and such isn't an issue.

One might say, but that's impossible! You can't prevent programs from messing with each other without using hardware to do it, unless you're going to precheck every instruction as it gets executed, which would slow down the system by an order of magnitude. But that would be thinking "inside the box." Here's my scheme: you can check every instruction without much impact if by doing so you can reduce the total number of instructions. This can be accomplished rather easily since most things you would want to do do not require the granularity of straight machine code. So, the check (which is like two instructions anyway, what with a clever scheme I had) is amortized over a larger number of machine lanuage instructions. Since there's less overhead, (no context switches, address translation, etc.) I think it may end up actually being faster than present operating system architechtures.

I got this idea when thinking about a number of things at the same time, mostly I was thinking about how Java is so ungodly slow, whilst Unrealscript is very fast, for an interpreted language. I'm fairly certain that the difference is that in Java, virtually every low-level structure and such is implemented in Java, which is unavoidably slower than C or assembler. In UnrealScript, all the low-level stuff is implemented natively, which is good, because it's almost always stuff you would never want to change anyway. (Such as concatenation of strings and stuff.)

Anyways, basically a compiler's going to make something in-between bytecode and machine code. I was initially considering having an interpreted setup like unrealscript, but decided that that would be too slow - then you have to look up a bytecode for every instruction. However, you also can't have applications run at the machine level, because then you have to use a million and one hacks to prevent them from either inadvertandly or maliciously tying up a shared resource, damaging each other, running away with the processor, etc.

So I figured you need a middle ground. Basically, machine language, but a machine language that doesn't provide the functionality required to do the above evil things.

Anyways. There's probrably lots more I could say about that, but it's late, and I'm kind of tired of thinking about it for the time being. And there's one more thing I wanted to rant about:

This was obviously going to have to be written largely in assembler. That's okay, since I've locked horns with machine code before. Though manually looking up opcodes in a reference manual and entering them into memory on a Commodore 64 is something I'd rather avoid doing again, I figured that since back then they had these things called "assemblers," (I didn't have one) it would be a lot easier for me now that I could just download an assembler off the internet. These assemblers would allow you to enter the instructions one per line and it would convert it into opcodes and enter it into memory for you. You could even save programs and everything! Quite the marvel of technology. So anyways, I downloaded a few and was quite surprised to find that apparently assembly language had evolved into something else. Not the good kind of evolution (the kind I don't believe in anyway) where species supposedly evolve into other species. This is the kind of evolution where you live next to a nuclear plant and your firstborn has five arms.

It was my understanding that assembly language was supposed to convert 1:1 to machine language opcodes. There wasn't supposed to be any functionality that wasn't availible at the machine level. So, to my surprise, I find not only structs being declared in machine language, but functions too! After a little bit of reading I find that this is called "MASM" and was made by Microsoft. Apparently, it's supposed to be a lot like programming in C. See, the thing about that is, if I wanted to program in something like C, I'd program in C. The real beauty of assembly language is that it is supposed to be exactly like the way the processor actually operates. So, the very first long word I reserve space for in a bootloader really does go at location 0 in memory. (presumably, anyway) By putting structs and functions in assembly language, you defeat the purpose of using assembly language.

One might argue that that functionality is all optional, and you don't have to use it if you don't want to. That's fair, if you'd consider listing human blood on a drink menu (on the grounds that you don't have to order it if you don't want to) fair.

So anyway, long story short, the chair of the computer science department of the University I go to wrote a software package that emulates a PC and some hardware, specifically intended for experimenting with operating systems concepts. I obtained a copy of it and I've been using the included assembler and linker. I'm assuming (hoping) that it's compatible with x86, though I'm fairly certain it would be. At the most I might need to change the names of a few opcodes, but that would likely only entail writing a simple disassembler that takes the compiled binaries and spits them out with x86 opcodes.

On the upside, I've learned some interesting things about the way C programs look after compilation. For some reason I had suspected that when compiled all the function names would be different, or maybe even in many cases absent. However, they appear to translate literally to references that can be picked up in assembler using .extref.

I've still been super busy and haven't been able to do much with the mod. I've made a few small tweaks in the short time that I've had the opportunity to. I made the bombs self-propelled, so they're more like a slow-moving rocket, kind of like in Freespace. Previously they were basically a pure dive-bomb, requiring vehicle momentum to hit. Unfortunately, this seems to be a fairly difficult thing to guarantee for bots. Vehicle momentum still counts, of course, but the bombs are a little more predictable. I've also been considering changing salvoes of bombs (world war II style) for singular, more powerful bombs. (Like in Freespace.) That would be better for networking, and maybe would make the limited ammo on bombers a bit less limited.

Speaking of limited ammo, I've noticed something interesting when observing botmatches. The bots run out of gas. This isn't normally a problem, since they're just sitting ducks then. The issue is, if I leave it for a long time, when I come back, all the bots will be out of gas and just hanging in space. I have a couple of potential fixes to this: I can make thrusters not use any fuel. I don't really like that idea too much - it removes any incentive to carry larger fuel tanks. I could make the thrusters more efficient, but the generators still consumes fuel, so I'd have to make them more efficient too. I don't really want to do that, because there again, it removes incentive to carry additional fuel. I could make the bots suicide when they run out of gas. I'm not sure how good of an idea that is. I could also do like in Homeworld, where if a ship is out of fuel, it can still move, albeit very slowly. My qualm with this is that it might require something of a hack. I'd have to either provide some stipulation in the firecontroller to accomodate that, or make engines generate fuel at a very slow rate.

Later that day...

Aha! I got to thinking about the scale and the render distance and such, and then it hit me. The reason I couldn't just scale stuff down was because I was using the wrong factors. I didn't realize that reducing the ships to 1/10th their current size, requires the engine power, etc. to be reduced by a factor of a hundred, not by a factor of ten. (Ten times because the world is now a tenth the size, and ten times that because the ships are only a tenth of their previous size - so the ship requires a tenth the impulse to move at the same speed in UUs, but since everythings scaled down, it only should go at a tenth the speed it was going before.) This is good. It will make the world look better. Unfortunately, it's going to be a lot of work, because unless I just put something in the superclass of all my special effects, I have to update all the special effects. I don't want to put a hack in the superclass because that incurs a cost at runtime.

It's STILL the 12th? Geez.

Got more of the scale stuff changed. I also found a wierd bug that only manifested itself when I reduces the scale. This is very queer, as the bug has apparently been there for some time without effect. Almost makes me wonder if there was some other bug cancelling out the effect of this bug, forcing it to lay dormant until now. Hmmm.

Anyways, everything's scaled down, (except the lights and sounds, so the lighting is kind of washed out and you can hear things from a long way away) but I haven't decreased weapons range yet which had some interesting effects. Firstly, this is kind of bad, because you can "snipe" the enemy carrier from near your own. This isn't necessarily bad if you had some sort of long ranged weapons, but for the time being, any weapons will reach far beyond the enemy carrier. (Note to self: I have to reduce the projectile speed to accomodate the new scale.) Anyways, that's going to be changed when I update the ranges. The ranges on the carrier weapons may or may not be changed. I'm still deciding. After fixing the but mentioned above, the bots would fire again, which caused an interesting behaviour. The carriers shot at each other. This isn't in itself a bad thing, in fact it was more or less something I wanted to happen. Unfortunately, the AI is pretty good at crippling enemy capital ships. One carrier mauls the weapons on the other carrier, while the other carrier molests the inside of the first carrier's flight deck with it's beam weapons. Though effective, these things are kind of bad. Carrier two loses it's ability to defend itself from fighter attack, so there is less need for diversity to take down the carrier. Not that it matters, since your chance of making it out of the flight deck on carrier one are next to none.

I'm not sure how to deal with this, I do want the carriers to shoot at each other somewhat, but not to the extent that they severely impact the fighter's combats. Potential solutions:

• Adjust the headings of the carriers so the flight deck of carrier one doesn't face carrier twos main weapons and also so that carrier ones guns can't easily hit anything important on carrier two. This also poses a slight balance issue as fighters launching from carrier one have a slightly more direct path to carrier two.
• Start the carriers out of range from each other, and have them close in. Premise being, by the time they're in range, the attacks will already be well underway, so carrier two will already be missing most of it's guns, and fighters will mostly be launched (barring those that are respawning) so carrier two can't bottleneck carrier one's fighter bays.
• Change the carriers. Or something. This is possibly the best option. Both are copyrighted material so I can't release anything with them in it anyway. Meaning, they're going to get removed anyway, so maybe I shouldn't worry about it. Of course, there's no guarantee that their replacement won't have similar problems.

That annoying "constraint explosion" was starting to creep back in, and I was kind of annoyed. The only way I could find to keep it in check was to smoothe everything out. The AI was bad for this, since it doesn't need to move a mouse or joystick and thus can make "isntantaneous" changes in it's desired heading. Anyways, the problem was cropping up when ships would get hit hard by capital ships. They'd go careening off, the stabilizers would go crazy trying to correct, and the resultant pressure put on the Karma engine by the stabilizers wrecked everything.

Interestingly, it wasn't until today that I realized I could stop this behaviour by simply placing an upper limit on the maximum amount of stability assist that can be provided. Unfortunately, like the smoothing schemes I was using before, this is more or less only a stopgap measure - albeit an effective one. If you REALLY try to strain the Karma system, (setting level.timedilation to 10 does the trick) it's still possible to cause the constraint explosion. However, you can't really play at that kind of speed anyway, since unless you have an ungodly framrate you wouldn't really even be able to see stuff coming.

I also changed the mouse control a little bit to make it more like first person space sims. Previously you could use mouse control which was sort of like Freelancer, and your ship would "chase" the cursor, or you could use joystick, where it was like a flight sim. I've changed the system so the mouse is more like a flight sim mouse setup. This is cleverly set up to mimic a joystick, so the mouse basically just fakes it, based on how fast the mouse is moving, and/or the time since the last mouse movement. So, if you move the mouse quickly, then stop, that's like jerking the joystick and then releasing it. The downside of course is if you want to make a big turn. However, I don't think that will be that big of an issue, since I have a trackball, and I don't think there's any better solution for the brick type of mouse anyway.

One reason I made that change is so that the experience is similar using either. The other reason is that one had a bit of an unfair advantage. The joystick can only be moved so far, and has to be relative to your ship. For sensitivity reasons, you can't have extreme left be 180 degrees (behind the ship) otherwise you wouldn't be able to control very well. However, with the mouse, you could just scroll more, and thus could set your desired heading to any angle you wanted. This allowed for harder turns for mouse users. Unfortunately, it also means that the turning ability of a given craft will never be realized to it's full potential because the controls have been restricted. I'm not sure what to think about that. In a sense the ships aren't working to their potential. In another sense, limiting the amount you can turn makes the ships move a little more gracefully.