I had decided to provide the bulk of the progress updates on our blogs so that there wasn’t a huge wall of text and images on the “UDK Tool” thread over at the Epic forums. This let’s me make as much of a wall of text as I’d like to, which sometimes can be often, but hopefully there aren’t too many out there that mind.

To explain the UDK Tool. The original tool was called “UE3 Tool” which went up to version 2.7 before I decided to rewrite the entire program to be more efficient. It didn’t strike me until one day that this simple tool saved hours within a week, depending on how many times I would run a test, compile, or launch a dedicated server with a client.

Seriously, I sat there and thought about it. My original setup was batch files that I would double-click to launch a dedicated server, another double-click to launch a dedicated client, which I had on my desktop so I had to clear to desktop first, and to compile I kept using command prompt; so I would hit the up arrow for history (sometimes go too far or not far enough and do something I didn’t want to do), compile, and repeat to launch.

Yes, part of that time consuming process was my fault for not using a better method, or being more organized, but I personally don’t like the Unreal Frontend. I mean, it’s fine, but it wasn’t my taste as a programmer. While thinking about what I explained previously, all of those clicks and actions consumed seconds (or milliseconds) for each action, but that time adds up and it can add up quick. Combine the above with the time consumed while navigating browser windows and the time consumed starts climbing faster (the UE3 Tool provides directory shortcuts to address this).

Therefore, the original tool potentially saved an hour or more per week by just providing a simple interface to do all of those actions with single click of buttons. A work-flow was also established, which builds habits, which increases productivity time and attempts to reduce errors. That is always a plus for a programmer.

Now, when I released the last “UE3 Tool” I had decided to make the tool more proficient to save even more time and make life of the programmer easier. Granted, I originally thought I was going overboard when I listed the features I wanted to add, but once I got started it wasn’t very difficult (it helps being a custom application developer for over ten years before going into game programming) and I just knew this was a step in the right direction. I wanted to take the tool to the next level.

Over at the Epic forums I had posted up a quick preview of the upcoming tool, which has been renamed to “UDK Tool,” as an attempt to prevent confusion as some thought the original tool was for UE3 only; which wasn’t true. This blog post marks when I’ve removed the original wall of text/images on the forum and placed them here, and this blog is for that purpose with the additional information above. This blog will be used more often than the Epic forums for progress updates.

————————————————————————————————————————————–

This tool was called “UE3 Tool” which went to version 2.7 before I decided to start redesigning the tool. I’ve also changed the name to “UDK Tool,” which the post explains. I’m directly copying the post from Releases and Download Mirrors and this will be the new “home” for any progress updates.

If you’d like to try the original tool (UE3 Tool 2.7) you can find it here: http://forums.epicgames.com/threads/869435-UE3-Tool

UDK Tool 3.0
I’ve been hard at work on the new tool. I’ve renamed it to “UDK Tool” so there isn’t any confusion, as some may think it’s for UE3 only, which isn’t the case. For any that are interested in the upcoming tool, I figured I’d show some screen-shots, and the alpha version will be releasing within a few days. There are some sections that I’m not showing since they are still in progress, but I’ll be listing what will be available.

I noticed in the first tool that it wasn’t obvious that having proper settings is required and I imagined some may not have known that; ending up not using the tool because they couldn’t get it to work. I also wanted to make something that was more user friendly, didn’t take long to learn, and was really helpful for a team environment.

To address some of these thoughts I decided to make the tool project based. Here is a screen-shot of the main interface, which only comes up when it’s the first time you’ve used the tool, or have switched “active projects”:

Same example with “New Project” highlighted to demonstrate a bit more:

When the user selects “New Project” they will go through a few sections which basically is more of a user friendly “settings:”

An example of being “user friendly” is like these examples:

Invalid

“C:\RTS” is my correct UDK installation directory but I couldn’t use “UDKBase” because it already existed. This would also work for any class folders you’ve created (in which case you would use “Import Project” from the beginning to use the tool with an existing project).

Valid

The user then proceeds to set up their tool correctly with these types of interfaces. Here is an example of the next “page” which is to setup your SVN information and optional project folder synchronization:

For the sake of this preview, I’m using a fake address, and forced the application to return true that this is a valid SVN address. In the real version it checks your settings and makes sure there is a valid SVN connection.

I’m going to spare you on the rest of the interfaces, but the overall point is that it helps guide new users through the setup process, and this only has to be done once. The only time you see the above interfaces, besides being the first time setup, is when switching active projects and/or importing an existing project (if you already had your own UDK classes and just want to set the tool up for that project).

Now I want to show a preview of the actual tool, except I’m going to keep the real tool under wraps for now, and instead I’m going to show you the work in progress UDK Tool Editor. I said I probably wasn’t going to make an IDE but it eventually was starting to make sense as an ultimate all-around tool.

At this stage it supports:

Syntax Highlighting
Bracket Highlighting
Highlighting Color Configuration
Highlight Keyword Configuration
Color/Font Configuration
Code Collapsing
Tabbing
Tab Management
Cloning
Auto Indent
Word Wrapping with Auto Indent
Line Numbers
Multithreaded Saving/Loading/Synchronization
Block Commenting/Uncommenting (via keyboard shortcut)

Another example that show the editor when using tab management or cloning:

If you’re not sure what cloning is, it’s just a useful feature to have two of the same documents in view, while remaining in synchronization. An example is if you have a class that’s extremely long, one view can be to see your variables and the other is while you’re editing, making functions, or whatever you do.

I still need a couple days but the above features are done and the following need to be finished:

Tree View (for quick file opening)
Multithreaded UDK Compile (no editor locking while compiling, log window will display in the editor, including while in-game testing)
Debugging (based on compiling and during in-game testing)
SVN Commit and Synchronization
Auto Completion (this is already working I just need to spend more time on it)
Intellisense (also is working but I need to spend more time on it)
Auto Complete/Intellisense Auto Updating (this is so that your specific classes are added to the lists)
Search, Search and Replace, and Search Files

And that should be it for the UDK Tool 3.0 Editor, should only take a couple or few days, I’ve spent two days on the editor at the moment, so my progress is fairly steady.

That is all I’m comfortable to show at the moment, everything else either needs to be created, or is in an ugly state to be shown (such as ugly interfaces as place-holders).

If anyone would like to donate towards what I’m creating, it would be greatly appreciated, even though I told myself I wouldn’t ask, but what can it hurt? So, if you would like to, you can do so by clicking here – a direct paypal donation link

Anyways, I hope you enjoy this quick preview, and I hope you’ll like what I come up with for the next version of the UE3 Tool; now called “UDK Tool.”

Sorry, I forgot to list what will be available in Alpha, not just in the editor.

To reflect my previously written plan, which overall is what will be available, but I wanted to make sure the concept of the first tool wasn’t lost. This version will have and has the same shortcuts to: build, run, build and run, launch dedicated server, launch listen server, launch dedicated client, launch remote client.

The directory shortcuts will still be available as it did in the original tool but now with the editor having a project tree view it may not be needed as much. However, it was always useful, so it will be included. I will be creating a configuration window so anyone can create their own additional shortcuts.

UDN shortcuts will be available as it did in the original. Same idea with the above, a configuration window will be available to add your own help file shortcuts, and I will be adding tutorial shortcuts as well.

Log management will also be available as it did in the original. Absolutely need that.

The UDK Tool (UE3 Tool version 3) will be adding mostly SVN integration with a more powerful back-end to support advanced features. If your project uses SVN it will let you easily commit changes, update from SVN, and there will be an option for consistent synchronization. There will be a “project synchronization” which is essentially a “Dropbox-like” type of setup which will be useful for consistently changing files (like during prototyping or game design document writing or … something).

A backup system will be put into place, which will be optional, since most people who have SVN don’t really need another backup, but the option will be there. Backup your project folder (scripts only) to your email address, FTP, SVN, or all three.

A project manager will not be available during the initial release. I have to spend a good amount of time on the project manager but it will be done, I have a lot of plans for it, I just need the time to make it. I’m running out of time because we need to release in-game video of our project (http://www.ratsarmy.com) and I need to get back to that very soon; especially before my partner kills me

I believe that is all for this moment without explaining all the very small details.

 

Firstly, I’d like to apologize for the recent spam in the community forums, they have been taken care of, and hopefully they won’t be seen for a while (but hopefully forever). We encourage anyone who visits this website to please register and post up. We don’t post much in the forum but we do check it every day. We honestly haven’t been advertising R.A.T.S. as much as we should be, but it’s due to our small team size, and having no time to concentrate on such things.

As an update on the overall progress of R.A.T.S., we are currently in polish phase, before moving on to more features. We try to polish as we go along but sometimes it’s good to stop and look everything over. We’re trying our best to prevent potential bugs or errors before releasing, even for closed beta. While we’re in this phase, I figured I’d write up a blog, not only to update everyone, but to also begin a blog about the weapon logic in Unreal® Engine 3.

There has been talks, between Jamie and I, about potentially providing a full tutorial on custom weapons and having them working in UDK. The entire process, from modeling (mesh, UV, painting, rigging, animating, etc.) to programming (inventory manager, player controller, player input, pawn, weapon, replication, etc.), and hopefully teach those whom are new to the engine. I’ve seen countless questions about custom weapons on the UDK forums and brought it up to Jamie, and so we’re thinking about it, as of course it takes our time away from R.A.T.S..

I was thinking about this again as I was polishing up our Inventory Manager and Weapon class. I figured I could start by going through some of the weapon logic that is going on in the engine classes.

A couple important things to remember. The Controller class is used by both the Player and the AI. So, it makes sense that there is some logic within the Controller class. Here is a quick look through the Controller class that only emphasizes anything that interacts with a weapon.

 

event Posses(Pawn InPawn, bool bVehicleTransition);
Controller.uc, line 595

Though that function doesn’t directly interact with the weapon, it’s sole purpose is to attach the controller to the specified (passed in) Pawn. It does, however, perform the following (line 609):
if(Pawn.Weapon == none){ ClientSwitchToBestWeapon(); }

If the Pawn does not yet have a Weapon (which it most likely won’t) then it performs the function “ClientSwitchToBestWeapon().” Which can be found on line 1038.

This function is a replicated function. Examine the following:
reliable client function ClientSwitchToBestWeapon(optional bool bForceNewWeapon)

It has to be understood that if the server executes a “reliable client function” then it is replicated to the client (player) that owns that Actor. The keyword “reliable” means it will always be sent, whereas “unreliable” is dropped if bandwidth is limited.

This function simply then calls “SwitchToBestWeapon(bForceNewWeapon).”

On line 1022 you can examine the “SwitchToBestWeapon“:
exec function SwitchToBestWeapon(optional bool bForceNewWeapon)

An “exec” function is a special function that can be executed by the user/player at run-time by using the in-game console and is usually bound to a key bind (within the DefaultInput.ini configuration file) since they execute console commands. By default, this is bound to the “G” key.

This function eventually executes “Pawn.InvManager.SwitchToBestWeapon(bForceNewWeapon)” and this is when it starts to get a bit more advanced. Pawn has a variable called “InvManager” which stores the Pawns “InventoryManager” (which is also replicated via replication notification) and this function accesses this variable to execute the Pawns Inventory Manager class function. The Pawns Inventory Manager is created during the “PostBeginPlay” event within the Pawn class, which uses the variable “InventoryManagerClass” to define which class to spawn. You would generally create your own Inventory Manager class and define this within your Pawn classes default properties.

The “SwitchToBestWeapon” function is found on line 423 within the “InventoryManager” class. This is where the actual logic happens to decide which weapon to switch to, and can be based on ammunition amount, a weapon rating type, and so on.

I didn’t go through much at all, barely scratching the surface of how weapon logic works, however I’ve ran out of time and writing the above made me realize that teaching something like this could never be done in a blog. It’s hard to stylize Unreal Script code, I imagine once I look at this document on the website, the overall structure isn’t how I’ve actually written it out, and it just would overall cause a mess. I believe the best method is to either create a PDF document or a specialized website in which I’d do manual HTML to ensure everything looks proper. I could also easily use screen-shot snippets of code that is properly highlighted in my programming application instead of manually stylizing it.

Anyways, I hope I didn’t disappoint anyone thinking this would continue into a full tutorial, but I’m strongly thinking about doing such a thing. Generally I would erase this and let it go, but I’m going to post it anyway, hopefully get some feedback about how I word everything, or the flow. Don’t judge it too harshly though, it wasn’t planned out, I just wrote it as I went along.

 

Going to try and start doing what I use to do back when I had the blog before this one. I was posting up blogs before, during, and after each system or sections of the framework for R.A.T.S..

I’m skipping a lot of systems or sections of the framework that I didn’t cover in this blog but it would just take way too long to try and catch up. That’s usually time I just don’t have. The part I’m about to cover has already been finished but figured it would be a good place to start.

Weapon switching. Within this blog history you’ll see blogs covering inventory management, which goes along with weapon switching in general, but this part is covering more visual aspects of switching weapons.

Beyond performing “equip” and “unequip” animations, for both first person and third person, we also wanted to keep the weapons where they should remain as an unequipped item. To better explain what I mean, here is the process in a few screen-shots, but note the pistol in the holster and when switching to the pistol the rifle remains on his back:

 

 

Each weapon is assigned it’s specific location to attach the weapon after unequipped. The UMP45 is attached to the “Item1Socket” location and the pistol is attached to the “Item3Socket,” leaving “Item2Socket” reserved for future purposes. The pistol holster is also attached to the “Item3Socket.” Each pistol can have it’s own style of holster, it is not permanently attached to the character, it was specified by the pistols properties.

The whole system works fairly well, even over network, but there are some issues that have to be resolved. It’s not the fault of the weapon switching but the animation sets and animations. I switch between AimNode profiles so that there is less movement while moving around and switching weapons, however some animations (such as full leg turning for left/right movement) get in the way.

Beyond that I was fairly happy with how this turned out. I would have personally preferred a sling on the weapon and the character slinging the weapon over his shoulder, but this looks good too.

That’s all for now. Next blog I will probably get into “Dropped Pickups,” which is basically the character dropping their weapon upon death. We have our own special way we’d like to handle that situation, but we also have to handle situations such as the first screen-shot above: the weapon “in-hand” by default would drop but the pistol would remain in the holster.