• November 2008
    M T W T F S S
    « Sep   Jul »
     12
    3456789
    10111213141516
    17181920212223
    24252627282930

Message to Mythic

Below is a post I made on the VN boards in regards to what players want in regards to keeps in Warhammer Online:

Everyone knows that there is currently no incentive to defend a keep or BO right now, other than trying to cap a zone. However, capping a zone is such an involved, and seemingly random thing that this currently does not qualify as an incentive in my opinion. People play this game to RvR, but they also play the game to advance and experience the end game. Put simply, advancement is made by capping zones. The oRvR experience and the VP system are deeply interconnected within the player experience, and I think that this interconnectness needs to be exploited by Mythic to produce a potentially awesome gaming experience.

We need incentive to defend keeps, and I think that incentive should be focused on the VP system. Such a solution could also solve another problem with Warhammer: the VP system currently does not appeal to players. This system in its current, seemingly obscure and random form, is just not tangible to us. Right now, the only realistic way to cap a zone is to win scenarios. When enough VP’s are accumulated from winning scenarios, we quickly take the keeps and hope we have enough VP’s to cap when we are done. This “rush” to take keeps in a zone does not create keep defense. There is also currently no reason to defend a keep unless you are really close to capping a zone from winning scenarios. So, Mythic should shift the focus from scenario wins, to success in oRvR to solve both problems in one blow. The system of static VP’s from keeps and maybe BO’s has to go.

Here are a couple of ideas that could be applied, perhaps with some modifications (the VP system is very complex, and I am far from understanding its complexities). Neither of the two ideas are original, but within this context they could work to help make this game really great:

Idea #1: If a keep is captured by a realm, and/or possibly only when claimed by a guild, it will slowly trickle in VP’s for that realm. When a keep is taken back by the enemy realm, those VP’s are lost, including the accumulated VP’s (or maybe VP decay would take care of this, but only after a certain amount of time has passed.). So, if a realm can hold a zone for a reasonable time length (maybe 2 days for example), then it should have a higher chance of capping the zone, depending on how well the realm is doing in scenarios. Winning scenarios would still be a factor, but less of one.

Idea #2: Instead of Idea #1, capturing all of the keeps and/or BO’s could result in VP decay being halted. Currently, VP decay is set in place to balance against a sweep of (perhaps lucky) scenario wins, which is good in theory, but from experience it can also be very demoralizing when you’ve worked with your entire realm to cap a zone, and there just aren’t enough quick, back-to-back scenario wins to do it. Perhaps the VP decay system itself needs to be redone, but in the meantime this idea would give a realm incentive to defend taken keeps/BO’s if defending will help cap the zone.

These are not the only ideas that could work. The important thing that I would like to communicate to Mythic as a player who loves this game, but wants it to improve is that they should use the inherited interest of players to cap a zone and advance the game, to increase keep defense and game play in oRvR. This is what the player base wants, and I think Mythic could easily give it to us. Being successful in oRvR should lead to being successful in pushing or defending zones.

Thank you,
BB

Naming Computers and LANDesk OSD

LANDesk puts out a technical paper on how to accomplish Hardware Independent Imaging with its Management Suite.  If you don’t know what HII is, basically it is the process of creating a single image or imaging task that will work regardless of your hardware.  LANDesk’s tools plus Sysprep create a very easy to maintain HII imaging solution.  However, I wanted to add a little piece of of my own to this mix.

We have a newly implemented naming convention here at CSN.  This was very thoroughly thought out by many people, but more or less the naming convention identifies a computer’s location, and its asset tag number.  With the documentation on HII that LANDesk provides, a computer must be named properly in the LANDesk database, or named after the imaging task has finished.  Since our computers move from one location to another quite often, and renaming computers in the LANDesk database is not easy, I created a way for technicians to name the computer before the imaging process begins.  Once named, the computer images, and reboots into Sysprep where it joins the domain and installs all of its device drivers.  Wonderful!

Now, if you are not familiar with LANDesk, a lot of this won’t make sense.  Basically, LANDesk OSD scripts are a text file which you can alter to your liking much like any other scripting method.  Now, to get started with adding dynamic renaming to the script, I enter the following command into the LANDesk OSD script in the part just before the imaging command is executed:

REMEXEC259=sdclient /f /o /dest="X:\ldclient\pcname.vbs" /p="http://server/PC_Rename/pcname.vbs", STATUS

SDCLIENT.EXE is the swiss army knife utility of LANDesk.  It does lots of stuff.  Here it just copies a file from an HTTP share onto the WinPE environment.  I then add another line right underneath the one I just created that will execute the pcname.vbs script that was just copied from a server:

REMEXEC260=cscript x:\ldclient\pcname.vbs

So, let’s take a look at the contents of the pcname.vbs file.  Keep in mind that I do have a programming educational background, but I’ve never done any vbscripting before this, so the script may not be the most elegant vbscript around:

Dim objShell
Dim getName
Dim objFSO
Dim f


Set objShell = WScript.CreateObject("WScript.Shell")
getName = InputBox("What is the computer's name? Press Cancel to rename and rejoin the Domain later.")


set objFSO = CreateObject("Scripting.FileSystemObject")
set f = objFSO.CreateTextFile("x:\\LDClient\\insertname.bat", 2)
If getName <> "" Then
f.WriteLine("tokreplw c:\sysprep\sysprep.inf COMPUTERNAME=" & getName)
Else
f.WriteLine("tokreplw C:\sysprep\sysprep.inf COMPUTERNAME=%Computer - Device Name%")
End If
f.close

So, for a rough explanation of this vbscript.  First, an input box is called, which prompts the technician to input the computer’s name.  Whatever the user enters is returned to the variable “getName”.  A batch file is created that will get executed by the LANDesk OSD script later, “insertname.bat”.  If the user enters something, then the batch file is created with a single tokreplw command containing the text as an argument to the tokrepw command.  If the user does not enter anything, or presses cancel, then the batch file gets created with the original naming command that LANDesk put into the script originally.  I’ll go into tokreplw in a later post.

I mentioned that LANDesk creates its own naming command. Let me expand on that. By default, LANDesk attempts to find the name of the computer in the LANDesk database and name the computer for us.  The line that LANDesk puts into the OSD script when you initially create the OSD task in the LANDesk Management Suite Console looks like this (note that when you create a LANDesk OSD script, you do not see the actual text of the script. Instead, the LANDesk administrator uses a GUI wizard to create the OSD script. The OSD script can be opened in a text editor by selecting the OSD task and selecting “Advanced Edit”):

REMEXEC29=tokreplw C:\sysprep\sysprep.inf COMPUTERNAME=%Computer - Device Name%

Looks very similar to the contents of our batch file, doesn’t it?  We simply remove the command for REMEXEC29, and replace it with the execution of our batch file:

REMEXEC29=cmd /c x:\ldclient\insertname.bat

Instead of the computer getting the name that LANDesk thinks it should have, the technician can specify the name that the computer actually needs to have.  Since our computers move around a lot, their names change a lot.  This is convenient for our environment.

Well, that is all for now.  If I get a moment or two, I will try to pump out a post about the mysterious tokrepw program. 🙂