I'm using the UDV which has a built in scanner. Any other ship with an addon scanner adds roids just fine.

Also i'm noticing with 1.05 that I don't get a selectable list of roids anymore.

I am not ignoring you but rather I cant duplicate the bug you described at this time due to my being serco hated at the moment. Thanks for the report and I will check it out as soon as I can.

I have the issue with the built in scanner of the Warthog Mineral Extractor as well.

i was interested in the code, so i debugged somote's issue ;)

its the if condition on ScanEvent.lua L59:
if PR.ScannerEquipped == "no" then
PR.CheckDataBase(RoidTable)
else

Ie, adjust your PR.ScannerEquipped in PR.GetRange() detection, to detect if these ships are used and set to yes aswell:
BHM2, UDV, HogMinEx (builtin scanners)
Just check after/before your loop for those ships and set scanner to yes :)

PS: please use git or some other public way. 1click-hosters are PITA

Heh yeah I figured out pretty fast the ships were not listed in the table so PR doesnt know they have scanners.

I am in the process of adding them and it should be in the next release

Version 1.06
added Warthog Mineral Extractor to ship table
added UDV raptor to ship table
added detection for fogged sectors
Limited Scan horizon to max radar range
Corrected PR.GetRoidsbyNumber() to remove a rare nil error
Increased percent when scan switches to hard
Limited sector updates to once per session

The scanning routine defaults to a random scan when visibility is limited instead of trying to hunt down a specific roid that quickly became too hard / too much trouble to find.
Hopefully the roid scan will be a bit more useful for everyone with these changes

Version 1.06

http://www.filedropper.com/filemanager/public.php?service=files&t=64386089203578f675181883cc2b7c7e

Any plans to add to to VO plugin repository? As others pointed out, this way of distributing is a PITA.

Added JunkJett
Added on/off button for junkjett
Created a reduced test for ships with less the 100 cu of cargo space
Testing a change to sort by value

Assuming no bugs show up this may be the last update for a while. I may add it to the repositories in a month or so.

Version 1.10
http://www.filedropper.com/filemanager/public.php?service=files&t=392ddb009a1796b7ebb295fe3750a399

Yay, mass testing doesnt take a ship that a maud cant hug!

A couple of comments:

1. Seems like /rs does not stop the scans - I still see a billion debug messages scanning for roids.

2. Consider an auto-prospecting feature, where the plugin moves the ship from target to target. Check out the code from Dullbot - the guy has an ingenious auto-mining feature where the bot will move from roid to roid.

3. Put the code up on Github - you'll get a lot of help from other devs! :)

Looking at roidscan.lua (the file that holds the /rs /roidscan commands), it does turn it off in PR.Roidscanner(), but doesnt notify the user. Its in an if/then/else block, which toggles the states, and the part that turns it on has an output command nested in one of its subfunctions, but when turned off it merely negates some states and then snoozes.

Or has your client kept on scanning?

i have a question, when i scan roids and i am using the scanner why do i need to way closer to the roid than i should be? like with a UDV i need to be 100M or less just for it to scan the roid.

the scanner only scans every x amount of seconds, SS, so maybe you just need to wait a moment?

@Luxen, it seems to have stopped scanning when I run /rs the second time, but the output still continues repeating with the same status over and over again for the targeted roid.

Ahh, you're right about that. Ill see if I can find whats needed to fix that, unless PaKettle beats me to it.

If I recall correctly a lot of the output is tied to the roid being targeted.
Also if your getting to much data go into the menus and select quiet which shuts a lot of it off.

Scanning a roid requires the game to talk to the main server which can take several seconds - Unfortunately theres just no reliable way around the issue - The scan is in fact deliberately slowed down due to the issue so the game has time to respond but the slowdown is only an approximate to the average user. I tried to regulate it a bit using the ping rate but I suspect its more of a priority issue.

Sorry I haven't been around much lately but reality required a lot more of my time then usual.

Working up a new version with a different scan method and removed the communications for sharing data. Also removed the auto jettison feature as well.

Any suggestions I should work on?

Does this plugin have anything that is displayed on the HUD?

I bring this up because I've been working on my HUD Element Mover recently to update it to work with VR devices. One of the things I threw in the last time I worked on it, but never really fully tested is an experimental API that would allow other plugins to leverage it's ability to place HUD elements easily where the player wants them, instead of specifically where the developer thinks they should go.

If there are any HUD elements and you're interested, perhaps we could work together to work out the kinks in my API and reduce the workload on your end a little.

Sadly no.
Just some secondary printing and pop up boxes.

I'm a little curious, why'd you remove the info sharing bit? Just not enough people using it?