IPVGO: Add support for highlighting nodes and adding small text

[ficocelliguy]

Adds new API methods to go.analytics to allow for adding colored indicators and/or text to nodes by player scripts.

Can be tested at https://ficocelliguy.github.io/bitburner-src/

My testing script that makes it rave mode:

/** @param {NS} ns */
export async function main(ns) {

  const boardSize = ns.go.getBoardState().length;

  while(true) {
    await ns.sleep();
    const x = (Math.random() * boardSize) | 0;
    const y = (Math.random() * boardSize) | 0;
    let color = "#";
    for (let j = 0; j < 6; j++) {
      color += [0,1,2,3,4,5,6,7,8,9,"a","b","c","d","e","f"][Math.random() * 16 | 0];
    }
    ns.go.analysis.highlightPoint(x, y, color, color);
  }

}

[paulcdejean]

I almost want to say skip the text arg, and just have it support colors tbh. But maybe that's just me being mean.

[ficocelliguy]

The text arg is for adding a point value or relative score or whatever other label, as seen in many of the move highlighters/visualizers players have homebrewed

[ficocelliguy]

@d0sboots Is there anything more you need for this one? a couple people have asked about the feature's status

[d0sboots]

the status is "i should feel bad"

[d0sboots]

No, now you went back to the other issue :(

The fundamental problem here is a muddying of the waters between boardState and the top-level state. The top-level state is a singleton which contains a single boardState, but this doesn't mean that boardState itself is a singleton. It is entirely possible for multiple boardStates to exist simultaneously, and indeed I believe this occurs when the analysis functions get involved with user-provided boards.

You can view the highlight info as either being a UI thing (thus belonging to the top-level state) or as belonging to boardState; both are valid perspectives. But if it's the former, then you can't change the UI just because a move was made on any board, it has to be only for moves made on the board of the top-level state. Conversely, if it belongs to boardState then clearAllPointHighlights also needs to belong to boardState. (It's OK for it to trigger GoEvents.emit even for boardStates that aren't being shown, since that's idempotent.)

[ficocelliguy]

I have refactored this so that the highlighting methods are standalone utilities under the analysis file, and they take a boardstate to add or remove highlights from. When a move is made or passed on a board, the highlights for that specific boar is cleared.

The netscript api access for these utilities applies them to the current ui by passing the current board state to these utilities.