Comments by FergusDuniho

I am still confused. How do I execute the postgame handler (whiteFirstTurn) for a second time?

See the Post-Move code for Musketeer Chess to get some idea of how it can be done.

Each begins with a series of if and elseif conditions to check the value of thismove or movenum. Post-Game 2 first checks whether thismove is null, because at the very beginning of the game, it is effectively at the end of the second player's turn. This is because each subsequent time it is the first player's turn to move, it will be after the second player has moved, which is the normal time to run Post-Game 2. This means that the first Post-Game section to run will be the second, not the first.

However, Musketeer Chess does things in a more complicated way than your game. Before it lets you place both extra pieces on the same move, it has each player select one of the pieces. First White selects one, and Black gets the same piece, and then Black selects one and White gets the same piece. After this stage, it moves the selected pieces to the center of the board, and each player gets to place them. First White moves each piece, and then Black does.

So we need to jump ahead to this stage to see what is being done. For White, this is done with this code in Post-Game 2:

elseif == movenum 2: // White's 2nd move
  if not empty d4 and not empty e4:
    setlegal d4 a0 b0 c0 d0 e0 f0 g0 h0;
    setlegal e4 a0 b0 c0 d0 e0 f0 g0 h0;
    end;
  else:
    if not empty e!9:
      set legalto (b9 c9 d9 f9 g9);
      remind "Since you placed your first piece behind your King, the second may not go behind a Rook.";
    elseif not empty a!9:
      set legalto (b9 c9 d9 f9 g9 h9);
      remind "Since you placed your first piece behind a Rook, the second may not go behind your King.";
    elseif not empty h!9:
      set legalto (a9 b9 c9 d9 f9 g9);
      remind "Since you placed your first piece behind a Rook, the second may not go behind your King.";
    else:
      set legalto (a9 b9 c9 d9 e9 f9 g9 h9);
    endif;
    set f cond empty d5 e5 d5;
    foreach c var legalto:
      if empty realname #c:
        setlegal #f #c;
      endif;
    next;
    end;
  endif;

If White has not moved either piece, it sets legal moves for White. Otherwise, it sets legal moves for Black. But why does it work this way? Post-Move 2 normally runs after a move by the second player. If no moves have been made, this is normally the start of the first player's turn, and it will calculate legal moves for the first player. But when a move has already been made, this is a continuation of a move by the second player. In that case, it needs to calculate the moves for the second player.

When handling gating on the first move instead of the second, code like this may be more appropriate:

elseif == thismove null: // White's ist move
  setlegal d4 a0 b0 c0 d0 e0 f0 g0 h0;
  setlegal e4 a0 b0 c0 d0 e0 f0 g0 h0;
  end;
elseif == movenum 1: // Second part of Black's move
    if not empty e!9:
      set legalto (b9 c9 d9 f9 g9);
      remind "Since you placed your first piece behind your King, the second may not go behind a Rook.";
    elseif not empty a!9:
      set legalto (b9 c9 d9 f9 g9 h9);
      remind "Since you placed your first piece behind a Rook, the second may not go behind your King.";
    elseif not empty h!9:
      set legalto (a9 b9 c9 d9 f9 g9);
      remind "Since you placed your first piece behind a Rook, the second may not go behind your King.";
    else:
      set legalto (a9 b9 c9 d9 e9 f9 g9 h9);
    endif;
    set f cond empty d5 e5 d5;
    foreach c var legalto:
      if empty realname #c:
        setlegal #f #c;
      endif;
    next;
    end;
  endif;

Note that this is just a modification of the Musketeer Chess code, which has not been finetuned for your game, and which has not been tested.

Accordingly, the second part of White's turn is handled in Post-Game 1 with this code:

elseif == movenum 2: // Second part of White's Second Move
  set f cond empty d4 e4 d4;
  if not empty e!0: 
    setlegal #f b0 c0 d0 f0 g0;
    remind "Since you placed your first piece behind your King, the second may not go behind a Rook.";
  elseif not empty a!0:
    setlegal #f b0 c0 d0 f0 g0 h0;
    remind "Since you placed your first piece behind a Rook, the second may not go behind your King.";
  elseif not empty h!0:
    setlegal #f a0 b0 c0 d0 f0 g0;
    remind "Since you placed your first piece behind a Rook, the second may not go behind your King.";
  else:
    remind "Place your piece on" #f "behind your back rank.";
    foreach x range a h:
      set t join #x !0;
      if empty #t:
        set t join #x 0;
        setlegal #f #t;
      endif;
    next;
  endif;
  end;

Unlike the section that dealt with the second part of Black's move, this just calculates legal moves for White. Note that the movenum value it checks for is the same in each case. For White, it is the same move whether at its start or continuing it.

Since we already saw how Black's move is continued, let's look at how it begins. It begins with this code in Post-Game 1:

elseif == movenum 3: // Black's Second Move
  setlegal d5 a9 b9 c9 d9 e9 f9 g9 h9;
  setlegal e5 a9 b9 c9 d9 e9 f9 g9 h9;
  end;

I'm not sure why it would begin on a later move number than it would continue on. Maybe I included some extraneous code that doesn't do anything. Looking at Post-Game 2, I see this code for continuing Black's move:

elseif == movenum 3: // Second Part of Black's Second Turn
  set f cond empty d5 e5 d5;
  if not empty e!9: 
    setlegal #f b9 c9 d9 f9 g9;
    remind "Since you placed your first piece behind your King, the second may not go behind a Rook.";
  elseif not empty a!9:
    setlegal #f b9 c9 d9 f9 g9 h9;
    remind "Since you placed your first piece behind a Rook, the second may not go behind your King.";
  elseif not empty h!9:
    setlegal #f a9 b9 c9 d9 f9 g9;
    remind "Since you placed your first piece behind a Rook, the second may not go behind your King.";
  else:
    remind "Place your piece on" #f "behind your back rank.";
    foreach x range a h:
      set t join #x !9;
      if empty #t:
        set t join #x 9;
        setlegal #f #t;
      endif;
    next;
  endif;
  end;

This is mostly the same as the code for Black found with "White's 2nd Move". I'll do some tests later to see if I can remove the other code.

For some reason, I have code for continuing a partial move only in Post-Game 1:

elseif == movenum 4: // White
  if not empty e5 or not empty d5:
    continuemove;
  endif;

Investigation reveals that I am also using continuemove in the Post-Game sections. So things are just getting more complicated. White's placing move is handled with this code in Post-Game 1:

elseif == turn 2: 
  restore premove;
  set mvs explode chr 59 thismove;
  eval join "MOVE: " trim elem 0 mvs;
  if and != origin d4 != origin e4 or != rankname dest !0:
    die All you may do right now is place an extra piece behind your back rank.;
  endif;
  if > count var mvs 1:
    eval join "MOVE: " trim elem 1 mvs;
    if and != origin d4 != origin e4 or != rankname dest !0:
      die All you may do right now is place an extra piece behind your back rank.;
    elseif not empty a!0 or not empty h!0 and not empty e!0:
      die You may not place your pieces behind a King and a Rook.;
    endif;
    foreach f range a h:
      set c join #f "!0";
      if empty #c:
        delete #c;
      endif;
    next;
  remind "Now that you have placed your extra pieces behind your back rank, the remaining spaces behind it have been deleted.";
  else:
    continuemove;
  endif;
  return;
endif;

Note that it is restoring the position, parsing thismove into separate moves, executing each one individually, and testing it for legality. It does not evaluate either move until both have been made. If only one has been made, it uses continuemove.

In a similar manner, Black uses this code to evaluate the placing move in Post-Game 2:

elseif == turn 2:
  restore premove;
  set mvs explode chr 59 thismove;
  eval join "MOVE: " trim elem 0 mvs;
  if and != origin d5 != origin e5 or != rankname dest !9:
    die All you may do right now is place an extra piece behind your back rank.;
  endif;
  if > count var mvs 1:
    eval join "MOVE: " trim elem 1 mvs;
    if and != origin d5 != origin e5 or != rankname dest !9:
      die All you may do right now is place an extra piece behind your back rank.;
    endif;
    foreach f range a h:
      set c join #f "!9";
      if empty #c:
        delete #c;
      endif;
    next;
    setsystem originalpieces piececount;
    remind "Now that you have placed your extra pieces behind your back rank, the remaining spaces behind it have been deleted.";
  else:
    continuemove;
  endif;
  return;
endif;

I suppose you meant to write Post-Game code here?

Yes, I did. I have now corrected this. In your last sentence, you said Pre-Game code. Did you mean Post-Game code?

The code for continuemove is just a series of variable assignments, which by itself doesn't give much hint about how it should be used.

case "continuemove": // Allow multi-part move to be made with mouse/touch
case "redomove": // Allow player to redo illegal move
  if ($submit == "Preview")
    $submit = "";
  $pastmovesfield = ($args[0] == "redomove") ? "" : $moves;
  $movelist = $oldmovelist;
  $movenum = max($movenum - 1, 0);
  if (!$switchsides) {
    $side = $turnorder[$movenum % $sidecnt];
  }
  else
    $side = $turnorder[($sidecnt - 1) - ($movenum % $sidecnt)];
  break;

So, the main thing to consider is which variables are changing and how they are used. Changing the value of $submit changes which form_* script it includes when it loads the page after submitting a move. With a value of "Preview", it would include form_verify.php for showing a preview of the move and asking the player to confirm it. With an empty value, it will include form_move.php again. If you were playing by yourself in solitaire mode, it would not have to change the script it includes.

$pastmovesfield is for populating a form field that gets used for multi-part moves. So that the moves field works the same as it would for single moves, it starts out empty, and the previously entered moves go in a different form field.

$movelist is a string listing every move in the game on a separate line, sometimes with comments interspersed. $oldmovelist was set to $movelist just before appending the latest move to it. So this sets $movelist to what it was before the partial move that was already made was made. Once the full multi-part move has been made, it will be appended to $movelist as a single string.

$movenum is the number of the latest move. Since it would normally be incremented at the end of a complete move, it is decremented to keep it the same, though it is not allowed to go below zero.

$side indicates the side of the player who can move. This would normally switch to the other player at the end of a turn. But when continuing a move, it should not change to the other player. It gets the value of $side from a list of players whose identifiers in the game are values in the $turnorder array. It does this instead of switching a flag back and forth, because I wanted to add support for multi-player games and games with alternate turn orders, but that project is not complete, because some code in Game Courier just assumes a two-player game with alternating turns.

$switchsides has to do with the orientation of the board. It defaults to 0, which means that the board should be shown from the perspective of the player whose turn it is to move. Setting it to a non-zero value would cause the board to stay in the same position no matter whose turn it is. Since this is only a cosmetic difference, I'm not sure why it should have any bearing on whose side it is. So I'll experiment with whether giving $switchsides a non-zero value will mess up how a multi-move game operates.

The assigned variables mainly affect the form the player gets after completing the first part of a multi-part move, and they have nothing to do with the evaluation of a move, which is what the Post-Move code is supposed to handle. Given the purpose of this command, it should not be executed more than once during a whole series of moves, and it should not be executed for any past moves. In fact, calling it more than once could result in the wrong value for $movenum. So, it makes sense to reserve its use for the Post-Game code. In my code for Extra Move Chess, it is used after calculating the legal moves for the second part of the turn.

Per HG's suggestion!

No, he suggested you use it in your handling routines, but these are in your Post-Move code. So what I'm telling you is contrary to his suggestion.

In what I'm doing now continuemove does nothing. Any idea why?

The Developer’s Guide says to use it only in the Post-Game code, but you are using it in the Post-Move code.

It's the "set many" line that is causing the screen to go blank.

Technically, it was a bug in the line calling the error function that was causing it to go blank, as I had omitted the second argument for the line number. I have now fixed that so that if you use "set many" with an odd number of arguments, it will now give you a helpful error message instead of a blank screen.

The problem is that "set many" does not work with expressions. Each value assigned to a variable must be a scalar value or a variable value.

More precisely, "set many" does not natively work with expressions, and for a long time it just did not work with them. But if an expression is placed in braces, it will now be evaluated during preprocessing of the line. So this works:

set many ok 1 promo 0 ori #source1 desti #dest1 mover {space #dest1};

As a test of what I'm talking about, try echo with an expression and with the same expression between braces, like so:

echo + 8 9;
echo {+ 8 9};

The first line prints "+ 8 9", and the second prints 17.

It's the "set many" line that is causing the screen to go blank. I modified your code to this, and the screen went blank after I moved one Black piece.

sub blackInitialHandle:
 set tm thismove;
 set source1 join char thismove 2 char thismove 3;
 set dest1 join char thismove 5 join char thismove 6 char thismove 7;
 set source2 join char thismove 11 char thismove 12;
 set dest2 join char thismove 14 join char thismove 15 char thismove 16;
 move #source1 #dest1;
 move #source2 #dest2;
 set many ok 1 promo 0 ori #source1 desti #dest1 mover space #dest1;
die "ok: " #ok "promo: " #promo "ori: " #ori "desti: " #desti "mover: " #mover;
endsub;

The problem is that "set many" does not work with expressions. Each value assigned to a variable must be a scalar value or a variable value. When I changed your code to this, it did work:

sub blackInitialHandle:
 set source1 join char thismove 2 char thismove 3;
 set dest1 join char thismove 5 join char thismove 6 char thismove 7;
 set source2 join char thismove 11 char thismove 12;
 set dest2 join char thismove 14 join char thismove 15 char thismove 16;
 move #source1 #dest1;
 move #source2 #dest2;
 set many ok 1 promo 0 ori #source1 desti #dest1;
 set mover space #dest1;
endsub;

However, since it handled only one piece at a time, there are still pieces in the middle of the board, and they are now able to move normally, which is not what you want.

I get a blank screen after this instruction.

I modified blackInitialHandle like so to return some values before things go wrong.

sub blackInitialHandle:
 set tm thismove;
 set source1 join char thismove 2 char thismove 3;
 set dest1 join char thismove 5 join char thismove 6 char thismove 7;
 set source2 join char thismove 11 char thismove 12;
 set dest2 join char thismove 14 join char thismove 15 char thismove 16;
die "tm: " #tm "s1: " #source1 "s2: " #source2 "d1: " #dest1 "d2: " #dest2;
 move #source1 #dest1;
 move #source2 #dest2;
 set many ok 1 promo 0 ori #source1 desti #dest1 mover space #dest1;
endsub;

Here are the values I got:

tm: g e7-d11 
s1: e7 
s2: 
d1: d11 
d2:

I broke it into multiple lines so that you can clearly see that source2 and dest2 have no values.

So far, your code is not set up to handle two moves on the same turn. When I moved one White piece, it immediately changed sides for me to move a Black piece.

For a second test, I moved the die command down two lines to see if "move #source2 #dest2;" was the problem. Since the die command still worked, I assume something happened in HG's code.

That would indeed be an alternative: do a full king-capture test after every King move. But it would be more expensive, as a King usually has several moves.

It's more than that. I do a full king-capture test for every pseudo-legal move by every piece that can move. My code works like this.

1. It goes through every piece from the side that can move.
2. For each piece on the side that can move, it calculates the spaces within its range of movement. This is an optimization to keep it from checking for legal moves to every position on the board.
3. For each space within a piece's range of movement, it checks whether the piece has a pseudo-legal move there.
4. For each pseudo-legal move, it tries the position and checks whether it places the King in check.
5. It checks whether the King is in check by checking whether any enemy piece can move to the King's space. As an optimization, it returns true as soon as it finds one check.
6. It checks whether a piece may move to the King's space by calling its function for the move from its location to the King's space.
7. Divergent pieces are handled by writing them to behave differently when the movetype variable is set to CHECK. In the following example, the function for the White_Pawn first checks some conditions any Pawn move must meet, then handles capturing, then continues to handle non-capturing and en passant moves only if movetype is not CHECK.

def White_Pawn
remove var ep
and < rankname #1 var bpr
and < rankname var ep rankname #1
and == filename var ep filename #1
and checkleap #0 #1 1 1
and var ep
or and checkride #0 #1 0 1 == rankname #0 var wpr
or checkleap #0 #1 0 1
and empty #1
and != var movetype CHECK
or and islower space #1 checkleap #0 #1 1 1
and any onboard where #1 0 1 == var movetype CHECK count var wprom
and <= distance #0 #1 var fps
and > rank #1 rank #0;

8. Pieces with non-displacement captures are handled by writing two different functions for them and using the value of movetype to call the correct function.

So you would have to do enemy move generation several times.

Since my code uses piece functions, this is not a big problem. In tests I ran yesterday, my checked function ran 1000 times in under half a second, and the checked subroutine got called 1000 times in close to a second, and this was on a position in which the King was not in check, which meant it never broke out early. Since your code does not use piece functions, it may handle the evaluation of moves more slowly, which will also cause it to evaluate check more slowly.

Testing whether a destination contains the King is not any more expensive than marking the destination. And to do it, you only need to geenrate all enemy moves once.

This optimization might be helpful when not using piece functions, but one thing about it concerns me. While it might be helpful in determining whether a move by the King would be into check, I'm not sure it will work for revealed checks. It is because of the possibility of revealed checks that my code checks for check for the position resulting from every single pseudo-legal move it finds.

I suppose one optimization that could be made if it were needed would be to identify the pieces that might possibly check the King at its current location, then limit the test for whether a move by another piece places the King in check to those pieces. This could be done by making a short list of every enemy piece whose range of movement contains the King's location and having the checked function use it instead of onlyupper or onlylower. If this list were empty, it could even skip the step of trying out a pseudo-legal move and testing whether it places the King in check.

However, this might not work for non-displacement captures in which the capture occurs outside the piece's range of movement, such as the Coordinator capture in Ultima. So, I have to balance efficiency with the work a programmer has to make to use a piece in a game. The brute force method I use helps reduce the work the programmer has to do to make different kinds of pieces work with it.

The issue was that the test for being already in check was done with the King taken off the board

Why would you take the King off the board for this? Couldn't this cause false positives and false negatives from divergent pieces like Pawns or Cannons?

This was a bug that did not yet express itself. A Checker diagonally adjacent to the enemy King would not deliver check if a friendly piece was immediately behind that King, blocking the landing square. But that blocking piece would then essentially be pinned, and its moves should not be highlighted.

The code I use avoids this by trying each pseudo-legal move and checking whether any piece in the new position is checking the King.

I got your diagram to display correctly and added it to the page with some modifications. To make the board display correctly without tiling, I removed the firstRank assignment and set borders to 0. I replaced the graphics with ones I created for Smess. The board is a stretched version of one I made for Game Courier, and the pieces are the ones I made for Storm the Ivory Tower, which have smoother edges. I set useMarkers to 1 to stop it from changing the background color of a space when highlighting it, but this doesn't work for moves made by the opponent. Since it is important to not hide the arrows on the board, it would be helpful if useMarkers would also change how the opponent's moves are highlighted.

I created and used a new board with 83x83 spaces, and I set squareSize to 83, but now the board is starting halfway into the first rank and tiling on the right side. What can I do to fix that?

I changed the board image to the one that goes with the pieces, and it looks a lot better, but there are still some alignment issues. The spaces on the board are rectangular with a width of 83 and a height of 73, but the squareSize parameter seems to expect one value that gets used for both height and width. Is there any way to specify height and width separately? In the meantime, I'll make a resized copy of the board with square spaces.

Also, I added the same code to the Smess diagram, and it is now tiling with the pieces on it. Since I made those pieces for a larger board, I think the board image and the pieces are not at the same scale.

For some reason this does not work anymore. The I.D. on the Eurasian Chess page also lost its background, and I am sure this worked before. Is there some global style definition now that gives elements a background color?

Looking at it with Web Developer Tools in Firefox, I see that TABLE TR has the background-color value of var(--nav-bgcolor), and when I turn it off, the background image shows up. With that in mind, I added this to the Eurasian Chess page, and that fixed it:

<STYLE>
TABLE#board0 TR {background-color: inherit;}
</STYLE>

Would it be a good idea to add this to global.css?

Yes, I originally would have thought when an Advancer made a move that threatened a King, an enforcing preset would automatically announce check.

However, maybe the Advancer, being an Ultima-like piece, does not actually make a check in an Ultima-like game (which Butterfly Chess is not)?

So I now ask, is that the usual assumption that Applet generated preset code makes for every CV put through the generating process?

I don't know how a generated preset works, but the checked subroutine I use in the fairychess include file normally checks for captures by displacement by checking if each enemy piece on the board can move to the King's position. This would not normally work with Ultima pieces, which do not normally capture by displacement, but I have managed to use this subroutine with Ultima without modifying it. First, let's look at the subroutine:

sub checked king:
    my from piece;
    local movetype;

    set movetype CHECK;
    if isupper cond empty var king $moved space var king:
        def enemies onlylower;
    else:
        def enemies onlyupper;
    endif;
    for (from piece) fn enemies:
        if fn const alias #piece #from var king:
            return #from;
        endif;
    next;
    return false;
endsub;

The key to working with Ultima is that it sets movetype to CHECK. With this in mind, I have written functions for Ultima pieces like this:

def Black_Withdrawer fn join "Black_Withdrawer_" var movetype #0 #1;

Depending upon the value of movetype, it will call either Black_Withdrawer_MOVE or Black_Withdrawer_CHECK, which I have defined separately and differently. Thanks to setting movetype to CHECK, the checked subroutine will use the *_CHECK functions for Ultima pieces. Instead of going through a normal move, one of these functions will check whether the piece at the first coordinate can capture the piece at the second. For example:

def Black_Withdrawer_CHECK 
empty where #frm - file #frm file #to - rank #frm rank #to
and == distance #frm #to 1
and not near #frm I 1
=frm =to;

This first makes sure that the piece is not next to a White Immobilizer (designated as I). It then verifies that the two spaces are adjacent. Calculating the direction away from the piece at #to, it checks whether there is an adjacent empty space in that direction. If there is, it returns true.

That is precisely why!

But it fails to do it.

Calling an inverse king symbol 'Man' goes against the grain.

Why use an inverse King symbol when one of your goals is to make it clear that this piece does not have the same status as a King?

In the selection table of the PTA, 'Kinginv' appears under the heading 'name'.

In that table, the name of any piece without a Betza code provided for it appears to be based on the file name.

My impression is that it's an icon name, not a piece name.

Yes, it means inverted King, which is exactly what the image is of.

I wanted to keep the term king, because it's a piece that can move like a king, but without the status.

But Kinginv is not a word, and the name suggests something that may still have the status of a King. I would mention the common names, but Bn Em already did that.

Your link is missing a query string.

I have changed forpersonid to author in the link, and it now works.

Hey! New month started!

Oh, right. I was focused on updating the color schemes. I should exercise now, but I'll remember to do this soon.

On the page /index-test.html, I have augmented the CSS implementation of the color schemes with a JavaScript implementation. The CSS implementation works without JavaScript, but it requires the use of :has(), which earlier browsers do not support. The JavaScript implementation is working on both my Kindle browser and on both Chrome and Edge on my iPad 2, though the latter two require you to save your change before it takes effect. I don't think there are browsers more primitive than these that still need to be supported. By providing both a CSS and a JavaScript way to change the color scheme, this expands the number of browsers it will work well on. I plan to add the code for this to the site tomorrow. In the meantime, try it out and let me know how it works for you, particularly if you have some older device I am not using.

I fixed the PHP script behind this page to display the description, rules, and credits for this page, but it could not find some of the expected files.

There were a few lines of code that were held over from an earlier version of the code, and these lines used an undefined variable. The result was $itemid being set to just "MS". Removing these lines of code fixed the problem.

I have not located the page mentioned in your screenshot. What is its URL? If you were attempting to create a new page, please make that clear. I need every relevant detail when you make a bug report.

Hey, it seems like both logos in dark & darker mode have the same silver moon image in them.

They do not. One is from the Motif Shogi set, and one is from the Symbolic Shogi set.

Can I suggest one replacement in darker logo? – change moon to khon:

No, the moon, as a symbol of the night, is representative of the color scheme. But I might replace it with another moon-themed piece, such as the Alfaerie Mage. Then I might replace another piece with a Kanji Shogi piece.

This should be fixed now.

As it happens, two of the options I would've given over Champion are Cardinal and Camel.

I have avoided using Cardinal or Chancellor for C, because the Cardinal is also known as an Archbishop, Princess, Paladin, and other names, and the Chancellor is also known as Marshall, Empress, and other names. I was initially using the Alfaerie Camel, but in looking over your pieces, I decided I liked your Champion better than the Alfaerie Champion.

And since I'm mentioning it, where you put the Fortress I would've suggested something more whimsical or offbeat:

I was going for something more suggestive of a Chess variant piece when seen out of context. A doubled-up Rook is one of those obvious designs that you, Jean-Louis Cazaux, and Musketeer Chess have all used.

The champion and phoenix were chosen to help spell cvp.

I have added new logos for the Darker color scheme. They feature a black cannon and a natural colored nightrider in the style of a winged horse. In the big logo on this page, the cannon was designed by Jean-Louis Cazaux and the nightrider by Bob Greenwade.

I followed the link to your thingiverse profile, but I didn't see all the pieces you have posted images of here in your comments. The closest I found to a Nightrider was the Zebrarider.

I figured out that you're packaging multiple pieces together, and I have to browse through each package to see them all.

I think I can work with the 3dviewer.net website, but I don't have a link to Bob's thingiverse account. Considering how many 3D pieces he designs, it would be a good idea for him to include a link to it in his profile.

Hopefully, brown works at least a little better.

It doesn't. The coloring is very splotchy, though more so on curved surfaces than on flat surfaces, as can be seen in this color image of a color scan of my Likebook Mars: