Building a thing description from default gizmo properties
Pursuant to http://hlkitwiki.wolflair.com/index....tion_Procedure in the documentation, they recommend an approach of having a static text field with the vehicle loadout since "The load-outs for each vehicle in Savage Worlds is fixed, and the number of vehicles is not exhaustive". Is there a better way as we start to have more items and/or want to change how we present the information? I'd prefer to programmatically build the text so that I don't have to change it in more than one place.
|
I don't read that as a recommendation - I read it as the choice that was made based on the set of vehicles that existed in the core rulebook at that time.
The problem with changing something like this in an existing game like Savage Worlds will be that you'll have to make the change in a way that preserves everyone else's work on the vehicles in their own settings, while still expanding the capabilities for those who want something more extensive. Without knowing extensive details about how vehicles in Savage Worlds are implemented, and knowing what changes you're proposing, I don't know what the best approach would be. |
Ah. To clarify for my own case, I am using a similar construct in two places. One is advanced vehicles, where users can buy and sell ship upgrades in much the same way as the weapons in the article above. Existing ships have these upgrades as well. When the user is buying a ship, I would like to be able to list all of the ship upgrades. The second is a set of weapon qualities that, again, sometimes come inherent and sometimes may be added or removed on an existing instance. I started out using tags, but since the items have inherent cost, descriptions, rules, etc, it seemed to make more sense to dip into Gizmos.
At the risk of an over-simplified example, let's say that we have some weapon qualities built such as Accurate, Double-Tap, and Failure-Prone. The Shafter pistol comes with the Accurate and Double-Tap qualities present. I can bootstrap those qualities onto the entity, and I've got the description working to build a list of special properties ("Accurate, Double-Tap") for the weapon, but the description when buying one does not have those items (since it's a Thing being presented, not a Pick). :) Does that make things any clearer? |
Ok, this is "how do look up a bootstrap as a thing" - I thought you were asking a design philosophy question, about how to design a system where you can have HL generate the whole set of text for you.
Code:
foreach bootstrap in this from Component |
Since the foreach is working on the gizmos/bootstraps, does anything have to change depending on if ‘this’ is a Thing (for display say in a chooser description) or a Pick (for output in a statblock/output sheet)?
|
The question there is whether you want to be able to update the list with any changes the user has applied - for example, can the user add another thing from the same category to the list of standard things that came with the vehicle? Or can the user pay to upgrade the level of one of the standard things, in which case you want the name displayed to the user to change. If so, then you'll want your script to have a branch, with a pick branch that uses foreach pick in gizmo, and a thing branch that uses foreach bootstrap in this. If you're ok with the same list being displayed before and after the user adds the item, then the foreach thing will function in both cases, and give the same information in both cases.
|
Something I realized I should add to the foreach bootstrap in this - here's how you can look up tags that were assigned to a bootstrap as autotags and fields that were assigned to the bootstrap as assignvals:
Code:
mountmods = "" Code:
foreach bootstrap in this from Gear where searchexpr |
Quote:
Code:
<procedure id="InfoWeapSp" context="info"><![CDATA[ Code:
<thing id="wpmBOB_GREG" name="BFF Autocutlery Chainsaber Mark IX" description="description omitted for space" compset="Melee"> |
First, just a best practice - in any foreach, you should always try to use the "from <component>"
So Code:
foreach bootstrap in this from WeapQual Code:
foreach pick in gizmo from WeapQual Ok, I think I see what's going on - my example was from a vehicle, designed to handle the bootstraps that are coming from the vehicle, but not from the vehicle's entity. Code:
foreach bootstrap in entity from WeaponQual |
That did the trick! Thank you. :) I figured there had to be something I was missing.
|
All times are GMT -8. The time now is 05:55 AM. |
Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.