Lone Wolf Development Forums

Lone Wolf Development Forums (http://forums.wolflair.com/index.php)
-   HL - Authoring Kit (http://forums.wolflair.com/forumdisplay.php?f=58)
-   -   Building a thing description from default gizmo properties (http://forums.wolflair.com/showthread.php?t=63073)

Duggan August 20th, 2019 07:49 AM

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.

Mathias August 20th, 2019 08:26 AM

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.

Duggan August 20th, 2019 09:06 AM

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?

Mathias August 20th, 2019 09:22 AM

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


TCArknight August 20th, 2019 10:48 AM

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)?

Mathias August 20th, 2019 11:16 AM

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.

Mathias August 20th, 2019 11:28 AM

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

This code is from a procedure that's called by the foreach bootstrap, since we have multiple places where we need to look up the same info. A procedure can't reference eachthing or eachpick unless the foreach is inside the same procedure, which is why it sets the focus to the current pick and then calls the procedure, and the procedure uses the focus.
Code:

    foreach bootstrap in this from Gear where searchexpr
      perform eachthing.setfocus
      call VehModInfo
      nexteach


Duggan August 21st, 2019 07:10 PM

Quote:

Originally Posted by Mathias (Post 281414)
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.

Yes, I want to update the description if the user changes things. So I guess I will need the dual setup. The following is what I've got set up, but it's still not pulling in those bootstrapped qualities in the purchase table. Using debug statements, I've verified that I get into the "ispick = 0" section, but that the loop doesn't execute anything in it, suggesting that there are no items among the bootstraps.

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>

In case it's relevant, this is the weapon I'm testing it out with:
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>


Mathias August 21st, 2019 07:22 PM

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
and
Code:

foreach pick in gizmo from WeapQual
That's a speed savings for HL.

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
Would be the way to look inside the gun's entity. "foreach bootstrap in this" will look at the bootstraps outside the entity.

Duggan August 22nd, 2019 02:43 AM

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 01:23 PM.

Powered by vBulletin® - Copyright ©2000 - 2019, vBulletin Solutions, Inc.
wolflair.com copyright 1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.