forums.cubicle7.co.uk
archive

Ah yep. I just checked again and I have it! I see what they did there (those little tricksters!)

Ok, I tweaked the code to distribute the correct number of rolls across all legs, weighted by the number of days each leg requires. I'm rounding, so it's possible there are edge cases where you end up with too many or too few rolls, but the delta should never be greater than 1.

Basically I changed
to
Yes, total_rolls should probably be "max( 1, round( td / dpr ));"

Here's an example (notice that there are zero travel rolls for the last leg):


I decided not to merge legs, partly because each zone has its own flavor and hazards and encounters, so the LM should know where rolls are taking place.

Please give it a whirl and let me know what you think! (I'll do the same thing, or something similar, for corruption checks.)

That was quick, Elfcrusher! But, seems like the total number of rolls doesn't match up to the total number of rolls listed in each leg of the journey.

Morgoth wrote:That was quick, Elfcrusher! But, seems like the total number of rolls doesn't match up to the total number of rolls listed in each leg of the journey.

Oh, that's because "Total Rolls" should really be labeled "Total Travel Rolls". I added Corruption rolls as an afterthought but never totaled them. I'll do so.

Unless you mean something else....

P.S. I didn't realize that exporting a pdf as a jpeg was hard in Windows. My apologies for the hurdle.

Elfcrusher wrote:

Morgoth wrote:That was quick, Elfcrusher! But, seems like the total number of rolls doesn't match up to the total number of rolls listed in each leg of the journey.

Oh, that's because "Total Rolls" should really be labeled "Total Travel Rolls". I added Corruption rolls as an afterthought but never totaled them. I'll do so.

Unless you mean something else....

P.S. I didn't realize that exporting a pdf as a jpeg was hard in Windows. My apologies for the hurdle.

No I wasn't counting corruption rolls. For example:

Oh, yeah, that's the rounding error. Thinking about a fix for that.

In the example you showed, it should probably be just one leg. And maybe that suggests a change: any time there wouldn't be any rolls, combine that leg with an adjacent leg.

The other thing I'd love to do is handle the cells that overlap two (or more) zones, and then have the software infer which zone you must mean.

Those are both good ideas. As for the coding, I don't think I can be much help there :\

Also, is there some way to make the route by clicking each square? I always drag the mouse over the route, then end up messing up a little and having to redo it a few times.

Shift-click works for selecting and unselecting hexes

Just pushed a new fix (thought of the solution in bed and got up to type it...took 30 seconds.) Basically, whenever rounding the # of rolls to an integer, add the rounding error (positive or negative) to the next leg. I.e.:
So imagine three legs of equal length and 10 rolls. Each leg would get 3.333 rolls, rounding down to 3, and totaling 9. With this new algorithm, the .333 from the first leg gets carried over to the second leg, giving it 3.666, which rounds up to 4. The -.333 carries to the third leg, giving it 3.000.

Please test this out and see if you can still find edge cases.

(Corruption tests are still being computed independently for each leg, and always rounded up.)

Valarian wrote:Shift-click works for selecting and unselecting hexes

Awesome. I should have figured that out.

Elfcrusher wrote:Just pushed a new fix (thought of the solution in bed and got up to type it...took 30 seconds.) Basically, whenever rounding the # of rolls to an integer, add the rounding error (positive or negative) to the next leg. I.e.:

Code: Select all

rounding_error = 0
legs.each do | leg |
    decimal_rolls = leg.days * total_rolls / total_days + rounding_error
    leg.rolls = round( decimal_rolls );
    rounding_error = decimal_rolls - leg.rolls
end

So imagine three legs of equal length and 10 rolls. Each leg would get 3.333 rolls, rounding down to 3, and totaling 9. With this new algorithm, the .333 from the first leg gets carried over to the second leg, giving it 3.666, which rounds up to 4. The -.333 carries to the third leg, giving it 3.000.

Please test this out and see if you can still find edge cases.

(Corruption tests are still being computed independently for each leg, and always rounded up.)

This looks great! I'll probably test it a bunch tomorrow. Because right now...

Fire and lamp, and meat and bread,
And to bed! And then to bed!