SWADE Chase Range

Chase in SWADE is more broken.

There was a work-around where the GM would set distance multiplier to a decimal value to calculate chase distance more or less accurately, like 1.7 to calculate a range of 5 per card.
That work-around is no longer workable.

The range now shows raw range, even when "show raw distance" is toggled off.
The diagonal distance option also makes no difference.

This changed recently, and is in the current release version, as well as the test channel.
This makes chases unusable.

Here's a screen shot. It's very zoomed in to show the tiny number. The number should be a legible "5".
Attachment 56466

Thanks

Confirmed :(

I would not say it is more broken. Without seeing evidence of an even older issue. However lets discuss the current situation.

Not conviced that this is a new issue. For due diligence have tested in Prev branch. Lets break it down into smaller bits to get clarity: I have set a grid set to 1.7 per square. Which means a card incerment is now going to be 5.1. Note the numbers given for card incerment is just a suggestion so people could use intergers and dodge the whole problem. Especially if they look at weapon range bands for a better number. However lets all agree to use 1.7 for now. At this point in my test the chase button has not been set to on. Cards have be laid down but chase rules switched off. Here is the result:

1. The "show raw distance" does not seem to have any effect outside of chases. Does the setting even work in SWADE outside of chases?
2. Use the mouse to simply draw an arrow and display length. Measured distances are always shown to one decimal place.

When the chase button is pushed repeat:

1. The "show raw distance" does not seem to have any effect.
2. Use the mouse to simply draw an arrow and display length. Measured distances are always shown to mutiple decimal places in a tiny font.

Questions:

1. Does the The "show raw distance" check mark work at all?
2. Why is range not shown the same number of decimal places when chase mode engaged?

The chase button should make all measurements count orthogonally (no diagonals). Without changing the display properties.

I say more broken because it was somewhat broken previously.
Here's my argument for why chase was already broken (again).

The fact that I have to divide normal chase increments by 3 is crazy. The distances never come out to whole numbers. There should be no rounding happening.
While in chase mode, each card / chase position should measure as the distance multiplier. The chase range increment should be the distance multiplier.
That's the point of the case mode. What's the purpose of having that button if it just does weird fractional calculations? You could not use chase, put down cards, set distance to 5 (25/50), and move one square at a time.
Having to calculate and enter odd distances so ranges come out close to accurate is broken. (And not as close when doing starship fights.)

Regularly in starship fights the range bumps over into the next increment due to rounding, or counting the cards should put it in medium range, but fractional calculations put it into long. I have to move tokens for rolls or hand update totals in those cases. It means every roll is watched and checked, which slows down chase scenes. I consider that broken.

There was a time when I would set the distance multiplier to 5 (or 25 or 50) and it would calculate the distance properly. It worked just like on the table top.

Sorry for the grumpiness. This is a real thorn in the side for our games, and I sometimes avoid the chase rules (and entire chase scenes) because of it. I don't do starship chases at all at this point.

To answer the questions:
Here's chase turned off and show raw distance on. It's the same when raw distance is turned off.
Attachment 56505

Here's the chase turned on and show raw distance off. It's the same when was distance is toggled on.
Attachment 56504

No, toggling raw distance makes no difference, either in or out of chase.

The only thing working is the orthogonal measurement.

I think this counts as more broken.

It is broken and has been for some time. It makes no semse having a Chase mode that makes more work for the GM. The old Doswelk Chase video haa none of this weird work around finagling.

Quote:

---

Originally Posted by Mike Serfass

I say more broken because it was somewhat broken previously. Here's my argument for why chase was already broken (again). The fact that I have to divide normal chase increments by 3 is crazy.

---

Quote:

---

Originally Posted by Jiminimonka

It is broken and has been for some time. It makes no semse having a Chase mode that makes more work for the GM. The old Doswelk Chase video haa none of this weird work around finagling.

---

We simply could not place place more that one token in the same square when setting up a Dogfight card layout. From the very first day the chase rules came out the solution was to divide the suggested chase increments by 3. The word suggested which is written in italics comes directly out of the game chase rules. So the method used is a completely intentional design feature guided by game rules. It's a old compromise and not a new bug. The very first tutorial video made by Savage Doswelk years ago explained this limitation.

Debates on chase rules or token stacking are futile here. Any point of view is build on the assumption that rounding featues work. The real problem is that does not seem to be the case. So based on how it is supposed to work. Here is once again the problems at hand.

1. The show raw distance check mark in map controls does not appear to function under SWADE. Both inside and outside of a chase. So the question for the developer is how is this core rules function being disabled?

2. Calculations are displayed to a diffrent number of decimal places when chase button is used. So standard rounding is being bypassed when switching on chase rules to count orthogonally. So the question for the developer is how a core rules rounding function being bypassed?

It is two bugs and a feature request. If the original token stacking limit fix can be removed that is great but right now a ruler that works is what is needed. I know people are not satisfied by the whole original solution to SWADE case rules. I can sympathize with the objections raised. Ikael came up with the best solution available at the time. Have linked to the original training video which helps explain how we got here. The general consensus is right now SWADE has some non-functional map tools that need fixed before we get futher into the weeds on this one.

So, I was just watching the @Doswelk video; and the behaviors that he showcased all appear to be working as noted in that video in the current SW ruleset version.

For @Lonewolf's specific callouts,

1) The raw calculation and the adjustments to units and suffix work correctly; however, there is a bug that the the targeting arrows do not update immediately on change of those parameters. I'll open a ticket for that one.

2) There is an override in the ruleset for how measurements are calculated, which is how the ability to override the default target measurement is even possible in the chase scenarios. Since the measurement is being overriden, the Savage Worlds chase measurement code is responsible for returning the number to be displayed, not the client. This ruleset is currently in maintenance mode given that the developer has been unavailable, and we are working hard to keep it up to date with the latest CoreRPG changes. If I have a few minutes, I'll look to see how easy it is to change the chase code to not need divide by 3 and apply rounding; but no guarantees as it's not code that I wrote.

I'm not sure why there is a claim that the tools are now "non-functional", as they appear to work as they were originally created a few years ago.

Regards,
JPG

Took a quick look at the measurement code in SW.

* I don't see any way in the current code to differentiate between foot chase vs. dogfight; there's just a find "nearest chase card" function. So, the current chase code does not provide any mechanism to know whether a given chase setup is foot chase or dogfight, so I won't be able to do anything about divide by 3 requirement.

* I think I was able to add the rounding for the chase calculations to keep the scientific notation from displaying; but you still have the divide 3 scenario for dogfight setups as noted above. I've added to the version currently in the Test/beta channel.

Regards,
JPG

Quote:

---

Originally Posted by Moon Wizard

Took a quick look at the measurement code in SW.
* I don't see any way in the current code to differentiate between foot chase vs. dogfight; there's just a find "nearest chase card" function. So, the current chase code does not provide any mechanism to know whether a given chase setup is foot chase or dogfight, so I won't be able to do anything about divide by 3 requirement.

---

The trick here is using the same a find "nearest chase card" function for both. Whilst telling the GM to alter the card spacing. It is GM setup that makes the difference. Standard chases overlap card areas reducing the distance between those cards. Dogfights don't overlap cards and so use the full chase card size of nine squares. The same solution therefore works for both.

Quote:

---

Originally Posted by Moon Wizard

* I think I was able to add the rounding for the chase calculations to keep the scientific notation from displaying; but you still have the divide 3 scenario for dogfight setups as noted above

---

Stopping scientific notation from displaying is all that is required for the chase system to work as intended. So long as the display is rounding to one decimal place it works just fine.

People might still complain or get confused by the Dogfight setup dividing increments written in book by 3. However, it gives nine squares to get passed token stacking. Unless there is a fundamental change that allows multiple tokens to share the same square. I can’t see us ever getting rid of the dividing by 3 setups.

The only area of that might still cause concern is this. The show raw distance tick mark still has no functional use in SWADE. Distance will now always round off to one decimal place regardless of how show raw distance has been set. Although it does not appear to do anything. I don’t see this as a significant issue. I am not aware of a use case that depends on show raw distance being set differently in SWADE.

It appears chases are fixed. I know people are going to still hate the divide by 3 set up but it there for a reason and it is explained in the tutorial.

Thank you for addressing this, Moon Wizard.
It's not easy maintaining someone else's code for a system you don't play.
It's appreciated.

I made some code tweaks to the swade ruleset. Here's how it now works for me.

This is the standard foot chase. Note that I set distance multiplier to 5. It calculates range correctly on the target arrows and in the attack rolls.
Attachment 56603

Here's the same foot chase with the same distance multiplier but cards spread out like a dogfight.
Attachment 56604

Here's the same foot chase and distance with cards spaced with one grid between. Notice how the ranges and distances calculate correctly.
I don't know why you'd set it up like this, but my change supports it. You could put 3, 4, 5, 10 spaces between the cards and it calculates correctly.
Attachment 56605

Drawing arrows on the board measures the same.
Attachment 56606

Here are my code changes with a dogfight.

First, a dogfight set with distance multiplier 5.
Attachment 56607

Here it is set at 50.
Attachment 56608

Everything calculates correctly. No fractions, no decimals, no divide by 3.
This is how it should work.

I'll test my changes a bit more then share them with Moon Wizard.
If the decision is to not implement this change, I'll turn my code into an extension.

Nice work!

Quote:

---

Originally Posted by Mike Serfass

Here it is set at 50.
Attachment 56608

Everything calculates correctly. No fractions, no decimals, no divide by 3.
This is how it should work.

---

Yes is how everyone wants it to work. This is better. A lot better.

With the last fix. The current chase system now works as intended when it was first introduced. It works but everyone hates the solution with a passion. Divide by 3 and enter fraction into distance multiplier is a terrible solution. It is possible to dodge errors by not putting in a fraction but that puts a burden on the GM. Who now has to check every ranged weapon for range compatibility.

Counting by proper chase card increments is a feature that is long over due.

Here are the code changes I made, in case anyone wants to test it.
I included code comments and a variation on the function that figures out chase card spacing.
These changes are based on the test channel code as of March 5 but work in the live channel SWADE ruleset as well.

Here's the synopsis:
In scripts/manager_token2.lua, in getTokenDistance method added at line 344
local divisor = ImageManagerSW.calculateChaseCardDivisor(ctrlImage )
edited line 345 to
local nDistance = (ImageManagerSW.measureChaseVector(ctrlImage, nVectorX, nVectorY) * ctrlImage.getDistanceBaseUnits()) / divisor

In scripts/manager_image_sw.lua, added
function calculateChaseCardDivisor(ctrlImage)
There are two of these; a simple one (commented out) and a much more dynamic one.
The dynamic version accounts for cards being re-spaced, re-ordered, changed between foot chase and dogfight, adding and removing cards, spacing cards from 1 up to 5, etc.

In campaign/scripts/image_record.lua, in onMeasurePointer method, added at line 27
local divisor = ImageManagerSW.calculateChaseCardDivisor(self)
and updated line 28 to
return ((nGridUnits * nBaseUnits) / divisor) .. getDistanceSuffix()

I attached a zip with the three lua files. You can replace these files in the test channel as well as in the live.

@Moon Wizard: I hope these changes can make it into the SWADE rules. You'll grasp what I'm doing quickly and will likely have a more elegant reworking of this.

So, just after posting this I got the update.
Here are the edited lua files that now match what was released an hour ago.

Thanks, Mike. I'll take a look when I get some time to digest.

Regards,
JPG

I have not noticed these issues (actually I may have done and forgot, I'm getting old), in fact I ran a chase last night and had no problems, BUT I long ago came to the conclusion my setup seems to be different to ANYONE else (I have to delete forge .dat files of SWPF modules to allow my versions to work!)

That said if I had the problem I'd be so annoyed, so well done guys for fixing it :)

Quote:

---

Originally Posted by Doswelk

I have not noticed these issues (actually I may have done and forgot, I'm getting old), in fact I ran a chase last night and had no problems, BUT I long ago came to the conclusion my setup seems to be different to ANYONE else (I have to delete forge .dat files of SWPF modules to allow my versions to work!)

That said if I had the problem I'd be so annoyed, so well done guys for fixing it :)

---

You probably do the divide by 3 automatically now hence you should definitely write the Stream Template formula as per Discord.

https://discord.com/channels/2745828...31518574346250

What do you mean divide by 3?

Not read this thread in detail as I do not have the problem and therefore have never needed to work out a work-around <confused>

Quote:

---

Originally Posted by Doswelk

What do you mean divide by 3?

Not read this thread in detail as I do not have the problem and therefore have never needed to work out a work-around <confused>

---

Exactly ;)

Quote:

---

Originally Posted by Doswelk

What do you mean divide by 3?

Not read this thread in detail as I do not have the problem and therefore have never needed to work out a work-around <confused>

---

Dividing the distance multiplier by 3 when doing dogfights or chases where you want to space out the card with highlighting turned on. The quirk you point and how to make up for the card highlight being 3 spaces per card.
If you don't have to divide by three, how are your distances and ranges accurate? Are we missing something?

Quote:

---

Originally Posted by Mike Serfass

Dividing the distance multiplier by 3 when doing dogfights or chases where you want to space out the card with highlighting turned on. The quirk you point and how to make up for the card highlight being 3 spaces per card.
If you don't have to divide by three, how are your distances and ranges accurate? Are we missing something?

---

I only recall one dog fight in games wirh Doswelk, the weird war one. Maybe he has forgotten.

Quote:

---

Originally Posted by Doswelk

I have not noticed these issues (actually I may have done and forgot, I'm getting old), in fact I ran a chase last night and had no problems

---

That is becuase you ran a chase and not a Dogfight. Cards overlap in this set up and the increment is therefore one square so you can't see the problem.

Quote:

---

Originally Posted by Doswelk

What do you mean divide by 3? Not read this thread in detail as I do not have the problem and therefore have never needed to work out a work-around <confused>

---

There is a tutorial video I linked to by a helpful chap. He is the best person for an explanation why we all divide by 3 :p

Using Savage pathfinder and the quick map system, SWADE chase rules can be selected, but I can't see how to set range. What am I missing?

Quote:

---

Originally Posted by Maxpdev

Using Savage pathfinder and the quick map system, SWADE chase rules can be selected, but I can't see how to set range. What am I missing?

---

Have you dragged the cards onto the map?

Yes I have, it looks like a chase, but I don't see a place to input range increments.

Quote:

---

Originally Posted by Maxpdev

Yes I have, it looks like a chase, but I don't see a place to input range increments.

---

Once it is in Chase mode, it will automatically set range increment, if you want to change the range increments, unlock the image and edit the scale in the Grid section. This works the same way it does in Doswelks videos.

Post #11 has screenshots of the grid section where range increment is set.

Great, thanks! got it working. One less thing I am confused about.