Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
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.
|
#1 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,213
|
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. |
#2 |
Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
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? |
#3 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,213
|
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 text &= eachthing.field[name].text |
#4 |
Senior Member
Join Date: Jan 2007
Location: NW Arkansas
Posts: 1,321
|
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)?
Working on - |
#5 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,213
|
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.
|
#6 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,213
|
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 = "" if (focus.tagis[ModCatAllw.MountMod] <> 0) then if (focus.autotags.tagis[WMVisible.?] <> 0) then mountmods = splice(mountmods,focus.autotags.tagnames[WMVisible.?,", "],", ") else mountmods = splice(mountmods,"External",", ") endif if (focus.autotags.tagis[WMFlex.?] <> 0) then mountmods = splice(mountmods,focus.autotags.tagnames[WMFlex.?,", "],", ") else mountmods = splice(mountmods,"Fixed",", ") endif if (focus.autotags.tagis[WMControl.?] <> 0) then mountmods = splice(mountmods,focus.autotags.tagnames[WMControl.?,", "],", ") else mountmods = splice(mountmods,"Remote",", ") endif if (empty(mountmods) = 0) then modlist &= " (" & lowercase(mountmods) & ")" endif ~if there's a domDomain field for a weapon mount, that's the direction ~it points, and the format used to display those is to just add it to ~the end of the text, outside the parentheses if (focus.assignvals.field[domDomain].isempty = 0) then modlist &= " " & focus.assignvals.field[domDomain].text endif Code:
foreach bootstrap in this from Gear where searchexpr perform eachthing.setfocus call VehModInfo nexteach |
#7 |
Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
Quote:
Code:
<procedure id="InfoWeapSp" context="info"><![CDATA[ ~declare variables that are used to communicate with our caller var iteminfo as string ~report any special details about the weapon (omitting if there are none) var special as string special = tagnames[Weapon.?,", "] if (isentity = 1) then if (ispick = 0) then foreach bootstrap in this special &= eachthing.field[name].text nexteach else foreach pick in gizmo where "component.WeapQual" special = splice(special, eachpick.field[thingname].text,", ") nexteach endif endif special = splice(special,field[wpSpecial].text,", ") if (empty(special) = 0) then iteminfo &= "Special: " & special & "{br}" endif ]]></procedure> Code:
<thing id="wpmBOB_GREG" name="BFF Autocutlery Chainsaber Mark IX" description="description omitted for space" compset="Melee"> <fieldval field="wpDamage" value="Melee+3d6"/> <fieldval field="grCost" value="4"/> <fieldval field="shortname" value="Chainsaber"/> <tag group="Equipment" tag="TwoHand" name="Requires two hands" abbrev="Requires two hands"/> <tag group="License" tag="Illegal" name="Illegal" abbrev="Illegal"/> <tag group="WeaponType" tag="MelExotic" name="Exotic Melee" abbrev="Exotic Melee"/> <child entity="grCustWeap"> <bootstrap thing="wqHyperAcc"> <autotag group="Quality" tag="Free"/> </bootstrap> <bootstrap thing="wqFProne"> <autotag group="Quality" tag="Free"/> </bootstrap> </child> </thing> |
|
#8 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,213
|
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 |
#9 |
Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
That did the trick! Thank you. I figured there had to be something I was missing.
|
#10 |
|
|