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.