Skipping chunks around zero degrees is something that I am afraid that I completely missed. The smallest unit to scan is a full chunk and I had planned to leave this as is rather than require a fixed stepping or storing a lot more state data. Because of fractional stepping to get a complete fill, sometimes the next point will be on the inside corner of a chunk on one pass and an outside corner of an adjacent chunk on the next. The jitter you are seeing on the outside edge is because the outside edge is a calculation of a radius from the center. Accounting for that and allowing for more flexible rotation speed, dynamic direction, oscillating between two angle, etc. This is when I discovered the LUA does not actually have an integer type, everything is floating point calculations anyway. This required adding a fudge factor to get a complete fill. This would leave a radially symmetrical pattern of holes within the plot. But I had to be able to step the outside and scan between that and the center. The Bresenham's circle rasterization algorithm is an optimization for integer math which draws a complete circle. The most flippant one being the advances in modern CPUs. There are many reasons I switched to a trig based calculation method. I attempted to move the radar, but when mined, it does not return the original object. It also seems to skip charting chunks at (I suspect) around 0 degrees specifically, to the right of the radar, but only sometimes. I've noticed that the current algorithm seems to have a certain amount of jitter over multiple rotations it seems to only sometimes chart certain chunks that are on the edge of the scan radius. Mrudat wrote:Very nifty, but a number of comments:įor reasons of UPS, I'd probably prefer the more CPU-efficient algorithm then again, trig functions are I think single-cycle on modern processors, but branch instructions can take significant numbers of cycles to resolve, so I'm uncertain which would actually be more efficient. Able to configure direction of rotation Switched from Bresenham's circle algorithm to trig based calculation Able to configure default scanning speed Power usage scales with speed and radius Can enable/disable radar with condition Irection, 1 for Clockwise, -1 for CounterclockwiseĪr range, outer limit scanning radius (equivalent to ) Signal input support added, can control: Some mods requires all items to have a 32 pixel icon Quick fix for mining, seems to fix bot mining as well Step size increased to full chunk on outside diameter per step Pause sweep while game generates new map data Added option to disable additional power usage Inner radius specified by signal was not limited Corrected for floating point error near zero degrees Only call force.chart() once per chunk per scan
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |