Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 04:08
    BSDataAnon opened #1063
  • Oct 15 16:32
    cartag closed #172
  • Oct 15 16:32
    cartag commented #172
  • Oct 15 16:22

    cartag on master

    Round 1 of Bug Fixes Merge pull request #1062 from B… (compare)

  • Oct 15 16:22
    cartag closed #1062
  • Oct 15 16:22
    cartag opened #1062
  • Oct 15 16:22

    cartag on cartag

    Round 1 of Bug Fixes (compare)

  • Oct 15 16:22

    cartag on cartag

    (compare)

  • Oct 15 16:21

    cartag on cartag

    (compare)

  • Oct 15 16:21
    cartag closed #1061
  • Oct 15 16:20
    cartag opened #1061
  • Oct 15 16:19

    cartag on cartag

    Add files via upload (compare)

  • Oct 15 16:13

    cartag on cartag

    Round 1 of Bug Fixes Fixed Bat… (compare)

  • Oct 15 03:24

    cartag on master

    Round one fixes Merge pull request #1060 from B… (compare)

  • Oct 15 03:24
    cartag closed #1060
  • Oct 15 03:23
    cartag opened #1060
  • Oct 15 03:23

    cartag on cartag

    Round one fixes (compare)

  • Oct 14 01:27

    cartag on v2.1.3

    (compare)

  • Oct 14 01:23

    cartag on v1.50.10

    (compare)

  • Oct 14 01:23

    cartag on master

    Cities of Sigmar initial release (compare)

Iain Launchbury
@Mad-Spy
one downside is that it means it moves around in the display.
unless we go back to numbering the profile types, which i really don't like.
OftKilted
@OftKilted
Not following.
Iain Launchbury
@Mad-Spy
Because the output is alphabetised, the wound table for different units will be in different places.
OftKilted
@OftKilted
Yeah ... this is true, depending on how you’re displaying the data. I was displaying data in a unit centric method (basically a default view)
One could put a non-text character to force it to a specific point

But as it’s all one type of “X Wound table” it will at least still be together under X. Only oddities is that I did have several wound tables that were reused. (Zombie Dragons and Terrorgheists)

The perfect is the enemy of the good. Or Good enough.

Iain Launchbury
@Mad-Spy
I'm not complaining. I like yours better
I might change all of mine :)
OftKilted
@OftKilted
:+1:
Iain Launchbury
@Mad-Spy
@/all, to make everyone's life easier when splitting, GA traits and Artefacts should be in the GST. Please move yours.
Iain Launchbury
@Mad-Spy
see #175
OftKilted
@OftKilted
.... and I was doing so good ...
Iain Launchbury
@Mad-Spy
Got to keep you on your toes :)
OftKilted
@OftKilted
Dang moving goal lines ... let’s line up for another try.
Next thing we’ll have “Battalion Validation” To input ...
OftKilted
@OftKilted
@Mad-Spy Did you actually submit your commit on the GA Traits and artifacts?
I'm not seeing it posted
Iain Launchbury
@Mad-Spy
I did it in my oe
OftKilted
@OftKilted
oe?
Iain Launchbury
@Mad-Spy
My Own branch didn't I?!
And forgot to merge it...
OftKilted
@OftKilted
takes out the poking stick and pokes @Mad-Spy
"Chaos is already done ...." looks at the get ... finds nothing ... Sneaky-sneaky chaos ....
OftKilted
@OftKilted
If you qualify for Allegiance X. And also the GA. You can choose to entirely use the GA Allegiance Traits. Does that mean that you're using Allegiance: <grand alliance> or that you're just using the traits? (See: Allegiance: Tomb Kings ... and Battleline for Tomb Queen ... No Allegiance Traits for TK)
Almost makes one want to set up an 'Allegiance: X (GA:<grand alliance>' allegiance
Iain Launchbury
@Mad-Spy
Just using the abilities.
OftKilted
@OftKilted
That makes more logical sense.
Lemme know when you're going to do the merge, so I can coordinate dropping the Death GA abilities into the gst.
Iain Launchbury
@Mad-Spy
Just merge yours whenever. Mine will go in via a PR.
OftKilted
@OftKilted
We may not test our code often ... but when we do ... we do it in Production.
tekton
@tekton
good news: figured out something I was doing wrong
bad news: that was a wasted night...
OftKilted
@OftKilted
@tekton I know the feeling. Managing Catalogues that have multiple Allegiances (other than just the GA and the default) is nearly headache inducing. I’m a hairbreadth away from just splitting them out (Soulblight, Nighthaunt ... I’m looking at you .... :angry: ) to make catalogue management easier with the Allies forces... hmm ... perhaps there is an easier method
OftKilted
@OftKilted
So ... if one does a “constraint” on the Allegiance, based on the Category entries one could flag ‘bad’ units when building a list.
It wouldn’t hide them, just make a list validity warning. :thought_balloon:
OftKilted
@OftKilted
That might entail more categories in the gst ... hmmm.
Not optimal. :/
OftKilted
@OftKilted
@Mad-Spy What if we were to do this a different way for the Limitations?
If instead of hiding or showing, what if one did modifiers on the Categories?
For example: Nighthaunt
Set a max in roster of -1 by default.
If allegiance 'Derathmages' set Max in Roster to 0
Deathmages
If the units are categorized properly, it should flag that the restriction isn't being met ...
OftKilted
@OftKilted
It just makes gst'izing the keywords not as helpful.
Or reverse it ...
OftKilted
@OftKilted
Set Max 0 selections in Roster (child selections/child forces). Modifier - a decrement MAX 0 Selections by 1 OR <list of allegiances>
While one could set the default for the show the actual 'validation' is more of a 'too many selections of <category> in Roster
The only issue that I'm seeing is that for shared categories you can't add local modifiers.
shared from the gst