Dade's Blog

CodeIgniter Templating

dade- — Tue, 02 Mar 2010 11:59:21 +0000

These tutorials and code snippets for CodeIgniter are, sadly, in no particular order as these are things I’m discovering as I go and thus they are all over the place. After using CI for a little while, I recently stumbled across the gem that is Templating. There are some extensive documentation on template usage in CI, but here’s one or two to get you going! :)


	class Template_Test extends Controller {
		function __construct() {
			parent::Controller();
		}
 
		public function index() {
			$template = $this->common->getTemplate();
			$template["message"] = "";
			if($this->input->post('alert')) {
				$template["message"] = $this->load->view('index_alert');
			}
			else if($this->input->post('notify')) {
				$template["message"] = $this->load->view('index_notify');
			}
			$this->parser->parse('temp_index',$template);
		}
	}
 
/* End of file: template_test.php */
/* Location: ./system/application/controllers */

Then create the views…


<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
		<meta http-equiv="Charset" content="utf-8" />
		<meta name="author" content="{board_vendor_name} Development Team" />
		<meta name="language" content="en" />
		<meta http-equiv="Accept-Encoding" content="gzip,deflate" />
		<meta http-equiv="Content-Encoding" content="gzip" />
		<meta http-equiv="X-UA-Compatible" content="chrome=1" />
		<title>Template Test</title>
	</head>
 
	<body>
		{message}
		<p>This is some sample text</p>
		<form method="post" action="">
		<input type="submit" name="alert" value="alert"><br/>
		<input type="submit" name="notify" value="notify"><br/>
	</body>
</html>

Pay special note to the {message} part. :)

Now two other views, one called index_notify.php and the other called index_alert.php..

<div style="background-color:rgb(20,100,30);color:rgb(255,255,255);">
	<p><strong>NOTIFY TEST!</strong></p>
</div>

<div style="background-color:rgb(100,20,30);color:rgb(255,255,255)">
	<p><strong>ALERT TEST!</strong></p>
</div>

Test the script and see the results! I admit this is all ugly as hell, and basic as a shack made of newspapers, but you can at least see how it works. Now, go forth and play with templating!

CodeIgniter – A quick introduction

dade- — Wed, 24 Feb 2010 17:07:05 +0000

CodeIgniter and Doctrine combined

Creating a Table

Here’s a quick bit of code to create some tables with CI/Doctrine. I’ll assume at this point that you have CI set up to point to your database and such. If not, you will need to go to the system/applications/config/database.php file and change the settings there.

This is the model.. so create user.php in your models folder of codeigniter. This is using doctrine too, so please read the documentation on integrating doctrine to codeigniter before proceeding.


 
  class User extends Doctrine_Record {
    public function setTableDefinition() {
      $this->hasColumn('username','string',225,array('unique'=>'true'));
      $this->hasColumn('password','string',225);
      $this->hasColumn('email','string',225,array('unique'=>'true'));
    }
 
    public function setUp() {
      $this->actAs('Timestampable');
      $this->setTableName('user');
      // this is where the magic begins...
      $this->hasMutator('password','_hash');
    }
 
    protected function _hash($pw) {
      $salt = md5('randomstring'); // this can be a simple string. i prefer to md5 it.
      $this->_set('password',md5('__'.$salt.'~1337#'.md5($pw).'!'));
    }
  }
 
/* End of file: user.php */
/* Location: /system/applications/models */

Let’s review the code. First we have the class declaration. This creates a class called User. With CodeIgniter you would normally extend Model, but in this case because we’re using Doctrine we have to extend Doctrine_Record (much like active record, for those familiar with it.) Then we create the setTableDefinition() method, which gives the database the necessary column data. $this->hasColumn(name,type,options={}); where name is the column name, type is the column type (eg. whether it’s a text column, clob, integer, and so on.) Refer to the Doctrine documentation for more information on data types. Lastly we have options, which include things like unique, default, and so on.

Fairly simple to grasp, wouldn’t you say?

Now, the next method is the setUp(), which does the setting up of our database table to input the columns. actAs(‘Timestampable’); creates two fields called ‘created_at’ and ‘updated_at’. setTableName(name) should be obvious – it’s the name of our table. In this case, user. Then the magic. Mutators. hasMutator(column,mutator) means you can set a column name and apply a block of code to it. In this case we’re creating a password hashing system, so our mutator is called _hashpw.

We then define a protected function to the model to actually carry out the hash. This is so that the form doesn’t just input a user’s password and store it as-is on the server. Big no-no on the security front right there. Anyway, let’s move on quickly and review what the hashing actually does.

$salt – this variable acts as our condiment to the hashing. It can be a string you define, or as I have done you can run an md5 encryption on a random string for added oomph. It’s really not necessary, but I like to be safe than sorry. This then becomes a complicated string that we can use later.
$this->_set(column,string) – sets our column ‘password’ with a string, which may seem complicated at first, but really it’s not. First I like to create an opening string, then attach the salt, then a middle string to bridge the md5($pw) and then an ending string.

Let’s imagine for a moment that our final $salt = md5(’string’) comes to ‘WTFPWN’ and our md5($pw) becomes ‘WTFBBQ’, our final string will be something like…
“__WTFPWN~1337#WTFBBQ!” Simple. :)

Now our controller to create the tables. Here we go!

db_tools.php…


 
  class Db_Tools extends Controller {
    public function index() {
      echo 'Database Tools
      
      

      

';
 
      if($this->input->post('cr_usrTab') {
        Doctrine::createTablesFromModels();
        echo 'Database tables created.';
      }
      if($this->input->post('cr_admUsr') [
        $data = array('username'=>'admin','password'=>'password','email'=>'admin@baseurl.com');
        $adm = new User();
        $adm->fromArray($data);
        $adm->save();
        echo 'Admin user created.';
      }
    }
  }
 
/* End of file: db_tools.php */
/* Location: /system/applications/controllers */

This bit is magic, and I love it. Firstly we create a controller as normal and populate it with a simple index() method which fires when you navigate to http://localhost/index.php/db_tools/ – and all the index is to begin with is an echo of a h2 title, and a form with two submit buttons; one to create the tables in your db, and another to populate the table with an admin user.

Note the submit button names are the same as the if statements. $this->input->post(name) gets the submit/post name you just clicked. If it relates to what it governs, the script will fire. Again, really simple stuff.

Doctrine::createTablesFromModels(); – a magical line of code that says “I want to create tables, so I will look for ALL files in the models folder that extends the Doctrine_Record class and run the operations listed in each one to create the tables.” Truly a time-saving line of code for working with larger projects with multiple Doctrine_Record models. Then we echo that the database has been created.

The admin user creation is also a very simple idea. Firstly we create an array called $data, and within this array we have the column => value as you can see. Then we assign the a new class User() to $adm and then we can extend from that. $adm->fromArray(arr_name) takes all the values in the above array and populates them into the User class, then we simply save() it and echo that this has completed successfully.

Navigate to http://localhost/index.php/db_tools/ and test it. Any error messages will be very clear as to what the problem is. If you have problems you can always shout me though. Have a crack at it and see what you can do. :) Remember, the documentation of these systems are your very best friends.

The Continuing PHP Saga…

dade- — Tue, 09 Feb 2010 22:05:51 +0000

Upon starting my social network engine in pure PHP, I quickly abandonned it for CodeIgniter, which then fast become CodeIgniter & Doctrine. I have to say, I’m less suicidal when it comes to PHP now and this is a good thing, since PHP is the easiest language for ease of edit, access, and collaboration – cos I’m not going to teach others how to use Ruby on Rails when they have no grounding knowledge in that but do in PHP… so here goes.

What is PHP & Doctrine? Well, Doctrine is a tasty PHP5 ORM that works quite nicely with CI, and CI is a tasty little MVC framework for PHP. All in all, it’s tasty. We’ll see how things go from here.

As a side note, for those starting out in development of such projects should check out wampserver.com and download wamp for windows. It quickly and easily installs and runs an Apache webserver, MySQL server, and slaps PHP on there for you too. Not bad, I’d say.

PHP – Why!?

dade- — Sat, 23 Jan 2010 12:27:28 +0000

Having recently picked up a project that was side-lined for a while I’ve come to the realisation that PHP is not a language I like, and I’m as rusty as hell with it. The project is a community engine for achievements. I won’t go into great deal just yet, but it requires a forum, a facebook-like functionality but without the crap that unfortunately the community have added to it, and a lot of code.

I’ve opted to do this from scratch, as I’m not really satisfied with the other community engines out there for PHP. As a result, I’ve run into the problem of work load. It’s a big project and one that I’m passionate about, but the lack of will to live whilst using PHP is one that bothers me.

I over exaggerate a little. It’s not as bad as I make out, this PHP lark, but I feel that there are better engines out there for achieving this type of project in a lot shorter space of time. I’m going to create this site/community on 2 or 3 different languages/frameworks. First will be pure and plain PHP, the next will be the CodeIgniter framework for PHP, and lastly Ruby on Rails. This means a bit more work than before, but in actual fact the hardest part of it all is the planning. Once I have the site running under one system, it’ll be easy enough to implement it into others.

Still, it’s a big job and nowhere near off the ground in terms of the code side. The ideas and planning has been there some time. We’ll see how it goes.

For the time being, I’m going to be cheeky and ask for all the PHP nuts out there that I know to give me a shout if they’re interested in giving me some pointers and helping with the intricacies of PHP programming.

Rubyists also wanted for much the same. I cannot offer pay, but you will get my e-kudos; and that, my friends, is invaluable. <3

Thanks in advance!

Dragon Age Modding – Area Tutorial

dade- — Sat, 05 Dec 2009 23:25:03 +0000

Apparently there was some mixed up information so my section on how to assign Module and Module Owner is a little wrong. For this tutorial, they should both be the module name (ie. tutorial). Sorry for the mix-up. I will re-write this article when I have some more time to cut down on the wall of text into a more concise explanation.

dade-

Welcome to the first instalment of my Dragon Age tutorials. I will assume that you’ve looked at the toolset already and have a basic understanding of how the viewports work and how to navigate (mainly for this mod) the terrain window; such as camera panning, rotation, and so on. If not, I suggest you have a play around, though be careful not to create/save anything into the Single Player campaign as problems can occur this way.

Firstly, you want to create a tutorial module. To do this, go to File > Manage Modules. This will bring up a window much like the image below.

A list of modules, both core and custom created.

As you can see, this lists all the modules that are stored on the local machine, from the default to the custom created. Core, Demo, and Single Player are all default with the game. These you should leave well alone, and instead you want to create a new module.

When you create a new module, you’ll be greeted with the following window:

Creating a new module

The fields you need to focus on for the purposes of this tutorial are Name and UID. Name is, obviously, the name of your module. This can be anything you like, and can contain spaces. UID is the module’s Unique Identifier. I’ve yet to find where this is referenced, but for the sake of module “best practices” I would give this a unique and descriptive name. For this tutorial, you can simply put tutorial into both fields.

OK that and then highlight and Open your newly created module. The first time the module is loaded after creation you may find that it takes a little time to respond. Be patient, and when it’s fully loaded you will have a completely blank module to play with. Go ahead and create a new Area. Do this by going to File > New > Area. This will open up a window like so…

Creating a new area

Resource Name should be the name of your area. It is a good idea that for each module you create, you specify and stick to a naming convention for assets that you create, such as Areas, Monsters and so on. For this I will say use “tut_” as a prefix. Go ahead and call your map tut_flemhut_ext.

Folder is the location your area will be saved once created. If you look on the Palette Window on the right of the screen (enabled by default) you will see a folder tree view. Leaving Folder as / will create your area in the root of the Area tab. I’d suggest not putting your custom content in the root as this can get extremely confusing for larger mods later on. Go ahead and put /Tutorials in there.

Module is the module that you are creating the asset for. In this case, you should leave it as tutorial, or whatever you’ve called the module for this tutorial.

Owner Module confused me at first, but upon further reading I’ve discovered that this is specifying which module should be able to access the asset. I’ve set this to Core Game Resources. Anything that we set to be owned by “CGR” can be accessed by any other module. Obviously if you only want the asset accessible in a specific module, you will want to set this option accordingly.

Leave State as NONE and leave the tickbox as it is. This option literally acts like when you finish installing a program and tell the installer to “Run program when installer exits”. A quick explanation about checking in and out resources. When working on a mod with several people who are scooting about left and right modifying different files here and there, you will get to a point where your modifications to one object conflicts with another developer in your team. To counter this problem, the toolset has a Check In and Check Out feature. When a file is checked it creates a local copy of the file for that developer to chop and change and do what is needed on their part; for instance a programmer adds his/her script to a monster while another developer adds some armour and changes the appearance of that monster. When these two finish with their task, they Check In which merges their changes with the master copy saved on the module. Both of the changes are seen, and the monster now has scripts and some items and a new look with the least bit of hassle for either developer. :)

If you have multiple developers working on a single module, you can view the history of check ins/outs by going to View > Resource History. Notes are recommended when checking in resources so that others can see what it was you changed. Not essential, but it’s good to get into the habit of it.

NOTE: If you are familiar with using Git and/or GitHub you may be familiar with the way this kind of collaborative development works. It is essentially the same.

So now you have a blank area… what to do with it!? Well, you want to make sure the area is open so that you can see some of its meta data in the Object Inspector (enabled by default) in the bottom right of the window. You will see a whole list of variables and (possibly) confusing settings…

Area Layout lets you load a pre-made Level. Click in the input box on yours and then the “Triple Dot” button that appears. This will open up a list of the game’s areas that you have been walking around in the single player campaign. Load up ost101d which is Flemeth’s Hut Exterior.

Name can be anything you wish, though something relevant would be ideal.

The last important thing we need on this is Resource Name. You will notice in the above picture it is called dbare_flemhut_ext. Swap the dbare_ with tut_.

You will notice whilst editing that Object Inspector that a map has loaded. As a default the camera will be faced down at the exact centre of the area. Navigate North a little and rotate the camera so that you can see Flemeth’s hut front. Right click the ground and place a waypoint, then another. These will be our spawn locations, but before we start editing the finer points of transitions we’ll create/place everything that’s needed.

You will see on the front of Flemeth’s hut that there’s a little niche where a door should be. Now here comes the magic from BioWare, and one of the hundreds of reasons why I love this engine. Open up Placeables (Palette Window, Table icon) and select the Area Transitions > genip_at_normal and place it just in front of Flemeth’s hut. You will notice that there is a blue ball on the side of the door, which is the reference point for doorways. It’s magic, I tells ya!! Drag the ball on the door to near the one on the door frame and let go.

BOOM! No need to faff about aligning and re-aligning. The engine knows which way the door should sit, and whether or not it’s rotated the right way. Anyway, now that the excitement’s over and we have our first area kitted out with waypoints and a door, we want to create another area. Follow the steps as before, but call it “_int” for interior, and load the Area Layout called ost102d. This is Flemeth’s hut interior, as seen in the campaign.

Go ahead and add a door to the interior, and place a single waypoint here. Rotate and move your waypoints so that you have something along the lines of…

tut_flemhut_ext layout

And the interior should look like…

tut_flemhut_int layout

Select the left-hand waypoint in our exterior and go to its Object Inspector. The waypoint’s inspector looks like this:

Tag is important here

As the caption says, Tag is the important field here. This one we will call mod_start. This will be the point where we initially spawn upon loading our mod. You may specify a name if you wish. I would personally advise you do so, even if to fully explain the tag; for instance with our mod_start waypoint we could give the name a value of Module Starting Location or something similar.

Our second exterior waypoint will act as our transition anchor. This will become clear soon. This one I named wpt_flemhut_ext. Now open the Object Inspector for our door, which will look like this:

Settings for our area transition

Everything for this door can be left as default, even the Tag of the door; however, for larger scale mods I would advise change these tags too… less confusion when you try to debug and need to find a single door in a city area. ;) For simplicity’s sake, set the tag to atdr_flemhut_ext.

Note: In the next tutorial I will be going over custom area transitions. :)

One last thing with our door transition is to set its variables. In the Object Inspector window, click on the “Open” button (triple dot) to get this:

The variables for a certain resource, in this case, a transition.

Sort the Name column so that you have PLC_AT_DEST_AREA_TAG which is the area tag of our destination. Seeing as this is our exterior door, we want to point this to the interior, which should be tut_flemhut_int and set the PLC_AT_DEST_TAG as wpt_flemhut_int.

That should be it for the interior. OK that window and switch to our interior. Again, we want to name our waypoint and set the transition of the door. The interior waypoint has to be the same as the exterior door’s variable PLC_AT_DEST_TAG, which in our case is wpt_flemhut_int. Now change the interior door’s variables to point to the waypoint outside.

PLC_AT_DEST_AREA_TAG = tut_flemhut_ext
PLC_AT_DEST_TAG = wpt_flemhut_ext

I hope that made sense. Basically you need to point the object to its opposite side, which is where naming becomes essential to save time and headaches.

Right! Almost done. The last thing we need to do is save and then “Check In” both the areas we’ve created. The easiest way to do this is to right-click the tab in the main view port and then click Check In. You will see that the resource you’re trying to check in is highlighted, and there is a comment box below. I normally put something like this:

Initial check in/commit - basic info about what was done

Repeat this with both areas, and once done you want to go to File > Manage Modules again and under Starting Area select our exterior map, then set the Starting Waypoint to our mod_start. OK that, select Open on our Module again, and finally we’re ready for the export and test. :D

Go to Tools > Export > Export with dependent resources. Give this some time, as it can take a moment or two to export all the necessary files. Once done, we want to do two more exports, but this time we want Tools > Export > Export Module XML and Tools > Export > Export Manifest XML.

Once all these steps are done, open up the game and (hopefully) the newly created mod will be filed under Other Campaigns on the main menu. :)

NOTE: If whilst testing you find that you spawn outside the map, or do not spawn at all, check that the transition door are named and pointing to their corresponding waypoints. Also, if you placed a waypoint on uneven ground, you want to lift it just a fraction so that it doesn’t go through the floor. If you are still having problems, leave a comment and I’ll try to answer your queries.

OFP:DR LUA Tutorial 1

dade- — Sat, 24 Oct 2009 12:52:51 +0000

:edit – 12 Nov 09: I’ve rewritten the lua scripts for this mission and will now share it with you. I will assume you know how to create a simple mission and set up the entities in the map panel. If not, please refer to one of the many tutorials on the OFP:DR mission editor forums.

First thing’s first, you need to create your playing field and set up your entities. You will need the following:

- 3 vehicles (destructible ones)
- 1 level script
- 1 mission objective
- 1 fireteam

You will need to set up your Mission Objective marker and set the objective text and everything like that, then you want to select the Fireteam’s echelon and Jump to a character within the fireteam. Set control mode to “player” and leave the rest as AI or multiplayer. Whichever you wish. Rename the trucks to truck1, truck2, and truck3 (this is just for ease of naming, you can do whatever names you want). Once everything is set up you want to enter the following code to the level.lua panel:

-- onMissionStart().. place everything you want to initialise at the BEGINNING of the mission here..
-- such as setting up primary start objectives like "rendezvous with such and such"
function onMissionStart()
	OFP:setObjectiveState("trucks", "IN_PROGRESS") -- sets objective "trucks" to in prog. makes sense..
	OFP:setObjectiveMarkerVisibility("trucks", true) -- trucks objective marker set to visible
	tP = 0; -- sets variable tP to 0 - more on this soon
end
 
-- custom method, not built into OFP:DR API
-- what it does...
-- when progressCheck() is run
-- if value of tP is 3 then set objective "trucks" to complete
function progressCheck()
	if tP == 3 then
		OFP:setObjectiveState("trucks", "COMPLETED");
	end
end
 
-- the onDeath method can be used in two ways
-- either onDeath_truck1() etc etc and create new blocks for each entity on the kill list.. OR!
-- create an array/table of victims and place everything into a single block statement
function onDeath(victim, killer)
	victim = {truck1, truck2, truck3} -- sets array with all three kill targets' entity names
	tP = tP + 1; -- each time a victim in the above list is killed tP is incremented
	OFP:displaySystemMessage(tP.."/3 trucks destroyed"); -- display console message "value of tP" out of 3 destroyed...
	progressCheck() -- run the block we created above, so when tP increments to a value of 3 (when all are dead) the mission completes.
end
-- easy stuff, eh!?

My map screen looks like this, and my code is as above….

Desktop UI

dade- — Tue, 28 Jul 2009 10:50:13 +0000

Okay, so without going into much detail about this, I’m design a desktop UI for an OS. It’s not going to be used as an OS, but I want it to feel like one. So, for instance, when you open a browser page it gives some ‘pseudo-internet’ pages. Like a spoof OS, if you like.

What I want is some input from anyone that reads this blog. Ideas are welcome for features, look, animation, etc.

Blogging in the car

dade- — Sat, 21 Mar 2009 20:24:56 +0000

Just been to the Apple Store’s Genius Bar with my mate Phil to replace his iPhone. The strangest thing… the girl that was serving us saw Phil’s email address (@deadbadger.org) and commented on how he came up with the name, which pointed the finger at me for setting up the site.

Well anyway, conversations led to a bit of Badger Trivia. Apparently if you hit a badger with your car, you have to report it to the police because they’re protected or something. The enemy are well entrenched in the government now! This is a bad day for the Anti-Badger Coalition! Men! To arms!

Samsung NC10 :: A New Toy

dade- — Tue, 10 Mar 2009 01:08:53 +0000

Yes, I went and did something I didn’t think I would ever have done. I bought myself a netbook – a bloody Samsung one at that.

While I’m no fan of Netbooks due to their size and power, I have to say that I’m pleasantly surprised by this one. It’s fast, very fast, and can load up Windows XP in a matter of seconds, as opposed to Vista’s minutes. Added to this, it has a fully fledged SATA-II hard disk drive in it, which other models of the same variety do not – they have tiny little flash drives. Dirty flash drives.

The NC10 is not the smallest of netbooks, strutting into the ring with a 10″ widescreen display running at 1024 x 600 resolution, and weighs in at roughly 1.5kg. Not bad, I say.

There is a built on webcam, the keys are 17.7mm wide, which makes for decent fast paced typing. What every geek does!

The power consumption on this beast is very efficient too, though I haven’t fully tested this yet as I’ve only just recently got it and it needs to go through my rigorous cycle of battery prepping.

Anyway, it’s a bloody nice laptop! I’m proper chuffed about it.

Blogging from my phone

dade- — Thu, 05 Mar 2009 18:05:25 +0000

I’m such a geek, but it means I can do this stuff while on the road or at a place without internet connection! Good fun