• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Position script and tagis[]?

T

TCArknight

Well-known member
I am laying out a set of fixed tables in a layout named "treetab"

Code: 
[FONT="Courier New"]  <layout
    id="treetab">
    <portalref portal="stRow1Col1" taborder="20"/>
    <position><![CDATA[

          var gap as number
	  var colspan as number
	  var cellwidth as number
	  var cellwidth2 as number
	  var cellwidth3 as number
	  var cellwidth4 as number
	  var hlinewidth as number
	  var vlinewidth as number
	  
	  gap = 20
	  cellwidth = 108
	  cellwidth2 = (cellwidth * 2) + gap
	  cellwidth3 = (cellwidth * 3) + (gap * 2)
	  cellwidth4 = (cellwidth * 4) + (gap * 3)
	  
	  hlinewidth = gap
	  
          ~position rows
	  ~row 1
          portal[stRow1Col1].left = 0
          portal[stRow1Col1].top = portal[stSpecName].bottom + gap
          ~portal[stRow1Col1].height = 40
	  
	  [COLOR="Red"][B]if (tagis[SpecColSpan.?] = 0) then[/B][/COLOR]
	    portal[stRow1Col1].width = cellwidth
	  else
	    colspan = tagvalue[SpecColSpan.?]
	    if (colspan = 2) then
	      portal[stRow1Col1].width = cellwidth2
		elseif (colspan = 3) then
	      portal[stRow1Col1].width = cellwidth3
		elseif (colspan = 4) then
	      portal[stRow1Col1].width = cellwidth4
		  endif
	    endif

        ]]></position>[/FONT]
I get:
Hero Lab was forced to stop compilation after the following errors were detected:

Syntax error in 'position' script for Layout 'treetab' on line 26
-> Invalid use of reserved word 'tagis' in script
Click to expand...

The fixed table portal[stRow1Col1] contains a Talent which may have the SpecColSpan.? tag. That is the tag I'm trying to check to see if the portal needs to be single, double, triple or 4 columns wide.

At least that was what i was thinking, but now it seems that I'm missing something.

Any suggestions on what I'm missing?

Thanks!
TC
 
Think of context - a layout script isn't attached to any pick. It's not even hero context, so what pick is the tagis[] testing a tag on - none.


Templates do operate in the context of a specific pick, so that's more likely to work - build this display in a template, then arrange the finished template in the overall layout.
 
I really appreciate the help . :)

I am running into an issue though and I'm not sure the best way to solve it.

I moved everything for my first row into a template (ptRow1):
Code: 
[FONT="Courier New"]                     
  <template
    id="ptRow1"
    name="Cells Row 1"
    compset="Power">

	  <portal
		id="ptRow1Col1"
		style="tblOuter">
		<table_fixed
		  component="Power"
		  showtemplate="ptPower"
		  scrollable="no"
		  alwaysupdate="yes"
		  agentlist="PowerTree">
		  <list>TreeRow.1 & TreeCol.1</list>
		  </table_fixed>
		</portal>
		
	  <portal
		id="ptRow1Col2"
		style="tblOuter">
		<table_fixed
		  component="Power"
		  showtemplate="ptPower"
		  scrollable="no"
		  alwaysupdate="yes"
		  agentlist="PowerTree">
		  <list>TreeRow.1 & TreeCol.2</list>
		  </table_fixed>
		</portal>

	  <portal
		id="ptRow1Col3"
		style="tblOuter">
		<table_fixed
		  component="Power"
		  showtemplate="ptPower"
		  scrollable="no"
		  alwaysupdate="yes"
		  agentlist="PowerTree">
		  <list>TreeRow.1 & TreeCol.3</list>
		  </table_fixed>
		</portal>
		
	  <portal
		id="ptRow1Col4"
		style="tblOuter">
		<table_fixed
		  component="Power"
		  showtemplate="ptPower"
		  scrollable="no"
		  alwaysupdate="yes"
		  agentlist="PowerTree">
		  <list>TreeRow.1 & TreeCol.4</list>
		  </table_fixed>
		</portal>

    <position><![CDATA[
	  
	  var gap as number
	  var colspan as number
	  var cellwidth as number
	  var cellwidth2 as number
	  var cellwidth3 as number
	  var cellwidth4 as number
	  var hlinewidth as number
	  var vlinewidth as number
	  
	  gap = 20
	  cellwidth = 108
	  cellwidth2 = (cellwidth * 2) + gap
	  cellwidth3 = (cellwidth * 3) + (gap * 2)
	  cellwidth4 = (cellwidth * 4) + (gap * 3)
	  
	  if (tagis[TreeColSpan.?] = 0) then
	    portal[ptRow1Col1].width = cellwidth
	  else
	    colspan = tagvalue[TreeColSpan.?]
	    if (colspan = 2) then
	      portal[ptRow1Col1].width = cellwidth2
		  portal[ptRow1Col2].visible = 0
	    elseif (colspan = 3) then
	      portal[ptRow1Col1].width = cellwidth3
		  portal[ptRow1Col2].visible = 0
		  portal[ptRow1Col3].visible = 0
		elseif (colspan = 4) then
	      portal[ptRow1Col1].width = cellwidth4
		  portal[ptRow1Col2].visible = 0
		  portal[ptRow1Col3].visible = 0
		  portal[ptRow1Col4].visible = 0
		  endif
	    endif

      ]]></position>

    </template>[/FONT]
However, I get the following:
Hero Lab was forced to stop compilation after the following errors were detected:

Template 'ptRow1' - Reference to portal 'ptRow1Col1' that can only be used within a layout
Template 'ptRow1' - Reference to portal 'ptRow1Col2' that can only be used within a layout
Template 'ptRow1' - Reference to portal 'ptRow1Col3' that can only be used within a layout
Template 'ptRow1' - Reference to portal 'ptRow1Col4' that can only be used within a layout
Click to expand...

I seem to recall something about tables not being able to be inside a template? If that's the case, is there a better way to mimic this kind of layout?
 
I hadn't caught that those were table portals you were trying to make use of.


Ok, then time to re-think your approach - HL doesn't support the smart layout you want - time to think of a stupider layout where things have fixed sizes and positions, and they stay where they are.

I'm happy to help, but I don't know anything about what you're trying to present, and what it's supposed to look like.
 
Also, there may be ways of accomplishing something like you want, but it'll have to be based on sizing the contents, and then positioning the portals in the layout based on that. I'll need to know more about what you're trying to accomplish to help, though.
 
Mathias said:
Also, there may be ways of accomplishing something like you want, but it'll have to be based on sizing the contents, and then positioning the portals in the layout based on that. I'll need to know more about what you're trying to accomplish to help, though.
Click to expand...
Thank you Mathias, I really appreciate the help.

In the system I'm working on, mostly as a challenge to myself, Specializations are built on a Tree (4 columns, 5 rows) of talents with each talent "leaf" havinga particular cost depending on the location of the Talent on the tree. That Is what I've gotten working at the moment with the series of fixed_tables which each would hold just the one Talent.

The twist comes in the "Powers" for a hero. They too are set up in a tree-like structure of 4 columns and 5 rows) containing several aspects of the power which can be one of 5 "upgrades" in addition to the Basic power. The Basic power with is the root of the tree and takes up all 4 columns of the 1st row.

After that, each upgrade can take anywhere from 1 to 4 leaf positions in the subsequent rows. A simple example would be:
Code: 
[FONT="Courier New"]
(<-------------- BASIC POWER ---------------->)
(<----------   Upgrade 1 --------->) (Upgrade 2)
(<----   Upgrade 3 --->) (upgrade 4) (Upgrade 5)
(<----   Upgrade 6 --->) (upgrade 7) (Upgrade 8)
(Upgrade 9) (upgrade 10) (Upgrade 11) (Upgrade 12)[/FONT]

Does that make sense?
 
What does the width of each one represent? Is that game relevant, or just the designer's visual choice for how to display them? Does it mean that in upgrade row 1, you've got 4 points to spend, and the user spent 3 on upgrade 1, and 1 on upgrade 2?

Can upgrades be skipped? Can you take upgrades 1 and 3, but not 2?

Can this be a normal table, with the upgrades listed below the power, but indented to show that they're sub-abilities, not the main ability?

Pages from the original rules might help me understand what you're trying to get at. Sample character sheets would be good, too - so I can see an example of a real power with the upgrades that have been chosen. You've got my email address, in case these are things you'd rather not post on this forum.
 
Last edited:
Mathias said:
What does the width of each one represent? Is that game relevant, or just the designer's visual choice for how to display them? Does it mean that in upgrade row 1, you've got 4 points to spend, and the user spent 3 on upgrade 1, and 1 on upgrade 2?

Can upgrades be skipped? Can you take upgrades 1 and 3, but not 2?

Can this be a normal table, with the upgrades listed below the power, but indented to show that they're sub-abilities, not the main ability?

Pages from the original rules might help me understand what you're trying to get at. Sample character sheets would be good, too - so I can see an example of a real power with the upgrades that have been chosen. You've got my email address, in case these are things you'd rather not post on this forum.
Click to expand...
This is what I'm trying to implement. The linked pdf is a compilation of the Force Power trees from all the various sourcebooks for FFG's Star Wars RPG.
Force Powers Trees
The number in the cell is the XP cost to purchase the basic power or upgrade. The vertical/horizontal links indicate, once an upgrade is taken, which are eligible to be taken next.

The part that gets me is that it's very visual, and dependant on things selected in a particular order.
 
Is there ever a choice of which thing to take in a specific upgrade position, or does each power have a fixed set of upgrades - the one you've posted there only seems to have "I've taken this" checkboxes.

If there aren't options, then one way to implement this is with a lot of complexity built into the power itself - 16 checkbox portals, 16 text fields as titles ("Control", "Duration", etc., and 16 description fields. Then, when the user adds the power, each power display pick within the powers table is very tall, and contains the various checkboxes laid out in a grid - for example, on the one you showed, in row 1, portals 1, 2, and 3 are used, 4 is hidden, and 3 is stretched over a 2-column space.

The skeleton files already offer vertical and horizontal lines (they're designed to be separators, but maybe they can be re-purposed here, too).

Based on this one example, it appears that every checkbox portal always includes a vertical line to the thing above it - always centered on the display of the upgrade itself. Horizontal lines are rarer - looks like you'll need to come up with some system to set which horizontal lines to show for each ability.

For your description text, you'd have a thing in the descript procedure to check which checkboxes were checked on a particular power, and then append the name and description of the active ones as part of the power's final description.

For the pick template for the power, you can come up with color schemes that highlight the selected/available/not available for each checkbox, or just do a simple version where you set portal[checkbox0103].enable = 0 if the character doesn't qualify for that one yet. You might also need bound scripts on the portal fields, so that if the character doesn't qualify for it, the @maximum = 0 - that way, if the user un-checks a higher-up portal, the ones below it un-check themselves. Or if you don't want to do that automatically, you'll need a lot of eval scripts to check dependencies.
 
Last edited:
Option 2 - this one's necessary if there are multiple choices available to some powers, and may be the way you want to go anyway.

All powers have a gizmo. Within that gizmo's form, you offer a single table to add upgrades to the power - each of the various control, range, duration, strength, etc. upgrades are a thing that can be added to the table, and each one defines prereqs as to which other upgrades need to be selected before it can be selected.

Then, on the pick template on the powers table, you don't present the upgrades as powers. Instead, you have individual text portals. Each uses a foreach to search through the upgrades added to the gizmo of that power, looking for one with a tag or pair of tags that match its position, and if found, displays the name of that power - "Control" or whatever. Then, the mouseinfo on that portal uses the same foreach to find the power and show its description text.

In both cases, if the foreach pick in gizmo fails to find something, then it runs a foreach thing in compset, to find all the upgrades that could be added to that spot, and displays them (but grayed out, since the user hasn't selected this yet).


Oh, and for both these ideas, I'm thinking of using portals (checkbox or text) where the borders are all turned on, so that the display looks like a box.
 
Last edited:
Ok, that was too much time spent on this, during these last few weeks before the Gen Con release wave (tsunami), but this sort of design is what I consider the most fun task in my purview, and my current project is not as fun (some fiddly setup), so I guess it was a good break. Ok, back to work.
 
Last edited:
Mathias said:
Ok, that was too much time spent on this, during these last few weeks before the Gen Con release wave (tsunami), but this sort of design is what I consider the most fun task in my purview, and my current project is not as fun (some fiddly setup), so I guess it was a good break. Ok, back to work.
Click to expand...
Thank you Mathias! That gave me a good idea of perhaps how to get it done. I may have a couple of questions here and there, but I’ll try to work things out best I can. :)
 
You must log in or register to reply here.
Back
Top