Prototype var-based filtering

[syrifgit]

Huzzah, it works. Likely not merge ready, but just for you to see what the prototype looks like.

Testcase: Dropping bones every tile while turning pray on/off

Proof that var changes are working, even though no access to leagues world.

Questions for you

varexpr in preamble

Should common transforms (bit0-bit31) be defined in preamble.rs2f so all filters can use them? Or left to filter authors?

Newline termination

Does varexpr bit9: v >> 9 & 1 end at newline, or need a ;? Currently it just reads tokens until it hits something that's not a bitwise op, which works but isn't explicit.

Operator precedence

Left-to-right chain (how it's implemented now) or C-standard (>> before & before |)? Current behavior: v >> 9 & 1 = (v >> 9) & 1 which happens to be the same either way, but v & 3 | 4 would differ.

Testing filter used.

meta {
  name = "Var Condition Test";
  description = "Tests varexpr/var/varbit conditions using toggleable game state. Toggle quick prayers and run to see changes live.";
}

// === TRANSFORM DECLARATIONS ===
varexpr bit0: v & 1
varexpr bit1: v >> 1 & 1
varexpr bit2: v >> 2 & 1

// === Controllable varbits ===
// Varbit 4103 = QUICKPRAYER_ACTIVE (toggle via prayer orb)
// Varbit 25   = STAMINA_ACTIVE (drink a stamina pot, or 0 if none active)

// === TEST 1: varbit true/false ===
// Bones highlight GREEN when quick prayers are ON, no highlight when OFF
apply (id:526 && varbit:4103) {
  color = GREEN;
  showLootbeam = true;
  lootbeamColor = GREEN;
}

// === TEST 2: negated varbit ===
// Feathers highlight RED when quick prayers are OFF, no highlight when ON
apply (id:314 && !varbit:4103) {
  color = RED;
  showLootbeam = true;
  lootbeamColor = RED;
}

// === TEST 3: varbit with transform ===
// Quick prayer varbit is 0 or 1. bit0 extraction should behave the same.
// Coins highlight CYAN when quick prayers are ON
apply (id:995 && varbit:bit0 4103) {
  color = CYAN;
  showLootbeam = true;
  lootbeamColor = CYAN;
}

// === TEST 4: varp with bit extraction (combat achievements) ===
// Varp 3116 = first combat achievement varp (32 tasks packed)
// Iron arrows highlight MAGENTA if combat achievement task 0 is complete
apply (id:884 && var:bit0 3116) {
  color = MAGENTA;
}

// Bronze arrows highlight YELLOW if task 1 is complete
apply (id:882 && var:bit1 3116) {
  color = YELLOW;
}

// === TEST 5: negated varp bit (incomplete task pattern) ===
// Raw trout highlights WHITE if combat achievement task 2 is NOT complete
// This is the exact pattern for leagues: highlight items for incomplete tasks
apply (id:335 && !var:bit2 3116) {
  color = WHITE;
  showLootbeam = true;
  lootbeamColor = WHITE;
}

// === TEST 6: multiple conditions combined ===
// Raw shrimp highlights BLUE only when: quick prayers ON AND task 0 complete
apply (id:317 && varbit:4103 && var:bit0 3116) {
  color = BLUE;
  showLootbeam = true;
  lootbeamColor = BLUE;
}

[riktenx]

1. varexpr should be terminated with semicolon
2. it should have the expected operator order you'd do in any programming language. arbitrary parens should also work. there's an example of postfix traversal for the condition stuff in the parser. but for this you'd want to basically convert the varexpr code to postfix and then evaluate postfix at runtime