@
kristi; First off: Don't use
._GetPos directly (I don't get why people do this, there is a reason for the prefixing underscore). Also it's really wasting resources and time to compute the position _FOUR_ times in a row, the way you do.
Computing your position is by no means a cheap operation.
----
`
Distance(..)` will fail given a (somewhat) large "delta" (x1-x2, y1-y2) as it will compute the square of those, and add together the squares. As the input to `
Sqr` is `Int32` the output from is also `Int32`, so it overflows.
The error then comes from the call to `
Sqrt`, again because the input argument wrapped around to a negative number; Delta's greater than
32767 can cause that to happen.
The "Sqrt"-function isn't capable of handling negative numbers (the square root of a negative number is a complex number). Hence the error.
One solution is as follows:
Simba Code:
function TPortal.GetDist(): Int32;
var pos:TPoint;
begin
pos := Walker.GetMyPos();
if (pos.X < 1) or (pos.Y < 1) then
Exit;
Result := Round( Hypot(pos.X - Self.Tile.X, pos.Y - Self.Tile.Y) );
end;
This works because Hypot takes a float, so it wont overflow like Distance which works on Int32.
Sidenote: Not sure why you call it a "tile", RSWalker doesn't work with "tiles", it returns the
pixel you are located on in the given world map.
It's a mystery to me how you get that large numbers from RSWalker tho. It should always give values within the range of the given image. But idk been a while since I've worked on it.
That would happen if you input an invalid number (in this case a
negative number is passed to Sqrt, due to an overflow). I would hesitate to call it a Simba bug, but rather a limitation due to the datatype used, we can however compute distance purely in Lape as `
Sqr` will return `Int64`, unlike in Free pascal, where it returns `Int32` when given `Int32` input.