HROT thinks NW limit is 4.

[tommyaweosme]

Code: Select all

#R R1,C2,S2-9,B3,NW191909191
!

9 is greater than 4, but the neighborhood explicitly SAYS it can be greater than 4.

edit: better example

Code: Select all

#R R1,C2,S128,B3,NW808080800080808080
!

edit: heres a flamingoship, and a flamingoship in the same rule but theres an error

Code: Select all

x = 4, y = 2, rule = R2,C2,S20-30,B30,NW0100000000000A0A0A00000A000A00000A0A0A000000000000
3o$o2b$3o!

Code: Select all

x = 4, y = 2, rule = R2,C2,S20-30,B30,NW100000AAA00A0A00AAA000000
3o$o2b$3o!

edit: ANOTHER beautiful oblique ship ruined by this bug

Code: Select all

x = 2, y = 3, rule = R2,C2,S20-21,30-32,B30-32,NW0101000000000A0A0A00000A000A00000A0A0A000000000000
o$2o$o!

Code: Select all

x = 2, y = 3, rule = R2,C2,S20-21,30-32,B30-32,NW110000AAA00A0A00AAA000000
o$2o$o!

[b-engine]

Sometimes you'll need two hexadecimal values per neighbor - the greatest weight could be 127, and minimum -127. This isn't a bug.

[confocaloid]

Arguably, it still can be considered a bug. Not necessarily a bug in the implementation, but instead a bug/flaw in the design.

The specific handling of negative numbers is counterintuitive. It is unexpected to have '8' mean 0 and '9' mean -1. People repeatedly attempt to use '8' to encode weight 8, and people repeatedly attempt to use '9' to encode weight 9, and it just plain fails to work in the intended way.

The idea to allow negative weights at all is also questionable. I consider them to be "a design flaw". It would be much more useful (and more intuitive) to allow nonnegative weights 0-15 (one hex digit) and 0-255 (two hex digits) instead.

Sometimes you'll need two hexadecimal values per neighbor - the greatest weight could be 127, and minimum -127. This isn't a bug.

[rowett]

9 is greater than 4, but the neighborhood explicitly SAYS it can be greater than 4.

You need to read the documentation which is here and here.