Group script

Assigning something to happen when an enemy or character dies is quite common in video games. Sometimes you may want to update a journal or mission, start a conversation, provide a reward, or any number of things. I've discovered there are a number of different ways to do this.

The most common one that is used is the OnDeath script. This is a script placed in the OnDeath tag of a single object. This fires when that object dies. It works well if you only have one enemy that is going to provide an update. If you have a number of combatants and assign the OnDeath to a single one and wish to start a conversation, it can be quite clumsy. Everquest 2 and World of Warcraft use this type of update more than any others.

A Body Count variable is a better way of doing an update with multiple objects. You would assign an OnDeath script that would fire a modifier to a variable of “iBodycount”, for example. If you had five combatants, you would assign an OnDeath on all of them that would add “1” to the “iBodycount” variable on that object's death. The object that is going to give the update would have an OnHeartbeat script that looks for the “iBodycount” variable to be at least “5”. Since the OnHeartbeat scripts fire every 6 seconds, there is going to be a delay of six seconds, at the most.

I discovered another way that I much prefer for multiple objects. It is called the Grouping script.

Here is the sample Grouping script that I tested:

#include “ginc_group”

void main()

{

AddNearestwithTagToGroup(“turds”, “turd”);
GroupOnDeathBeginConversation(“turds”, “jones”, “speak1”);
}

I took two zombie templates and placed them in a zone. I gave both of them the Tag “turd”. I then placed an umber hulk template down and gave him the Tag “jones”. I made a single conversation script and called it “speak1”.

This script fires when the player crosses a trigger on the ground. When it fires, it takes all the objects with the Tag of “turd” and places them in a group called “turds”. When all the objects in the group have been killed, “jones” starts up the conversation “speak1”.

Its pretty simple to use, but you have take note of all the groups you will be using in the module so you don't reuse them. Of course, you need to be sure that the object starting the conversation is set to Static FALSE, otherwise they won't do a goddamn thing, no matter how well you script.

Couple of Useful Scripts

I've been going through some scripts from the OC in an attempt to iron-out some from faults in some of my own scripts that have not been functioning as I had hoped.

It seems that when I "ChangeToStandardFaction(STANDARD_FACTION_HOSTILE)", the mobs fail to directly attack unless they are attacked first. Going through some OC scripts, I discovered that their is no direction solution to this, other than to create a valiable that determines the player's ability to survive the attack.

Rather than trying to script OnDeath scripts for all the opponents followed by the local variable that will determine what happens when the battle is one, the OC script adds the opponents into a single group that only requires a single OnDeath script. I'm gonna play with this tomorrow and see if I can get some of these to fire properly.

Ambient Life

The project continues as always with quick pieces and slow pieces. Recently, I have been working on some slow pieces. I have decided to move on ahead a little ways with a module that I knew was going to take a long time. While the player is not set to travel here, yet, this is the direction in which they are heading.

This is another cultivated precinct. It's far more advanced and populated than the small village I started out with. Given this, I have been deeply involved in creating realistic ambient life. This seems to be my weak-point, but I'm learning quickly with it.

I would like to give credit to Jeff Husges, a designer at Obsidian, for a counsel on a commonsensical way to create a "slumbering" npc.

Bug Fixed

Well, tonight I fixed a bug that was causing the game to crash when a certain conversation was started. It was a simple fix, but it took a while I figure out what was actually causing the error. I had set the conversation to use different dialogue depending on how far along the game was. I had placed one variable, but forgot to place the second one. That would be like someone telling you, "If the door is open, clap your hands. If the door is closed." I actually discovered the bug on accident. I don't know when I would have noticed if I hadn't stumbled upon it.

Rough Night

Rough night. I have definately earned myself a beer. Very early on in the developement, I worked out an answer to a question that I had about how to get companion non-player characters to join the player. I was unsure of how to do this, because I knew that this newer engine did not use the same system as the previous one. I figured out how I was gonna do it for a single-classed character, but put off working out a system for a multi-classed character.

I decided that while I was writing the script for the latest non-player companion and had some time to fully play-test this, I was gonna work out a multi-class system. More or less, I just wanted to see if it was possible. If it was not possible, I had a “work-around” in mind that should have taken care of it from a game play stand point.

So if the player is 2^nd level and a non-player joins the group, the non-player will automatically level up to level 2. That wasn't a problem with a single-classed character. The problem, however, lied in the multi-classed. I set up a non-player to be a rogue/cleric, both 1^st level. When the non-player joined the 2^ndnd class rogue. The secondary class was completely ignored. level player, they leveled to a 2

That would pose a problem when the player joins up with a monk/blackguard/warlock later on in the game. This non-player is part of the storyline, so having all three classes is of major importance.

After playing around with a number of different options, I found the final solution to be really simple. The reason the non-player was switching to a single was because of their “Starting Package”. This is basically a blueprint of how future leveling will occur. If I simply remove the starting package, the code that planned future leveling does not fire and the initial level in classes remains untouched. The non-player is then leveled in the standard fashion.

The most amazing part about this is that the engine does not crash when it fails to find a script that it expects. That was worrying me and was the main reason I did not think of trying this earlier.

I'm so lucky

I am so glad I started backing up my work at least every 30 minutes. I was trying to load a module for a play-test and the engine crashed. My 171mb data file went to 43mb. Thats a lot of missing data. Luckily, I was able to load a previous back-up and carry on.

Weather Effects

For whatever reason, weather effects are not the easiest thing in the world to input. On the previous engine I worked with, there was a setting for “Weather Effects.” You would change Rain FALSE to Rain TRUE. Simple enough. This engine doesn't make it easy. I was able to write a script for WEATHER_TYPE_RAIN OnEnter. It makes sense, because I could create a similar script to start rain, snow, or lightning when the player reaches a certain point. It boggled me at first, but I think I can get used to that method of weather effects.