Fix car tag rank emblems to use racer rank when segment numbering is disabled

[jamestford]

When car numbering by segment (hundreds place) is not enabled, car tags now use the racer's actual rank (Lion, Tiger, Wolf, Bear, Webelos, AOL) to determine which emblem to display, rather than defaulting to the car number hundreds digit which would show all racers with car numbers 1-99 as Lions.

This fix checks the car-numbering setting and:

• Uses rank name mapping when segment numbering is disabled
• Falls back to car number method when segment numbering is enabled
• Handles case-insensitive and plural rank names (Lions, Tigers, etc.)

Fixes issue where all racers showed Lion emblem despite being different ranks.

[jeffpiazza]

Thank you for investing the time to do this!

I infer that your pack races the whole pack as one group and wants to use car tags with images based on subgroup.

I think my preference would still be to base car tag image on the car number, and focus instead on numbering the cars with century values to reflect subgroup membership, as an alternative to basing them on groups.

It remains possible, if perhaps inconvenient, to number cars explicitly (e.g., by including car numbers in the imported roster), in which case the default numbering scheme wouldn't matter. Do you (or your pack) have any particular attachment to the current default numbering scheme?

When default numbering is used, presently the car number century is (optionally) based on group ordering; the idea would be to provide an alternative that uses the ordering of the subgroup.

Would this address your use case?

[jamestford]

Happy to do so, I hope to contribute more as I have time, so happy you have invested so much time to put this together for everyone.

Our pack races each rank prior to having a grand finals race but the century based numbering creates an issue for us at registration. We use pre-printed number stickers (1-100) at check-in since we don't have a printer available at the registration venue. The car tags are printed after registration at home and used to help with staging the next day. This means we can't easily assign rank-specific number ranges at registration - we just grab the next available sticker from the pack.

The change proposed does not remove century based image mapping, here is the current logic as written:
If car-numbering setting = 100 → use century-based (car number / 100) [Current Behavior]
Else → try rank name mapping first, fallback to century if no match [New Behavior]

So packs that want to use century numbering still can. Packs that can't (like ours with pre-printed stickers) now have an alternative. Would you be open to reconsidering the subgroup-based approach given this constraint? We're happy to refine the implementation if you have concerns about the current PR.

[jeffpiazza]

Thank you, you make a strong case why century-based numbering isn't the right thing, at least not always.

Reflecting on this a little more, it occurs to me that, in the default setting, the century is effectively conveying the group's sortorder value (or the sortorder - 1 if starting from 1). Instead of string matching against group names, I'd be much happier having an option that applies the sortorder value directly.

(Matching against group names doesn't work very well for non-Cub Scout groups, or even for Cub Scout packs that identify their fifth-graders as "Webelos II", say. By contrast, users can manipulate sortorder for groups, and thereby have control of the numbering without having to adopt compromised group names.)

I think that would address your pack's process, if you'd like to revise the PR.

[jamestford]

Jeff,

Got some time to look into this more and wanted to get your feedback before updating the implementation. Here is my current understanding of how it is working today.

Current implementation works like this:
$grade = intval($racer['carnumber'] / 100);

No conditions, no settings check. Just divide car number by 100.
Starting at 101 (default 100+101):
Sortorder 1 → cars 101-199 → intval(101/100) = 1 → 100-series.jpg
Sortorder 2 → cars 201-299 → grade 2 → 200-series.jpg
Sortorder 3 → cars 301-399 → grade 3 → 300-series.jpg
...and so on
000-series.jpg is never used (no cars 0-99)

Starting at 1 (configured as 100+1):
Sortorder 1 → cars 1-99 → intval(1/100) = 0 → 000-series.jpg
Sortorder 2 → cars 101-199 → grade 1 → 100-series.jpg
Sortorder 3 → cars 201-299 → grade 2 → 200-series.jpg
...shifts everything by one
Starting at 1 with no century numbering (0+1):
All cars are 1, 2, 3, 4... → intval(anything_under_100 / 100) = 0 for everyone
Every racer gets 000-series.jpg — same emblem for all

Known issues with upstream master's car tag emblem selection (intval(carnumber / 100)):

1. Partition import order is arbitrary — partitions are created in the order ranks first appear in the spreadsheet, not the expected rank progression. This means the wrong rank gets the wrong century of car numbers, and therefore the wrong emblem.

2. Starting at 1 instead of 101 shifts all emblems by one — the first partition gets cars 1-99 → 000-series, the second gets 101-199 → 100-series, etc. Different mapping than starting at 101, so the same image set gives different results depending on this setting.

3. Flat numbering (1-100) is completely broken — every car number is under 100, so intval(n/100) = 0 for all racers. Everyone gets 000-series — the same emblem regardless of rank.

Utilizing your suggestions on updating the PR to use sortorder-based emblem selection addresses some issues but would still leave the following unaddressed:

1. Import order problem remains — partitions are still created in whatever order ranks appear in the spreadsheet, so sortorder won't match the image set unless the user manually reorders partitions.

2. Flat numbering (1-100) depends on user knowing to reorder — sortorder would now drive the emblem instead of car number math (which is an improvement over everyone getting the same image), but only if the user gets the partition order right.

3. Reordering partitions after car numbers are assigned creates a mismatch — car numbers stay as 1xx, 2xx, etc. from the original order, but the emblem now follows the new sortorder. The printed car number and the emblem no longer correspond.

Before proceeding wanted to get your thoughts on this. My thinking would be to decouple car numbering from group emblem, then you would not have to worry about reordering groups breaking things, car numbering scheme would not matter, and the import order would not matter. As you have a much wider understanding of the user base wanted to run these questions by you for a better understanding.

[jeffpiazza]

I think you probably have a good handle on how things work currently, for the most part.

As you know, car tag emblem selection is currently based on the hundreds digit of the car number. That works for many common cases, but may not give especially desirable results for others, particularly when car numbering isn't based on racing group, or racing groups don't map one-to-one with emblems (e.g., two dens for the same grade). Tag emblems based on car number can be turned off altogether, resulting in still-useful car tags.

Sort order for groups and subgroups is under the user's control. It's possible to define group and subgroup names (and sort order) before importing a spreadsheet of racers, including by importing a prefs file; users can sort their spreadsheet before importing to induce a desired ordering; and they can reorder groups and subgroups after importing.

Car numbering is similarly under the user's control: the rule for auto-numbering can be set before importing; car numbers can be included in an imported roster spreadsheet, and/or the spreadsheet can be sorted to affect assigned car numbers; and bulk renumbering can update car numbers to reflect group sort order, especially after changing the group or subgroup sort order. Whether car numbers do or don't convey information about the racing group (i.e., whether a "mismatch" is a problem) is up to the user.

My thinking would be to decouple car numbering from group emblem, then you would not have to worry about reordering groups breaking things, car numbering scheme would not matter, and the import order would not matter.

The "decouple" part I think is what we're after, or at least supporting an alternative strategy (i.e., not basing the emblem ONLY on car number). The details of this matter quite a bit, though, so I'd like to hear what you have in mind before getting a PR.

[jamestford]

Jeff, here's what I have in mind, framed from the end user's perspective:

The typical workflow:

1. A pack leader imports a spreadsheet with racer names and den names (Lion, Wolf, Bear, Tiger, Webelos, AOL)
2. They select the "Cub Scouts" image set
3. They print car tags and expect each racer's emblem to match their den

The proposal: match the emblem to the den name using named image files.

The lookup in path_to_century_emblem() would become a fallback chain:

1. Try image_file_path("centuries/" . $partition_name) — look for an image named after the den (e.g., centuries/Wolf.jpg)
2. If no match, fall back to car number math (intval(carnumber / multiplier)) — preserves existing behavior

Why den name instead of car number or sortorder:

The emblem represents the den — not the car number and not the racing group. When a pack merges Lions and Tigers into one racing group so they race together, a Lion should still get the Lion emblem and a Tiger should still get the Tiger emblem. The den identity (partition) survives racing group restructuring, so the emblem stays correct regardless of how groups are organized.

This also means:

• Car numbering scheme doesn't matter — whether they use century numbering (101+), start at 1, or use flat 1-100 numbering, the emblem follows the den name, not the car number
• Import order doesn't matter — the emblem isn't tied to sortorder, so it doesn't matter what order dens appear in the spreadsheet
• Reordering groups doesn't break emblems — changing the racing group structure or sortorder has no effect on emblem assignment

Changes needed:

• Add named image files to the Cub Scouts image set alongside the existing numbered files, including common variations:
  • Lion.jpg, Lions.jpg
  • Tiger.jpg, Tigers.jpg
  • Wolf.jpg, Wolves.jpg
  • Bear.jpg, Bears.jpg
  • Webelos.jpg
  • AOL.jpg, Arrow of Light.jpg
• Update path_to_century_emblem() to try the name-based lookup first
• Existing numbered files remain for backwards compatibility

For non-standard den names: The existing image_file_path() search hierarchy already supports per-event overrides — a pack can place a custom image (e.g., Webelos II.jpg) in their event imagery directory ($homedir/imagery/centuries/) and it takes priority. This doesn't require modifying the shipped image sets.

Tradeoffs:

• If a user renames a den after import to something that doesn't match an image file, the fallback to car number math kicks in — which is the same behavior as today
• Shipping common name variations (plural forms, abbreviations) covers most cases but won't cover every possible naming convention

Use case: Custom racing groups

A common scenario is merging smaller dens into combined racing groups so they have enough racers to race together:

In this configuration:

• Racing Group 1: Wolf (11 racers) + Tiger (13 racers)
• Racing Group 2: Lion (11 racers) + AOL (9 racers)
• Racing Group 3: Bear (14 racers) + Webelos (13 racers)

With the den name approach, even though Wolf and Tiger are now in the same racing group, each racer keeps their den-specific emblem:

• A Wolf racer → partition is still "Wolf" → matches centuries/Wolf.jpg → Wolf emblem ✓
• A Tiger racer → partition is still "Tiger" → matches centuries/Tiger.jpg → Tiger emblem ✓

The racing group structure has no effect on emblem assignment because the emblem follows the den (partition), not the group.

Would this approach work for you?

[jeffpiazza]

I think we're in alignment that the choice of emblem should be based on the partition (or group or subgroup). Until now, that mapping has been expressed indirectly through the car numbering, but that doesn't work for everyone. You've succeeded at convincing me that the existing car number-based mechanism needs replacing.

Expressing the mapping to emblem by matching file names isn't the worst idea, but still seems awkward to me. I'm not very keen on the idea of duplicating emblem files just so they can match more names (the files are admittedly not large, but still), and I'm concerned that it leaves users having to manipulate image files if they change the names of their divisions.

I think instead that the way forward involves being able to assign emblem images to partitions or groups, similar to the way racer or car photos are assigned to individual racers. That would involve a schema change (to carry the emblem file name in the partition, group, or subgroup) and some sort of UI allowing assignment of images to divisions, probably somewhere in the Racing Groups page.

I expect that means the existing image files would get renamed from their current x00-series pattern, and then either the century-to-image mapping is made editable, somehow, or the use of car numbers for choosing emblems gets abandoned altogether.

Having different file names in different image sets then presents the possibility that changing image sets invalidates the images assigned from a different image set, but I'm not sure that's avoidable. There's also a question of what to do for partitions which don't have an emblem explicitly assigned.

I think all of the above probably takes this issue out of the realm of a simple pull request to add a missed feature.

[dlucatorta]

When we run our races we always have Adults, Siblings, and Troop so it would be nice to have an image set for them as well.

On Mon, Mar 16, 2026, 1:31 PM Jeff Piazza ***@***.***> wrote: *jeffpiazza* left a comment (jeffpiazza/derbynet#415) <#415 (comment)> I think we're in alignment that the choice of emblem should be based on the partition (or group or subgroup). Until now, that mapping has been expressed indirectly through the car numbering, but that doesn't work for everyone. You've succeeded at convincing me that the existing car number-based mechanism needs replacing. Expressing the mapping to emblem by matching file names isn't the worst idea, but still seems awkward to me. I'm not very keen on the idea of duplicating emblem files just so they can match more names (the files are admittedly not large, but still), and I'm concerned that it leaves users having to manipulate image files if they change the names of their divisions. I think instead that the way forward involves being able to assign emblem images to partitions or groups, similar to the way racer or car photos are assigned to individual racers. That would involve a schema change (to carry the emblem file name in the partition, group, or subgroup) and some sort of UI allowing assignment of images to divisions, probably somewhere in the Racing Groups page. I expect that means the existing image files would get renamed from their current x00-series pattern, and then either the century-to-image mapping is made editable, somehow, or the use of car numbers for choosing emblems gets abandoned altogether. Having different file names in different image sets then presents the possibility that changing image sets invalidates the images assigned from a different image set, but I'm not sure that's avoidable. There's also a question of what to do for partitions which don't have an emblem explicitly assigned. I think all of the above probably takes this issue out of the realm of a simple pull request to add a missed feature. — Reply to this email directly, view it on GitHub <#415 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOSB7ULU6PMDRPLLTGCUQ6T4RBCBDAVCNFSM6AAAAACUVIRUCSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRZG42TIMBUGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Deron Lucatorta 314-346-4759 ***@***.*** P *Please consider the environment before printing this email.*

[jamestford]

I think with a larger feature like this we have the opportunity to simplify the end user experience and enhance the functionality for all users. Should we close this PR and migrate this to an issue request to hammer out the requirements and gather input from others? And do we want to include backwards compatibility as part of the requirement or assume that with the new feature we will not need to fallback to century based assignment?

Forgot to add that I'd be happy to handle this feature.

DRAFT-ISSUE.md