You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The length of RingCounter objects is requested length++ since the counter starts at zero. This is likely the cause of hex_buffer contents appearing off by one for each column and the confusion when reverse-engineering planet maps. DOH! 馃憡 馃憥 馃槨 If so then this is a bug in Phoenix, not in EFS hex_buffer, and it took almost three years to notice ... ever so slight, subtle and fundamental flawww. Well, at least fixing #30 should be easier now ...
The text was updated successfully, but these errors were encountered:
The length of RingCounter objects is requested length++ since the counter starts at zero. This is likely the cause of hex_buffer contents appearing off by one for each column and the confusion when reverse-engineering planet maps. DOH! 馃憡 馃憥 馃槨 If so then this is a bug in Phoenix, not in EFS hex_buffer, and it took almost three years to notice ... ever so slight, subtle and fundamental flawww. Well, at least fixing #30 should be easier now ...
The text was updated successfully, but these errors were encountered: