Blog for John Vanderbeck at GarageGames.com

Wednesday Apr 6 13:45

John Vanderbeck — 2005-04-06T13:45:35+00:00

TileIt Leaks out!

Yesterday a sneak peak playable prototype of TileIt was mysteriously leaked to Torque2D owners and a few others in the #gameinaday IRC channel. It is still not clear how this nefarious act managed to take place, but we're quite certain black helicopters and flouride laced drinking water was involved somehow.

On the bright side apparently those that received the leaked game enjoyed it and want more. We are continuing to work on the whacky puzzle game and will hopefully be releasing a real demo within a week or two.

Monday Apr 4 14:49

John Vanderbeck — 2005-04-04T14:49:27+00:00

My disastrous attempt at GID #11

My disastrous attempt at GID #11. Whoah what a mess. You can read a play by play journal that I kept during the event with screenshots and a link to the game itself (what there is of it) here.

It started out what I thought was simple enough. I wanted a simple game that would help me learn Torque2D, but that would be fun and addicting so that after GID was over I could polish the game up as a commercial release. My choice for a game was what I call TileIt. Essentially you have a vertical game board consisting of a fixed hard border around the edges and a series of moveable tiles inside the border. You remove tiles by clicking on adjoining tiles that match each other. To remove tiles they must match and be touching either horizontally, vertically, or diagonally. The twist is that as you remove tiles, you can also rotate the game board. When you do so, tiles will fall down through the spaces left by removing tiles. In this manner you can continue to remove tiles and rotate the board to give you openings to remove more tiles It sounds like loads of fun to me. I also thought it would be fairly simple because I could just let the Torque2D physics handle the falling tiles.

Boy was I in for an eye opener. For one thing, I had to work both Saturday and Sunday at my "real" job, so in the end during the whole GID event I only had about 12 total hours to apply to my entry. A game in 24 hours is hard enough, but 12 for my first GID was hair-raising!

For another this was intended as alearning excercise. I was still a relative noob with T2S having only purchased it a week or two ago. I understood the raw basics and nothing else. This ended up causing problems for me time and again as I wasted valuable time struggling to figure out how to do something, or fix something. Despite that however, T2D was a virtual gem to me and it was only because of T2D that I did in fact get so much done in so little time.

In less than 2 hours I had managed to get a large majority of the game coded up, giving me a partial game board (I only coded up enough for prototyping at this stage), and the basic gameplay elements. It was very nice.

My first major problem though was when I realized the built in T2D physics just weren't giving me the ultra simplified tile dropping that I required. The physics were TOO good :) Tiles that I wanted to drop STRAIGHT down and stop were in fact spinning due to friction, bouncing all over the place, and being nudged out of thier slots. After a long few hours I managed to tweak the physics properties to fix most of those problems but a few I never could fix including the fact that even with my friction set at 0 the tiles acted like they had surface friction applied, causing them to drop down very very slowly when between other tiles. Sometimes not drop down all the way becuase they'd get stuck. They also kept getting "nudged" over a few pixels every now and then screwing up the whole game board. So eventually afgter probably half my GID time was over I ripped out all the physics stuff and tried to put in my own collision response. My real simple collision response was if two tiles collide stop them :p I then went to bed as I had to work on Sunday.

Sunday morning before work I grabbed a few minutes to apply some AWESOME graphics provided by a fellow GIDer Joe Lesko. Thanks again Joe! Then I had to head off to work for the majority of the day, ug.

When I got home and started to work on fnishing things up I knew my super simplified collision response just wouldn't cut it. I tried various things like checking positions on the tiles to see if they were next to each other or above, below, whatever, but that never panned out. I didin't understand the collision normals enough to do the same, but I suscpect even if I had it wouldn't have worked in some cases. After about 2 hours of the approximately 5 I had left till midnight I threw out the colllision all together and completely wrote a function to scan the whole game board and manually move the tiles around. I had come a long way from what I had intended. Originally planning to simply rotate the board and let gravity and T2D Physics do the rest, here I was writing and algorithm to scan each and every tile, look underneath it, and move it down if there was nothing there. Using a grid system.

Now I FINALLY had my game board workign in that I could remove tiles and other would fall properly. Yay!

Only one nagging problem left, and that was that the board rotated funny. I was having weird issues with the T2D rotation that seemed to be causing the boards' tile transforms to get messed up when rotating. I set down to fix it and 4 hours later was still unable to do so :( At this point I gave up in fristration, declared a bug in T2D (Which in fact I don't know for sure I was just mad at the world by this point) and said "Heres my GID its unfinished but i'm out of time".

Tuesday Feb 8 22:44

John Vanderbeck — 2005-02-08T22:44:04+00:00

Where I am, where i'm going. The last 6 or so months have been very rough for me, but i'm fighting back.

The last 6 months or so have been pretty rough. In October I underwent a procedure to help control my Hperthyroidism. The procedure was succesful but i'm still recovering and trying to return to some semblance of a normal life. It has been one heck of a rollercoaster ride with my thyroid levels the result of which is often extreme fatigue making it difficult to do the things I enjoy.

Wit the cost of the holidays plus thousands of dollars in medical bills, plus increased hours at my dead end day job, I had to cut my cable and internet for most of that time as well.

As if that wasn't making things difficult enough, a few months ago My co-owner of Novus Delta and I had a parting of ways. He is retaining Novus Delta, Genesis3D, and Destiny3D. I'm retaining Torque and Mayhem 2090 and going my own seperate direction now. I'm in the process of founding my own company, On Target Games.

After being away from Torque for so long I feel like i'm starting all over -- and in some ways I am. Now that Mayhem 2090 is 100% mine (and in fact i'm the ONLY one working on it now) I have decided to redo the design to make it into more the game I personally want to make. The major change is genre. Mayhem 2090 will be an RTS style game instead of the FPS it was originally designed to be. There is much more to it than that including many design elements that have never been done in an RTS to my knowledge, but i'd rather not get into them now. For one I don't even know for sure I can pull them off, and for another I just would rather keep them secret until i'm farther along :p

I want to apologize to the community at large for my sudden dissapearence, as well as several tools and projects I was doign for the community that just got left incomplete or not as complete as i'd like.

I'm slowly trying to work my way back into all this. Relearning Torque as I go and trying not to overstress myself too much. Unfortunately between my day job, doctors trips, and my medical restrictions, I don't get more than a few hours a week to work on Torque now, but i'm determined to not let that stop me.

Friday Aug 20 16:30

John Vanderbeck — 2004-08-20T16:30:01+00:00

Torque GUI Builder and Mayhem 2090

The first release of the Torque GUI Builder is now out. For the most part it is complete though there is still some cleaning up to do and a few maintenence functions left to be implemented before its "done". It currently supports quite a few basic Torque controls and the plugin system it uses allows easy adiditon of more at any time so that is a good thing :)

Mayhem 2090 is still moving along though it is doing so very very very very slowly :( As usual, finding people willing to work with only the hope of something coming back to them in the end is very hard to do. I have my network of friends and associates who are always willing to help, when they can, but that means i've got a constantly changing set of people working on the game and that means very slow development. It also means i've got gaps that slow things down even further. We're still in desperate need of a texture artist and a concept artist.

Since I like to show pictures in my .plans, here is one that encompasses both of the subjects in this .plan. The GUI Builder and Mayhem. The screenshot below is taken from the new show tool i've been wokring on after it was overhauled to use the new GUI builder. The model shown is a work in progress Mayhem 2090 model of the Ritak Assault Vehicle which you've seen concept art for in previous plans.

Enjoy!

Saturday May 22 14:24

John Vanderbeck — 2004-05-22T14:24:18+00:00

The Torque GUI Builder & Show Tool v2 progress

The Torque GUI Builder i'd say is for the most part built. The entire framework is done and working better than i'd originally planned. The only thing left to do is add in support for more control types (it currently only supports 3 types of controls) and perhaps more options for control positioning (currently there is support for absolute positioning, as well as "above, below, left, right" options). The fact that I need to add these in got me thinking about some things though. I was thinkign to myself how if I provided some easy way to add controls then perhaps some people in the community would be willign to help me flesh out the control support. Then that got my thinking what about people who have added custom control types to the engine. They would need an easy way to add those to the system. Custom controls then got me thinking that there might be soem cstom issues wth displaying those controls that I couldn't think of. That all got me thinking, "Why not make the controls and layout options dynamic. Stick those into a plugin system." So that's what i'm workign on now. When its done (which should be tonight), the control types and layout options will be completely abstracted away from the core system. There will be two directories named "controls" and "layouts". You will be able to put together a very simple script then drop it into the appropriate directory and the system will load and use it. This will make adding new control types and layout options as simple as writing the plugin (Which is really only a single function for either one) and dropping it into the directory.

My goal is to have that done tonight after work, but I have to be honest with myself and account for the fact that I might be too tired to do it. I have to work tomorrow as well but I think I have monday off (need to double check that). So at the very worst it will be finished by Monday. Once this part is finished, I can declare the Torque GUI Builder finished. At least the initial version/release of it. Anyone can then easily add controls and hopefully I can get some help on that. With that finished, I can then focus my efforts back on the Show Tool v2. The core of that is also done but I had it in limbo waiting on the GUI system which I need for it. With the GUI Builder done i'll refocus on the Show Tool and shoudl have a very basic initial relase sometime next week. It will NOT have ALL the features of the original show tool, but it will have the basic features such as loading a shape and playing animations. This will allow all you artists to see the direction i'm goign with it and complain or praise that direction so I can adjust things for the next release :)

If anyone would be willing to help out with the GUI Builder by writing some control plugins please let me know. This is really more grunt work then anything else, but the less controls I have to do myself the more time I have to work on the Show Tool. While the system isn't in place for me to show exactly how adding controls will work, it will basically be as simple as something like this:

// Control plugin for the control: GuiMLTextCtrl
package TGUIControl_GuiMLTextCtrl
{
	// override the function which actually creates the control
	function createGUIControl(%control)
	{
		// Dynamiclly create the code which will create this control
		%code = "%newControl = new GuiMLTextCtrl(" @ %control.name @ ") {" @
			"profile = \"" @ %control.profile @ "\";" @
			"horizSizing = \"" @ %control.definition.horizSizing @ "\";" @
			"vertSizing = \"" @ %control.definition.vertSizing @ "\";" @
			"position = \"" @ %control.x SPC %control.y @ "\";" @
			"extent = \"" @ %control.extentX SPC %control.extentY @ "\";" @
			"minExtent = \"" @ %control.definition.minExtent @ "\";" @
			"visible = 1;" @
			"command = \"" @ %control.command @ "\";" @
			"text = \"" @ %control.text @ "\";" @
			"groupNum = " @ %control.definition.groupNum @ ";" @
			"lineSpacing = " @ %control.definition.lineSpacing @ ";" @
			"allowColorChars = " @ %control.definition.allowColorChars @ ";" @
			"maxChars = " @ %control.definition.maxChars @ ";" @
		"};";
		// If the user has debug mode set, we display the code we generated
		if ($guiBuilder.debug)
			echo(%code);
		// evaluate (run) the code we created
		eval(%code);
		// return the control we created
		return %newControl;		
	}
};

Friday May 14 17:26

John Vanderbeck — 2004-05-14T17:26:28+00:00

Dynamic GUIs with the Torque GUI Builder

I've been rather quiet the last few days or so, but I haven't been idle. For the show tool that i've been working on, I wanted to have a GUI system that was dynamic. This system would present users with GUI options that were most relevant to the task at hand.

I knew that the best bet would be to design a seperate system that would make working with GUIs dynamicly a lot easier, and so that's what i've been doing the last few days. A few minutes ago, after writing a huge amount of code with no testing (I hate stretches of code like that) I finally managed to get the whole framework in place and cheered when it all worked.

So just how does it work?
The system is actually quite simple to use. There are a few core concepts that will help illustrate the system.

GUI Pool
The GUI pool is a master pool that contains ALL controls used by the system. You would start by adding a control to the GUI Pool. The specifics of adding a control depend on the control type (currently only buttons are implemented) but basically you define the basic attributes of the control. Here is an example for adding a button control:

%button = $guiPool.addButton("buttonName", "Quit", "quit();", "GuiShowButtonProfile", "150 17", "show2/client/ui/button_blank");

In the case of a button you define the name of the button, the text shown on the button, the command to execute when the button is pressed, the GUI profile to use for the control, the buttons extent, and the bitmap used. If the button is created ok, then the new control is returned.

Now you have a button added to the pool.

GUI Set
A GUI Set defines a collection of controls that are displayed together and in relation to each other. The concept of the set defines both with controls are displayed, as well as how they are displayed. You will notice that when adding our button to the Pool that we gave no information on where that button would be displayed. We did this because the Pool has no concept of positioning. This allows you to add a single control to the system that may be displayed in any number of positions. It is the Set itself that handles positioning. You could therefore add the same button to multiple sets and have it displayed differently in each set. In order to display our button in a set, we have to add it to one.

%set = $guiBuilder.createSet();
%set.addControl(%button, "Anchor", 200, 200);

First our code created a new set to work with, then it add the button which we added to the pool earlier. Here we see some positioning at work. our button was added as an "Anchor". Anchor's are very important because they provide a base, or anchor, for posititioning other controls. In this case we place the control at an absolute position of 200, 200. This could also be something like 50%, 0 for example, which would place the control in the middle of the screen horizontally regardless of resolution, and up against the top edge.

Now let's see how we would add another control. Let's say for example we want a series of buttons one underneath the other. Let's just build off of our Anchor now.

%set.addControl(%button2, "Below", "Anchor", 5);

What this call basically says to the GUI Builder is "Place %button2 below the Anchor control with a space of 5 pixels". Below means the control is placed below the indicated control so that the left edges line up.

But now how do we place the 3rd button? We don't want to place it in relation to the anchor. We want it unerneath our %button2. Here's how:

%set.addControl(%button3, "Below", "", 5);

By not specifying what control we want this in relation to, the system defaults to the control previously added to the set.

Ok so we've built a set now. Now that the set is built, we can use it anytime we want without having to define it again. Whenever we want to make the set visible (IE draw all the controls):

$guiBuilder.enableSet(%set, playGUI);

What this does is tell the master GUI Builder to enable the specified set, and display it on the GUI screen "playGUI". Viola!

This is the basics of the system. I'm not sure if I conveyed it well or not, but it is actually very powerful and easy to use. Basically you just add all the controls you use for your application to the Pool, then define each Set you plan to use. When you want to display a set of controls, just enable the set. You can create new sets, or even modify existing ones, at any time through the code, as well as add new controls as needed to the pool. It is all completely dynamic.

As a last example, here is the little piece of test code I was using as I developed it.

function testGUI()
{
	$guiBuilder.init();
	%button = $guiPool.addButton("button", "myQuit", "quit();", "GuiShowButtonProfile", "150 17", "show2/client/ui/button_blank");
	%set = $guiBuilder.createSet();
	%set.addControl(%button, "Anchor", 200, 200);
	$guiBuilder.enableSet(%set, playgui);
}

Monday May 3 14:49

John Vanderbeck — 2004-05-03T14:49:15+00:00

Show Tool Plugin System

This isn't a long post, but just a quick .plan to say.. YES! WOOHOOO!! I just finished implementing the raw skeleton of the plugin system and tested it with a very simple plugin that changes the loading behaviour of static objects. This is a huge step forward for me in the development of the new Show Tool, as this was probably the most work intensive aspect of it.

// Show Tool Plugin
// This script file implements a Show Tool Plugin
// Plugin interface is designed by John Vanderbeck and Novus Delta, LLC

// Plugin Name: StaticGravityMod
// Description: This is a very simple plugin designed to illustrate most of the
// basics behaviours of a plugin.  What this will do is add some controls to the
// Show Tool allowing the user to change the gravityMod on displayed static shapes
// as well as modifying the datablocks on shape load to achieve the effect.
// Events Used: onLoadStaticShape

// This code registers the plugin with the Show Tool and is required for all
// plugins.  The code is the same for all plugins, but replace "StaticGravityMod"
// with the name of your plugin.  It must be all one word with no spaces.
new ScriptObject(StaticGravityMod); // create an instance of our plugin
StaticGravityMod.pluginId = $gShow.registerPlugin("StaticGravityMod"); // register our plugin and save our assigned ID
if (StaticGravityMod.pluginId == 0)
{
    // Plugin failed to register properly.  This could happen if the plugin name
    // is already in use by another plugin, there are no more slots available for
    // another plugin, or the system just barfed :)
    // In any case the plugin was NOT loaded and will not be called.
    echo("StaticGravityMod: ERROR, Plugin failed to register.  Plugin is not loaded and will not be available.");
    // cleanup
    StaticGravityMod.delete();
}

// This code is executed by the Show Tool when the plugin is first loaded.  This provides the
// plugin with a place to do first run intialization
function StaticGravityMod::onCreate(%this)
{
    echo("onCreate");
    if ($gShow.registerEvent("StaticGravityMod", "onLoadStaticShape") == 0)
        echo("StaticGravityMod: ERROR, Plugin failed to properly register for the onLoadStaticShape event.");
}

// This code is executed by the Show Tool when the tool is shutting down and the plugin is to be unloaded.
// This provides a place for the plugin to clean up and free memory
function StaticGravityMod::onDestroy(%this)
{
    echo("onDestroy");
}

// This code is executed by the Show Tool when a UI button belonging to the plugin
// is to be displayed, or is pressed
function StaticGravityMod::onButton(%this, %buttonName, %state)
{
    echo("onButton(" @ %buttonName @ ", " @ %state @ ")");
    // %buttonName will be the text name of the UI button
    // %state will either be "Query" or "Pressed"
    //  "Query" indicates that the Show Tool is about to display this button
    //  and is giving you a chance to do any last chance modifications to the button
    //  before it is displayed, such as making it inactive or changing its appearence.
    // 
    //  "Pressed" indicates that the specified button was pressed (clicked on) by the
    //  user and the Show Tool is giving you the opportunity to perform whatever actions
    //  you need to perform based on this.
    //
    // If %state is "Query" and this function returns 0, then the Show Tool will attempt
    // to disable the button or make it inactive.  To do this it will first make the button
    // unclickable, then it will look to see if an inactive version of the button was made
    // available to the tool.  If so it will display that button instead of the active one.
    // This provides a quick and easy way to disable the button.  If the return is 1, the 
    // button will be made active.  If %state is "Pressed" then the return value is ignored.
}

// This code is the heart of the plugin in most cases.  The main interface
// with the Show Tool and Plugin consists of events.  The plugin specifies that
// it wants to be told when certain events occur, and when they do this code
// is executed so that the plugin can respond.
function StaticGravityMod::onEvent(%this, %event, %eventParam1, %eventParam2)
{
    echo("onEvent(" @ %event @ ", " @ %eventParam1 @ ", " @ %eventParam2 @ ")");
    // %event will contain the name of the event which is being sent.
    //  "onLoadStaticShape" - Whenever the user loads a static shape,
    //      after the datablock has been loaded but before the shape
    //      is created, this event is called.
    //
    // %eventParam1 and %eventParam2 will contain event specific information 
    // which varies for each event.
    
    switch$(%event)
    {
        case "onLoadStaticShape":
            if (%eventParam1 $= "preLoad")
            {
                %this.gravityMod = 1;
                eval(%this.buildDatablock());
            }
    }
}

// What functions are available on the Show Tool side for the plugin to use?  How does the
// plugin manipulate the Show Tool?
//
// The first way the plugin can manipulate the Show Tool is through the use of the main Show
// global.  This variable is "$gShow" and is the main location of all Show Tool related 
// variables and functions.  All interaction with the Show Tool will go through this global.
// A list of variables will be eventually placed in here for documentation.
//
// The second way the plugin can function is by calling key functions on the Show Tool.
// You've already seen one, the "registerPlugin" function.  The rest will be
// detailed below eventually.
//
// registerPlugin(pluginName)
// registerEvent(pluginName, event)
// unregisterEvent(pluginName, event)
// guiAddButton(buttonName,buttonImage,initialState,group)
// guiSetButtonState(buttonName,state)
// guiSetButtonGroup(buttonName,group)
// guiSetButtonImage(buttonName,buttonImage)
// guiGetButtonPosition(buttonName)

//-------------------------------------------------------------------------------
// Custom functions for this specific plugin.  Note: All functions, ALL, of them
// should be contained inside the plugin's namespace to avoid any possible problems
// with duplicated names.
function StaticGravityMod::buildDatablock(%this)
{
    %db = "datablock ItemData(GenericItem)" @ 
        "{" @ 
        "gravityMod = " @ %this.gravityMod @ ";" @
        "};";
    echo("Datablock:\n" @ %db);
    return %db;
}

Sunday Apr 25 21:57

John Vanderbeck — 2004-04-25T21:57:39+00:00

Show Tool Reloaded, Contracts, Day Job, Torque Real-Time Physics Editor, and Mayhem 2090.

Oh boy have a lot of things happened since my last .plan. So much that this might actually rival a Davis .plan (tm)!

First off is the new Show Tool. For those of you who didn't catch the thread, i'm involved in a total re-write of the Show Tool to bring it more in-line with what it needs to be. The above linked thread has more details and some screenshots. Progress of this has been painfully slow however, and i've wasted a crapload of time trying to implement some form of camera with collision on the scrpit side for the last few days. I'm now temporarily giving up on that to move on to some other aspects of the tool. I'm slated for an initial alpha release by tomorrow so I can't stay hung up on the collision. I really, really, want to have the basics of the plugin system working for this first release. Essentially this system will allow the tool to be easily expanded for modifications to the engine/resources. For example let's say you applied the Stencil Shadows resource. A plugin could be created which would integrate control over those shadows into the tool. The plugin system will allow a plugin script to add its own interface buttons to the tool, which would run its code. It will be really basic but should work nice.

Picked up two contracts this month. One for pay and one for trade. The one for trade is with Shay Casey and the NWX project. This is a snowboarding/sports type game. Shay is doing desperatly needed concept art for Mayhem 2090 and i'm doing some Torque programming for NWX. The other contract, for pay thankfully, is an automated testing system for another game.

Unfortunately 2 contracts in one month, and none last month, doesn't put enough food on the table, so I was forced to pick up a crappy day job :( As of earlier this week i'm now working as a salesperson in Sear's Home Electronics.

Torque Real-Time Physics Editor. What the heck is that? It is a project that we had messed around with internally when we first got Torque then shelved mainly due to my lack of understanding with the engine at the time. Recently i've pulled that back out and started to look at it as a viable tool again. It really didn't work and was a piece of crap but now that I understand the engine again i'm going to tackle this tool again. In a nutshell its similiar to a beefed up Show Tool that provides a very easy tool for loading a player or vehicle, testing the physics, and modifying the physics all in real-time so you can tweak the settings and immediately see the results.

Mayhem 2090 is really starting to rock and roll now. With the concept art coming in, the models being built, i'm getting really excited. In less than a month w'lll probably be actually playing a very initial alpha! YAY!

In fact, i'm so excited about the way things are moving on Mayhem 2090 that right here, right now, i'm going to release the very first sneak peak of any Mayhem 2090 content ever so far! What you see below is a Ritak Mobile Assault Vehicle. This thing is huge (like 8 meterss tall) and if you see one, you might consider running the other way.

Enjoy!

Concept art of the Ritak Mobile Assault Vehicle by Shay Casey

Wednesday Apr 14 19:28

John Vanderbeck — 2004-04-14T19:28:42+00:00

Linux tamed?

So I spent the day off and on taking another stab at Linux. With the Mayhem chat program rapidly maturing, I was going to need to eventually compile it under Linux so it could be run on our server. As some of you may have read, my last attempt to get Linux working as a dual boot was disastrous to put it midly, but I wasn't about to give up. After reinstalling Windows and getting things back to about the way I like them, I Ghosted my machine, and got ready to dive back into Linux.

This time I chose a much friendlier distribution; I opted for SuSE this time around. I first downloaded the "LiveEval" to see if it would run on my system, and other than a few hitches it seemed to do so. I then downloaded the boot iso, burned it, inserted it, took a DEEEP breath, and rebooted and began the installation. The installation from FTP took a god awful long time (on broadband), but after about 5 or 6 hours (no joke) everything finished and I rebooted.

Yay! I was looking at my new KDE destktop! Woot! I tamed it!

Or so I thought. My keyboard wasn't working. Gah! I use a Logitech Wireless USB keyboard, and it wasn't working. I hooked up a crappy old "normal" keyboard and it worked fine (Well fine except for the fact that its a broken keyboard and only about 7 letters on it actually work). So I then hunt around the house and find one of those neat little USB to PS2 adapters and plug my wireless base into the standard keyboard slot. It works! Yay! Using my elemtary powers of deduction learnt from Mr Holmes himself, I decided there must be a problem with the USB support in my install. After about 20 minutes of digging around KDE I finally found sound configuration options, and I noticed that what it called "Hotplugging" was already installed. Hmm. I fudged around with some settings for a bit, and suddenly my keyboard was working with the USB hookup. YAY!

I wanted to stop here and rest, but obviously this was all for not if I couldn't get Torque working and compiling. So that was my next step. First thing I did was install KDevelop 3, as i'd seen it mentioned on the forums. I then followed the instructions in the KDevelop section of the new Getting Started docs (Woot Josh!) and ran into my first problem. While SuSE was cool and mounted all my NTFS Windows drives so I could access them, I found that they were read-only. Boo. Ok, so I check out a new copy from CVS onto my Linux partition, and try again. Yay! I have Torque in KDevelop now! Loading the project file, or changing any project settings takes about 10 hours which sucks, but oh well. Build->Make. Fail! Booo! Konsole. cd !/projects/torque make -f blah blah. Back to KDevelop Build-Make it starts! Yay!

Erro you don't have nasm you moron. Boo! Install nasm package, make it goes farther. No SDL. Boo! Install SDL yay! No openAL boo! install OpenAL yay!

Then the one word that made me scream in joy.

SUCCESS

YAY YAY YAY YAY YAY!

I GOT TORQUE COMPILED IN LINUX! YAY!!!!

Ahem.

I run Torque demo. It runs! Holy cow this is cool! I've actually got Torque installed and running under Linux.

Now comes the time to deal with some issues I have no idea yet how to handle. For one, it looks like I have to maintain two seperate sources; one for Linux and one for Windows. Thats going to be a nightmare. I'm going to have to see if theres anyway to change that, because i'm not looking forward to applying all our changes again. I also need to see how to get some of our custom stuff compiled, such as SQLite. That's what i'm actually working on now.

But i've finally gotten over the top of that hill I think. I'm so happy.

Tuesday Apr 6 15:16

John Vanderbeck — 2004-04-06T15:16:50+00:00

GarageGames Forums Links

The GarageGames website has a really neat feature that allows you to in essence "mark" and easily find resources for later perusal. You can rate a resource a 4 or a 5 and it will then show up on your My Garage page under recommended resources. This is a handy tool. In addition, any threads that you start can pretty easily be found from the My Garage page. What is not easy to find later on is forum threads that you did not start. Threads that you posted in are a little easier to find, but still pretty hard once you've posted a lot. Threads you didin't reply to at all are real hard to find.

The website offers a "My Shortcuts" section on the left, but it is essentially useless. It only lets you mark 8 different items, and if you mark a forum post, it simply shows up as "Forum Posts".

After losing a bunch of my bookmarks that weren't backed up when I had to reinstall Windows, I decided I needed a better way. What I decided to do was make up a .plan that will link to any forum threads I find useful, and just keep it updated as I find new things. Anyone is welcome to use this list as well. I have a lot more to put in here, and of course it will be constantly updated as I find new things. So without further ado...

"Look" Animations
How to fix light source directions for proper shadows
Fixing ZIP file support (This may already be fixed in HEAD)
Interesting diagram of the Torque script sequence
The Tribes Networking Model
AudioEmitter Upgrades
Vehicle AI