Diablo 3 Website Launched
June 28, 2008 | Leave a Comment
The exciting news of Diablo III was confirmed to the world this morning when Blizzard unveiled it in its week-long splash screen! Shortly after my previous post on the topic, the Diablo III website was launched too! The site, as is typical with Blizzard sites, is gorgeous…here’s some info that was gleaned.
Storyline
It has been twenty years since the events of Diablo II. Of those who faced the Lords of Hatred, Terror, and Destruction in the battle over the fate of Sanctuary, there are few still living who can bear to remember the horrors that the Prime Evils wrought upon the world. And of those who did not witness the terrible events firsthand, most believe the stories to be little more than myth. But something evil is stirring once again in Tristram, and it may already have claimed its first victim: Deckard Cain.
Character Classes
There will be 5 character classes in Diablo III and classes can be either male OR female.
The Barbarian
This old favorite is back! See the Barbarian page. Some skills that are definitely returning are: Cleave, Ground Stomp, Leap, and Whirlwind! Check the barbarian page for videos on these moves!
The Witch Doctor
Here’s the newbie! This guy seems pretty freaking sweet. Check the Witch Doctor page for more information. This class will feature spells such as: Firebomb, Horrify, Locust Swarm, Mass Confusion, and Soul Harvest.”
Video
Currently on the Diablo III site there are two trailers. Cinematic and Gameplay. I can’t find any version of the two in decent quality yet so I’ll have to post those puppies later. In the mean time, check the videos out on the Diablo III site!
Release Date
As with any Blizzard game during announcements…there is no release date announced. Meh. But that’s why we love it. They polish a game until it glistens beyond compare and THEN deliver it to the world. I just wish they’d wait to announce things until a day before it is released so I don’t have to drool for years on end :P
Diablo 3 Officially Announced!
June 28, 2008 | 1 Comment
Blizzard has had a splash screen that changed daily for the past 5 days, today was its final day and I was extremely surprised to see that it revealed what has long been rumored…Diablo 3! This is exciting news!
The graphical announcement looks freaking awesome and I look forward to the link on the announcement to actually go to the Diablo site rather than a broken page! w000000t!
Compiling Invalid Objects in PL/SQL
June 25, 2008 | 4 Comments
While I do a lot of and prefer PHP and JavaScript development, my daily job has a darker side...PL/SQL. At times the packages that I oversee invalidate during upgrades or poor compilations of a package that ends up having a ripple effect.
Here's a query I wrote to find the invalid objects and generate compile statements to attempt to fix whatever is busted.
-
SELECT CASE object_type
-
WHEN 'PACKAGE' THEN
-
'ALTER '||object_type||' '||owner||'.'||object_name||' COMPILE;'
-
ELSE
-
'ALTER PACKAGE '||owner||'.'||object_name||' COMPILE BODY;'
-
END
-
FROM dba_objects
-
WHERE STATUS = 'INVALID'
-
AND object_type IN ('PACKAGE','PACKAGE BODY','FUNCTION','PROCEDURE');
Quest Software: Active Directory Recovery Video
June 20, 2008 | 3 Comments
While frittering our lives away on the internet, my friend Dan and I stumbled upon an ad by Quest Software that featured 3 dudes in funny outfits. We had to click...and this is what we found:
Dan tried to escape this Active Directory Recovery ad a few times but I made him stay...The masked guy at the end doing the robot made it all worth it.
Funny stuff :) Kudos to Quest Software!
D&D 4th Edition NPCs: Minions
June 14, 2008 | 2 Comments
I received my Dungeons and Dragons 4th Edition books on Monday and have been reading over them throughout the week. Because of the difference in rules from versions 3.5 to 4, I plan on covering a number of topics related to some of the new features of 4th Edition.
Minion NPCs happen to be the topic of this post.
So, I was reading through the Wizards forums and came upon a thread relating to the confusion with Minion NPCs in combat and how to explain their really weak stats. One of the questions that was posed asked how it made sense to have a level 14 Minion Cyclops that could feasibly drop in one hit while its fellow level 14 Standard Cyclops could withstand a much heavier beating.
One sage of a user, Morholdt, had this response which I buy in to totally:
Using that understanding of hit points, one can see that minions are not puny versions of the monsters, but they are versions with no karma. They are the marathon runner who twists his ankle after the first mile. That orc minion can kill you almost as easily as the normal orc, but when you stab him with your spear, his luck runs out and he dodges the wrong way.
Personally I love minions. I've always found it a little lame to go into a goblin village which is populated by 12 goblins, or a dungeon where the monsters never leave their rooms and swarm the adventurers because any more would make it too hard.
With minions you can have truly epic battles against foes that can actually threaten you and live to tell the heroic tale.
So...that level 14 Minion Cyclops that I talked about earlier isn't necessarily a slim, diminutive one-eyed brute that walks around with his fellow level 14 Standard Cyclops that his a hulking monstrosity with bulging biceps and a club that could fell an elephant in a single blow. Nope. The minion is the same as the level 14 Standard Cyclops...the Minion just makes a few mistakes on the battlefield that cause him his life much sooner.
If you haven't read the Dungeon Master's Guide for 4th Edition and don't know what a "Minion" is, then here's an excerpt on them from the DMG:
A Minion is destroyed when it takes any amount of damage.
I know...any amount of damage doesn't seem overly scary. However, each minion causes damage similar to a standard NPC of its type and level. Just because they fall quickly doesn't make them easy to hit or prevent them from hitting you!
The Minion role in a combat encounter is one sexy addition to 4th Edition that will make for a much richer game!
Luminis: Forcing CSS/JavaScript Updates to Clients
June 2, 2008 | 1 Comment
Contents:
Introduction
I gave a talk at SunGard Summit in Anaheim this spring on Plymouth State's portal (myPlymouth). There were a number of really great questions that came up following my presentation, one of which is the topic of this post:
When upgrading Plymouth State's Luminis installation from III to IV, we had to tackle this same issue and after banging my head against the wall a number of times, I found our answer. I wanted to:
- Ensure that the JavaScript and CSS that is being served up to our users can be cached by their browser in order to optimize their download speeds.
- Control when a user's browser has to re-download a new version of the code.
- Do the above within the bounds of the very restrictive caching provided by the Luminis product.
All of it was super easy to do, although I must admit I knocked my head against the wall a few times coming up with the solution to the 3rd in that list.
Step 1: Basic Browser Caching
When I sat down to tackle this problem, I knew that the inline JavaScript within nested_tables.xsl was an unforgiving issue - if I wanted to make a change to some of the inline JavaScript, those changes would not be forced upon the users until Luminis decided to let go of its cached nested_tables.xsl.
That didn't work for me. So I ripped the inline styles out and combined a few JavaScript files into one...called combined.js.
My header within the regularLayout template in nested_tables.xslnow looked something like this:
-
<head .......>
-
<title>.........</title>
-
<script type="text/javascript" src="/js/clientsniffer.js"></script>
-
<script type="text/javascript" src="/js/util.js"></script>
-
<script type="text/javascript" src="/psu/js/combined.js"></script>
-
<script type="text/javascript" src="/psu/js/behavior.js"></script>
-
<link rel="stylesheet" type="text/css" href="/psu/style.css"/>
-
</head>
The files clientsniffer.js and util.js are SunGard delivered and I did not touch those two. As I mentioned before, I yanked out all the inline JavaScript (provided by SunGard) and dropped that into combined.js along with a number of jQuery code. Our own custom Luminis JavaScript that controls a lot of our Ajax-like functionality in myPlymouth is in behavior.js. And of course, style.css holds the CSS for our portal.
All of these files could now be cached by users' browsers. Yay. I bounced the development portal and saw my changes in all their glory. Life was good.
Step 2: Browser Cache, Code Changes, and You
Invigorated by my recent success of effectively doing nothing, I grabbed a soda and began tackling the next objective. I had done this numerous times in my PHP applications and it was as simple as placing a version number at the end of the URLs used in the link and script tags. As such:
-
<head .......>
-
<title>.........</title>
-
<script type="text/javascript" src="/js/clientsniffer.js"></script>
-
<script type="text/javascript" src="/js/util.js"></script>
-
<script type="text/javascript" src="/psu/js/combined.js?v=1.0.0"></script>
-
<script type="text/javascript" src="/psu/js/behavior.js?v=1.0.5"></script>
-
<link rel="stylesheet" type="text/css" href="/psu/style.css?v=1.0.5"/>
-
</head>
Once again, I bounced our portal, saw the changes, and danced around the room. Step 2. Accomplished.
Step 3: Taming Versioning/Cache Expiration in Luminis
The goal of taming this versioning/cache expiration was to do so without the need for bouncing the portal so I could make changes on the fly without planning for down times. Step 2 - as I detailed above - only gets you so far. With Step 2 in place, I could easily make a change in my CSS file and edit nested_tables.xsl to one-up my version number. But, because nested_tables is cached by Luminis, that wasn't good enough. Here's what I came up with:
I removed the script and link tags in the header of the regularLayout template in nested_tables, created a file called load.js, and dropped the homeless script/link tags as document.writes in load.js...as so:
Start of a Solution: load.js
-
document.write('<script type="text/javascript" src="/js/clientsniffer.js"></script>');
-
document.write('<script type="text/javascript" src="/js/util.js"></script>');
-
document.write('<script type="text/javascript" src="/psu/js/combined.js?v=1.0.0"></script>');
-
document.write('<script type="text/javascript" src="/psu/js/behavior.js?v=1.0.5"></script>');
-
document.write('<link rel="stylesheet" type="text/css" href="/psu/style.css?v=1.0.5"/>');
But wait...
This gave me a file with all of my script/link tags and their appropriate versions. However...I couldn't simply replace all those script/link tags with a script tag that pointed at load.js because load.js itself would be cached by users' browsers. So this got past the Luminis caching, but not our end users. So I came up with this:
Final Solution: pre_load.js
So...I wanted to cache all my sub-files and prevent load.js from caching so that I could version my scripts easily without bouncing the portal. The solution? Yet another file! I called it pre_load.js and it looks something like this:
-
document.write('<script type="text/javascript" src="/psu/js/load.js?nocache=' + (new Date()).getTime() + '"></script>');
A simple document.write of a script tag with an appended variable based on time in order to prevent caching on the browser side. Yup...load.js is never cached, but it is a small price to pay.
Now my header in the regularLayout template in nested_tables.xsl looks like this:
How it works
- Luminis happily caches the pre_load.js script tag in the nested_tables.xsl.
- The JavaScript within pre_load.js writes another script tag to the document at render time. That script's URL is a call to load.js along with a variable that changes each page load thus preventing load.js from being cached.
- load.js then document.writes the appropriately versioned script/link tags into the document.
- The individual script/link tags load the associated JavaScript/CSS files. If the browser has already cached that script/link URL (remember, we change the version numbers when we make changes to the JS or CSS), then the cached file is loaded...otherwise the new version is retrieved from the server.
Summary
The set-up is fairly basic but the results just what we were hoping! And all it took was:
- Placing inline JavaScript into a file (combined.js)
- Creating load.js to document.write script/link tags
- Creating pre_load.js to document.write a script tag that uses a cache-free URL call to load.js
To date, we have not had any reported issues with local or server-side caching of our JS/CSS files using this method! You just need to make sure you remember to version your URLs in load.js!
