Difference between revisions of "Complex Vehicles (Savage)"

From HLKitWiki
Jump to: navigation, search
Line 165: Line 165:
 
===Refining the Entity===
 
===Refining the Entity===
  
While we now have the weapons assigned to the entity that is a child of the vehicle, we can definitely improve how it's all handled.
+
Let's return at our Zero now. We need to specify suitable text for the new "vhLoadout" field. For clarity, we'll put each weapon on a new line and indent it. This yields the following contents for the field.
  
 +
<pre>
 +
<fieldval field="vhLoadout" value="  2x 7.7mm MGs{br}  2x 20mm Cannons"/>
 +
</pre>
 +
 +
Now we'll take a look at our Zero within HL. Go to the "Gear" tab and add a vehicle. Our Zero should be listed, and it should show the load-out equipment properly. Add the Zero to the character, then check the mouse-info text for the vehicle. The display is different, since the Zero actually has '''two''' of each weapon that is listed. We need to fix this.
 +
 +
Before we continue, let's take a look at various other vehicles and their load-outs. Some weapons are re-used for different vehicles, which is great, but different ammunition quantities are specified. So we have to handle that. In addition, some vehicles simply re-use weapons and tweak them slightly. We can either implement lots of different weapons that are nearly identical or customize each weapon when it is added to the vehicle.
 +
 +
All of the adjustments can be most easily handled by customizing each weapon via the "bootstrap" element that adds it to a vehicle. Each bootstrap element can possess optional "assignval" child elements, which allow you to override the value of individual fields on the child pick. We can use "assignval" to modify the name, ammunition quantity, or any other facet of individual weapons.
 +
 +
In order to override the values of fields, those fields must be able to be overridden. This requires that a field be designated as the "derived" type. However, the majority of the fields used on weapons are "static". So we need to identify the various fields that we'll want to override and change them from "static" to "derived". After looking through the various vehicles in the core rulebook, the list of fields we need to change include: "wpPiercing", "wpFireRate", "wpShots", and "wpAmmo". Open the file "equipment.str" and modify each of these fields to the new type.
  
  

Revision as of 08:34, 12 January 2009

Context: HL KitAuthoring Examples … Savage Worlds Walk-Through 

Overview

Now that all the basics of vehicles are in place, we can look at how to support more complex vehicles, such as military vehicles with weapons. Each such vehicle needs to be managed as a user-selectable pick, plus the weapons need to be associated directly with each vehicle. We also need to handle the appropriate display of the weapons for each vehicle, which can be handled a few different ways.

Assigning Equipment to Vehicles

The biggest wrinkle posed by complex vehicles is how to define the various equipment separately (e.g. weapons) and then associate that equipment with the vehicle. Your first thought might be to use a bootstrap to associate the equipment, but that won't work. The vehicle is assigned to the character, so any things bootstrapped by the vehicle will also be assigned to the character. What we need is to treat each vehicle as its own container, into which the various equipment picks can be added.

In order to accomplish this, we must use a entity. When the entity is added to the character, it becomes a gizmo, which is a separate container. We can then add the various equipment picks into the gizmo. Entities are defined separately and then added via a thing. When the thing is added to the character as a pick, the associated entity is automatically added as a gizmo.

So our first task is to define an entity that we can use with vehicles. When we define the entity, we can automatically assign things into the entity, which will be added to every gizmo that derives from the entity. However, every vehicle is unique and there is nothing that must exist for every vehicle. We can also assign tags to every entity that will always be assigned to every derived gizmo, but we don't need any of those either.

This leaves us with an incredibly simple entity. The entity is merely a shell that will be separately customized for every vehicle. Since the entity is used to contain the various equipment possessed by each vehicle, we'll refer to it as the "load-out" for a vehicle and name it accordingly. This results in an entity definition that looks like the one below, which we can define at the bottom of the file "equipment.str".

<entity
  id="LoadOut">
  </entity>

Putting the Entity to Use

Now that we've got an entity, we need to put it to use. To demonstrate how this works, we'll define a the "A6M Zero" aircraft that is presented in the core rulebook. We start with the basic details for the vehicle, which should look like the following.

<thing
  id="vhA6MZero"
  name="A6M Zero"
  compset="Vehicle"
  description="Description goes here">
  <fieldval field="grCost" value="0"/>
  <fieldval field="vhAccel" value="20"/>
  <fieldval field="vhTopSpeed" value="140"/>
  <fieldval field="vhTough" value="12"/>
  <fieldval field="vhArmor" value="2"/>
  <fieldval field="vhCrew" value="1"/>
  <fieldval field="vhCost" value="0"/>
  <usesource source="TimeModern"/>
  <tag group="VehType" tag="Aircraft"/>
  <tag group="VehEra" tag="WWII"/>
  <tag group="thing" tag="holder_top"/>
  </thing>

The Zero has two pairs of weapons in its armament. It has two 7.7mm machine guns and two 20mm cannons. So we next need to define the two weapons appropriately. These should look like is shown below.

<thing
  id="vw77MG"
  name="7.7mm MG"
  compset="Ranged"
  description="Description goes here">
  <fieldval field="wpDamage" value="2d8+1"/>
  <fieldval field="wpShort" value="24"/>
  <fieldval field="wpMedium" value="48"/>
  <fieldval field="wpLong" value="96"/>
  <fieldval field="wpPiercing" value="2"/>
  <fieldval field="wpFireRate" value="3"/>
  <fieldval field="wpShots" value="500"/>
  <fieldval field="wpAmmo" value="7.7mm"/>
  <usesource source="TimeModern"/>
  <tag group="Equipment" tag="Natural"/>
  </thing>

<thing
  id="vw20mm"
  name="20mm Cannon"
  compset="Ranged"
  description="Description goes here">
  <fieldval field="wpDamage" value="3d8"/>
  <fieldval field="wpShort" value="50"/>
  <fieldval field="wpMedium" value="100"/>
  <fieldval field="wpLong" value="200"/>
  <fieldval field="wpPiercing" value="4"/>
  <fieldval field="wpFireRate" value="3"/>
  <fieldval field="wpShots" value="60"/>
  <fieldval field="wpAmmo" value="20mm"/>
  <usesource source="TimeModern"/>
  <tag group="Equipment" tag="Natural"/>
  <tag group="Weapon" tag="HvyWeapon"/>
  </thing>

We can now assign the load-out entity to the vehicle. Once we have the entity to contain the weapons, we can then assign the weapons into it. This is accomplished by bootstrapping the weapons into the entity, as opposed to bootstrapping them onto the vehicle. So we add the following material to our Zero, which adds the entity and then puts the two weapons into it.

<child entity="LoadOut">
  <bootstrap thing="vw77MG">
    </bootstrap>
  <bootstrap thing="vw20mm">
    </bootstrap>
  </child>

That's all there is to it. The two weapons now reside within the entity and behave as children of the vehicle itself.

Modify the Description Procedure

Let's take this opportunity to revise the "InfoVeh" procedure that synthesizes the details for each vehicle. We need to add the particulars the weapons within the gizmo. So open up the file "procedures.dat" and locate the procedure.

The first thing we need to do is differentiate between a vehicle that possesses a load-out entity and one that doesn't. Basic vehicles don't need the entity, so we don't define one for them. This means that we need to avoid trying to access a non-existent entity for vehicles that lack them. Within our script, we check if an entity exists and then bail out if we don't have one. The code should look something like the snippet below.

~if there is no child entity/gizmo, then there's nothing more to do
if (isentity = 0) then
  done
  endif

The next thing we need to do is report the basic load-out for the vehicle based on the contents of the entity. We want to identify each piece of equipment within the entity, list each along with the pertinent characteristics of the equipment. This can be achieved through the use of a "foreach" statement.

At this point, we run into an important distinction. Accessing the contents of a entity associated with a thing is very different from accessing the contents of gizmo beneath a pick. This is because the entity has not been added to the character yet, and that imposes some significant limitations on what can be accessed. We must use two completely different methods for accessing the contents of entities and gizmos, although the basic logic can be similar.

The problem we face is that the "wpNotes" field for the weapons is synthesized via an Eval script. No scripts are invoked for things, so we will have to synthesize all the information manually if we want to display it for things. In addition, we're going to run into some additional limitations associated with customizing things within the entity in just a moment. Since some weapons will be re-used with slight differences (e.g. ammunition quantities), we'll want to override the values of various fields via the bootstrap, but that information isn't accessible on the thing - only once the weapon is actually added to the gizmo as a pick. So we need to re-think our approach at this point.

Handling Display of Entities

Let's reconsider exactly what information we need to display to the user during selection of vehicles. The load-outs for each vehicle in Savage Worlds is fixed, and the number of vehicles is not exhaustive. Consequently, subtle differences between the load-outs of two vehicles is not going to be a serious consideration for players when selecting vehicles. That means that we really just need to identify the weapons and equipment for each vehicle by name during selection, without displaying all of the weapon characteristics. That information will be useful during the game, but not important during selection.

Given this situation, the best solution is probably to simply add a new field to each vehicle that lists equipment comprising the load-out. This field can be displayed within the description for the vehicle during selection and ignored when we have full access to the gizmo contents. So we'll define a new "vhLoadout" field for exactly this purpose, which should look like the field specification below.

<field
  id="vhLoadout"
  name="Load-Out"
  type="static"
  maxlength="250">
  </field>

Return to the Description Procedure

Now that we have the issue of load-outs resolved during selection, we can get the description procedure properly into place. If we have a thing, we will simply output the "vhLoadout" field for the vehicle. If we have a pick, then we'll go through the contents of the gizmo and properly synthesize all of the appropriate details.

The net result is code that looks like below. This new logic can be added at the end of the "InfoVeh" procedure, after we've verified that we indeed have an entity for the vehicle.

~if this is a thing, report the basic load-out for the vehicle based on the field;
~otherwise, synthesize any load-out for the vehicle as a pick appropriately
~Note: We must differentiate between a thing and a pick when accessing the entity,
~       as we want summary details for a thing and complete details for a pick
var loadout as string
if (ispick = 0) then
  loadout = field[vhLoadout].text & "{br}"
else
  loadout = ""
  foreach pick in gizmo
    loadout &= "{horz 10}" & chr(149) & " " & eachpick.field[name].text & ": "
    loadout &= eachpick.field[wpDamage].text & " - " & eachpick.field[wpRange].text
    if (eachpick.field[wpNotes].isempty = 0) then
      loadout &= " - " & eachpick.field[wpNotes].text
      endif
    loadout &= "{br}"
    nexteach
  endif

~if there is any load-out for the vehicle, output it
if (empty(loadout) = 0) then
  iteminfo &= "Weapons/Equipment:{br}" & loadout
  endif

Refining the Entity

Let's return at our Zero now. We need to specify suitable text for the new "vhLoadout" field. For clarity, we'll put each weapon on a new line and indent it. This yields the following contents for the field.

<fieldval field="vhLoadout" value="   2x 7.7mm MGs{br}   2x 20mm Cannons"/>

Now we'll take a look at our Zero within HL. Go to the "Gear" tab and add a vehicle. Our Zero should be listed, and it should show the load-out equipment properly. Add the Zero to the character, then check the mouse-info text for the vehicle. The display is different, since the Zero actually has two of each weapon that is listed. We need to fix this.

Before we continue, let's take a look at various other vehicles and their load-outs. Some weapons are re-used for different vehicles, which is great, but different ammunition quantities are specified. So we have to handle that. In addition, some vehicles simply re-use weapons and tweak them slightly. We can either implement lots of different weapons that are nearly identical or customize each weapon when it is added to the vehicle.

All of the adjustments can be most easily handled by customizing each weapon via the "bootstrap" element that adds it to a vehicle. Each bootstrap element can possess optional "assignval" child elements, which allow you to override the value of individual fields on the child pick. We can use "assignval" to modify the name, ammunition quantity, or any other facet of individual weapons.

In order to override the values of fields, those fields must be able to be overridden. This requires that a field be designated as the "derived" type. However, the majority of the fields used on weapons are "static". So we need to identify the various fields that we'll want to override and change them from "static" to "derived". After looking through the various vehicles in the core rulebook, the list of fields we need to change include: "wpPiercing", "wpFireRate", "wpShots", and "wpAmmo". Open the file "equipment.str" and modify each of these fields to the new type.



override values and tags on the weapons via the bootstraps to customize small differences

fields that need to be overridden via bootstraps must be changed from static to derived

add "reload1" weapon ability