forums.cubicle7.co.uk
archive

Glorelendil wrote:

Indur Dawndeath wrote:But they dont have to wear the warm winter clothes, freeze at night or melt ice to get water, so no need to change the fatigue ratings. Just stick with RAW.

Cheers

??

Maybe we're understanding the meaning of the rules a little bit differently. I always took the encumbrance of the travel gear to simply mean the weight/bulkiness of traveling gear. So even if you've got those sweaters and wool blankets packed away for the future, you're still carrying them.

The frequency of the checks of the travel checks (every 3 days in winter, every 6 days in summer, etc.) has to do with being wet and cold, trudging through snow, etc.

Am I understanding the rules differently than others?

I agree that the winter frequency has to do with the increased difficulty of travel, and the incrase in fatigue per failed test, has to do with the encumbrance of the gear, but my suggestion is to only apply the increase when it is actually needed i.e. In the winter season.
Equally there is no difference in fatigue per failed test from packing for a long trip and a short one...
A perfectly valid reason for the increase in fatigue could be that the consequence of a failed test is more dire in the winter season. If you fail to get a fire going in the winter or fail to find shelter, you could actually die!

Anyway my suggestion was only to keep it simple.

For any computer scientists out there, I'm going to need an algorithm that, given a contiguous and closed sequence of coordinates in a hex-shaped grid, determines if a cell represented by a pair of coordinates is inside enclosed by the sequence. (In other words, if regions are defined by their borders, test whether a hex cell is inside that region.) It should be as zippy as possible, so that I can iterate through all regions querying which one(s) the cell is in.

Alternatively, given the border, generate the list of all additional cells that are enclosed within that border.

Glorelendil wrote:Has not been updated in a while but it's on my to do list.

Can you post screen shots of the paths that break?

I'm starting in either Rhosghobel or Rivendell and the error hex is the last one you see drawn.

Honestly, no pressure, but this is the most remarkable tool out there for TOR. I'm not saying devote all your unpaid labor to this, but I am saying it's immensely rad.

Oh! You're using the player map; that makes it hard. I think you are hitting hexes that are not part of regions on the LM map. Try loading the LM map instead.

Sure enough, that did it. Though the problem with south of Mirkwood and the East Bight remains. The person who replied a few up saying those areas being simply blank (read: without terrain/evilness ratings) is what was messing up. But I can deal with that! And, if you're into updating the project, setting everything to the definitive Journeys and Maps maps would probably be path of least resistance.

But thank you! This helped and makes sense.

Yeah, I need to adapt this for all the maps in Journeys and Maps. /sigh

Hang in there Glorelendil, once it's done it will be invaluable!

I'm currently revising my Fan Supplement to include Contents & an index, current estimate is nearly 400 pages! (Sigh)

Robin S

Glorelendil wrote:For any computer scientists out there, I'm going to need an algorithm that, given a contiguous and closed sequence of coordinates in a hex-shaped grid, determines if a cell represented by a pair of coordinates is inside enclosed by the sequence. (In other words, if regions are defined by their borders, test whether a hex cell is inside that region.) It should be as zippy as possible, so that I can iterate through all regions querying which one(s) the cell is in.

Alternatively, given the border, generate the list of all additional cells that are enclosed within that border.

I would think that the easiest method is a 2d array of tuplets...
struct TerrainTypeStruct
{
char Terrain;
char Region;
};

TerrainTypeStruct Map[100,300];

then access each by Map[x,y].Terrain and Map[x,y].region

One could also, given the ability to code bitwise, simply make it bitwise comparisons ... and only check on the routes.
Checking on the route should be faster than region checking...

I'm looking for one step before that, before all the tuples are known. Starting with just the border cells.

EDIT: Also, although I'm currently using the scheme you suggest, I'm going to have to alter it to accommodate individual hexes potentially belonging to multiple regions. Probably just put an array of pointers to region structs (or javascript equivalent anyway) in each slot.

Update: I'm rewriting the whole thing. Well, lots of copying and pasting, but better to start with a clean slate than try to fix the current mess.