(BUG) CPRLCore IsTerrainLOS

Started by warren, September 14, 2014, 04:18:56 AM

Previous topic - Next topic

warren

IsTerrainLos appears to always return 0 if X or TargetX > MapHeight (should be MapWidth)

knucracker

Nothing is jumping out as a problem in the code for that CRPL routine.  The width and height checks seem to be ok.  Double check things and make sure the terrain isn't really blocked.  Also save and reload the map if you have resized it (in case there is some issue with that).

warren

I found the problem after frequent testing, where the test units did not fire on the right side of the map (over a period of multiple saves and loads). I have already replaced the affected code with a custom algorithm. (The behaviour I ideally wanted was a wasteful 2-way IsTerrainLos anway). I also tested the order of the coordinates to see if they differed from what was specified on the wiki.

warren

Here is file that demonstrates the problem. all the cores have a simple script that causes the towers to turn black if they cannot hit any neighbours.

knucracker

Yep, sure enough.
There is/was a problem in that crpl routine.  It was properly checking for out of bounds arguments, just on the wrong arguments.  Has to do with the order they are popped off the stack causing me to mix up the x and y coordinates for bounds checking.  So x was checked against map height and y was checked against map width.  It's fixed in the source tree now...

But, you are better off going with your own routine for the time being.  Do a new round of builds takes a day, then it takes even longer for it to percolate out to the players.  So I don't intend to do another game build till there is some healthy collection of changes and/or additions to the game.

warren

Cool. While we're on the topic of script bugs, I used GetImageScaleY and found it needed 3 arguments. I just used 1 as the third argument. If you are planning on changing this, it could break one of my scripts, so I will need to change that right away.

Personally, I am betting that GetImageScaleY has not been used much.

knucracker

Yeah, they (getimagescaleX and Y) have a 3rd and unnecessary argument.  It doesn't matter what you put as long as you put something.  I'll leave this, though, since it is harmless and would only break things if I changed it.

kwinse

#7
And updated the wiki pages (for the image scale commands at least) so others don't have discover this on their own. Feel free to tweak it.