You can press turbo by yourself while this is active, so its neat, the way the VO universe is designed right now though, most worm hole > new system "closest exit sector" points are pretty much for every system a 180 degree turn to the left.

alrighty!

-it uses turbo now unless it gets within 500m of a rock or runs into a storm. it may even kind of work with non infiniboost ships but I didn't try that.
-it can handle storms if the server is running but it won't use turbo. cause the game reports all objects as 0m away in there
-it uses those nav exit point thingies unless the server isn't running (then it falls back to the old behavior)
-the abort functionality actually works now (most of the time)
-it will restore ship settings properly on arrival
-it gets location and size of the radar from the game now.. so it should run without messing around with that (totally untested though)
-it's less spammy
-some other stuff that should make it a bit more reliable

I've increased the default tolerance and spin time a bit. It should find the icons faster now but this may cause it to bounce back and forth a bit on some ships. That stuff is so inaccurate that will land the right spot eventually.

Maybe I'll add something like ship profiles later.. I don't really want to expose all those parameters in the config section. just "light ship" "medium ship" "heavy ship" or something.

EDIT:
oh right. since the server detects exit points by their color, very close friendly characters may throw it off. I didn't have that happen yet, could be fun way to mess around with it though. :P
If it's possible at all that char would have to sit right next to it. The bot would then go for ca 30s in whatever direction that char was and then look for the exit point again.

So basically, you start robotserver.bat, load the game, make a navroute, then type /dullbot, and leave the game window maximized while it auto pilots you across the galaxy by taking screenshots, finding the exits, turning to them, and turboing (only in sectors without a storm, and when >500m away from roids) toward them, stopping only when it reaches the destination sector or you retype /dullbot ?

If thats right so far:
* It auto jumps to sectors and systems when it reaches the point, or only moves towards them?
* Does it avoid roids/stations/other ships well enough so that you can make it in one piece? If you're heading towards the exit, but a roid blocks the direct path for example, will it strafe up/down to get a clear line of sight to the jump point ?
* In the event the navroute hits and unmarked roid sector, how does it handle attacks (I'm not talking about players, but NPC)? If one fires a shot, will it continue flying straight to the exit, or will it abort and get stuck there to et shot to bits, or will it try to dodge?
* Does this conflict with any other plugins or theme modifications?
* If a ship is destroyed, will it restart the navroute (buy back ship/cargo, undock and fly), or will is stay in the station?

If thats right so far:

it is

* It auto jumps to sectors and systems when it reaches the point, or only moves towards them?

It auto jumps when it reaches the point. It'd be kinda pointless
if it didn't

* Does it avoid roids/stations/other ships well enough so that you can make it in one piece? If you're heading towards the exit, but a roid blocks the direct path for example, will it strafe up/down to get a clear line of sight to the jump point ?

Nope. It will run right into them. Bounce off into a random
direction keep going for a bit then find the target again.
I'm note sure if a collision avoidance would be much more
effective without slowing down the bot even more.

Collisions at non turbo speeds generally don't do more than 5-10%
damage anyway. You'd have to have really bad luck if it died
because of that. Just use a ship that can take some beating.

The longest route I did was from gaira to initros. I made it with
95%. Including running into a roid and some convoy bot.

* In the event the navroute hits and unmarked roid sector, how does it handle attacks (I'm not talking about players, but NPC)? If one fires a shot, will it continue flying straight to the exit, or will it abort and get stuck there to et shot to bits, or will it try to dodge?

It will go towards the navpoint marker and attempt jump out. It
doesn't avoid bots in any way. IOW it will probably die a
horrible death.

I guess I could make it detect the exit less accurately when
hostiles are around. Like an increased tolerance and smaller no
turbo zone. That could increase its chances.

* Does this conflict with any other plugins or theme modifications?

Avoid Plugins that re parent the radar widget (I don't think
there are any around yet) and plugins and themes that change the
color of those icons.

EDIT: and themes that use the icon color for the radar will mess it up too

* If a ship is destroyed, will it restart the navroute (buy back ship/cargo, undock and fly), or will is stay in the station?

It's not a trade bot. Heh ..that would make it interesting as a
kind of remote delivery thingy though

I never tried blowing it up. I guess it will think that it's
still flying around and take screenshots of the station window
..or crap out on the buy back screen. :P

hey spuck... if you do a "target next in front" from time to time and check distance you can avoid collisions and add turbo ;)

hey drazed... I think that could work!

I've considered that before but was afraid the different roid sizes would be a problem. But I seems to be able to target most roids that I would run into about from about 200-500m. Below that and I run into them even if I can't target them.
The only exception are those huge ice roids ..those are just weird.

So it would probably go like this:
find gate
start doing RadarNextFront every 1s
movement cycle (boost for 30s)
if roid targetable and distance < 500m -> interrupt cycle
if cycle finished -> go back to start
turn till nothing targetable within 500m
go back to move cycle

I'd have done something like this:
find gate
disable hud and bg
dump screenshot
ask server for closest black area to center
if none -> move backwards a bit and go back to start (means I'm sitting right in front of a roid and it's filling the screen)
if there is -> turn towards that point
enable hud and bg
movement cycle
go back to start

Disadvantage compared to RadarNextFront would be that it requires the server to do collision avoidance which I'd prefer to avoid and it'd be possible to throw it off by parking between the bot and the gate.

The advantage is that it will find a clear path through the sector quite fast and the risk of running into irregular roids is lower (unless they are moving).

Don't know yet which way to go. If I'll bother at all :P

EDIT: Har! I just raced it against nemesis on the gaira - sol route.. and it won (barely)!

EDIT2: I also just launched it right next to a nemesis turret and it didn't mistake it for the exit point ..so that shouldn't be a problem after all

EDIT3: durn! somethings still wrong with aborting

http://kitchen.nfshost.com/ven/plugins/files/animatedload.zip

Animated load screen.

Same thing as posted in suggestions but it uses the navmap image of the destination system as background and the animation images are premultiplied, which should reduce the overhead a bit.

The previous background shows up briefly when jumping between systems. Working around this would be kinda awkward unless there's some event that triggers between jumping and the loading screen showing up.
So I'm just gonna pretend that it's supposed to reflect the transition between systems and call it a feature :P

EDIT: hmm! that would actually be pretty cool. fade between images based on percentage of sector load

Haha: Neat engineering for the bot, but I can kind of imagine with the "abort function sometimes not working," someone decides to put it on an infinite trade route in his nation's space and go to sleep... Then they wake up in the morning: "/abort" "I'm sorry, I cannot do that, Dave." "Nooooooooooooo!" So then he'd try to logoff and he couldn't because the bot was moving, so he uses a hotkey to force quit it, next time he logs in bot continues on its path. He tries force quitting, deleting the file from the folder, but the access to the folder has become restricted... Then the bot gets angry and like... the next time he tries to get online, he gets stuck in VO and the bot had erased all the key bindings from the entire computer itself. And he'd be stuck foevah, also he'd be on the test server (as I have realized traders have snuck off to do, recently) so nobody'd ever kill him.

He'd become rich, but never be able to use the money, he tries to manually shut off the comp from the button on the computer itself, but that binding had been overwritten, too... Then, over all this time, the computer (now have been completely taken over by the bot) had learned how to control objects with the exact vibrations of the disc drive going in and out and is now able to obtain the chainsaw from the garage... More on this story later...

Oh yeah, I'm so sorry, I'm so fucking drunklol

I'd get worried when it starts asking for sarah connor!

Weird. I just noticed that the bot actually works even when the window is covered or minimized.
I used to get blank screenshots when doing that.

I notice at some screen resolutions it doesn't work, what is your resolution set to in VO?

Hmm, not work in what way? I've tried it at 1024x768 and 800x600.

Maybe the icon colors are different at certain resolutions or AA causes them to be blurred. You'd have to load a screenshot into a graphics program and check if the wormhole icon contains a 3 192 238 +/-10 colored pixel. Or post one here.

I can't really see it getting the location wrong especially if it works at some resolutions.

EDIT: 16bit vs 32bit mode may cause problems too. I'm playing at 32bit.

EDIT: oh wow... somethings wrong.
EDIT: doh. CENTER_X and CENTER_Y aren't updated by setup_radar_info. They point to the center of the radar at 1024x768 even if you are at a different resolution.

I switched to 1024x768 and it works. Very cool idea, gold star for you. I still have trouble when I don't use full screen. I'll try 32bit in a window next, I was using 16.

Thank you!

cool a star!

just tried this version under windows. I think I'm seeing the same thing as you. When fullscreen it works fine but in window mode it can't find the jump out point.

Looks like the color of that thing is slightly different in window mode. Guess I'll have to add some tolerance for that. Although that may cause some misdetections. :/

/displaysHIPPOS WEEEEEEEEEEEEEEEEEEEEEEEEEE

Something that I've been curious about is the precise equations for deriving turn speeds. With this automation, do you think one could come up with some data? If you can't make the screen dumps rapid enough, you can atleast slow down the trials with a Behemoth full of swarms.

Nah. It just waits a fixed amount of time after each impulse. It has no idea about how far they send it or how long it moved. So it wouldn't be of any use for getting that kind of info.

Also the amount each impulse sends it is pretty variable. I think it's because the command processor thingy introduces some delays which sometimes cause it to move longer than it should.

Okay! with the zbox fixes the animated load screen displays the tip now.

And this glorious thingy works now too! (here at least :P)

http://kitchen.nfshost.com/ven/plugins/files/tapehud.zip

Okay! the last update broke some of my stuff.
namely the glorious tapehud and the movesectorinfo thingy. both should work again. although the workaround looks a kinda whacky. There may be a better way to do this.

Seems like the last update causes objects to sometimes receive events in a different order than they were registered.

Okay!
I've split off most of the bot into a seperate module. Which could theoretically be used as part of more complex bots. The dullbot module would then just take care of going from A to B. For example it could be told to patrol a certain route or buy stuff from a station and dump it somewhere. Right now it just does the travel stuff though.

- It now optionally targets whatever is infront of it. This is used to roughly half the time spent without turbo while passing near objects. But it will run with higher speed into untargetable or hard to target objects like stations and larger rocks. Also passing ships may throw it off.
- There's optionally a really shitty collision avoidance. Chances are high that it will run into stuff anyway. It uses the target in front thing for this. I tried a few trips with it but overall it doesn't seem worth it.
- It can optionally use different tolerances for wormholes and exit points.
- It can autodetect a lot more of its parameters
- I think aborting aborts correctly now!
- it should handle things like dieing and disconnecting a bit more nicely
- spin time is now scaled based on the distance from the center. if the gate is on the front radar it often hits it in one attempt

The bot accepts a few keywords now:
"target" enables the target infront thing.
"avoid" enables collision avoidance.(implies "target")
"input" enables input while the bot is running
"big_exit" sets the size of the exit point tolerance to 50% of the radar diameter (or something like that). reduces time spent centering on the exit point a bit.
"light" "medium" "heavy" "extraheavy" adjust spin times to different ship types. the lower classes work with heavier ships too but it will take a lot longer to find the target with them.

example: /dullbot medium big_exit target
With that I made it from gaira till itan in a hog mk2 while hated! But only once. :/

the most simple bot made with the dullbot module would look like this:

local dullbot = dofile("dullbot.lua") -- load the module
bot = dullbot.new() -- create new bot instance
bot:SetServerDirectory("path/to/server") -- set path to server
bot:Init() -- start the bot

The whole list of methods exposed by the bot is:
IsRunning() -- returns true if this instance is active
Init(cb) -- initialize and start bot cb gets called when the bot finishes or gets interrupted. The callback receives as argument one of:
dullbot.BOT_ARRIVED
dullbot.BOT_STUCK
dullbot.BOT_DIED
dullbot.BOT_DOCKED
dullbot.BOT_ABORT
dullbot.BOT_DISCONNECTED
Abort() -- stops and uninitializes instance
ResetConfig() -- reset config
Tolerance(hole_tolerance, exit_tolerance) -- set wormhole and exit point tolerance (0-1)
MoveDuration(duration) -- time in seconds to move between checking for gate
SpinDuration(duration) -- max time to spin up
NoTurboZone(size) -- size of no turbo zone around objects
RadarOptions(size, off_x, off_y) -- location of radar (normally autodetected)
SpinBrakeFactor(factor) -- a bit abstract, SpinDuration is multiplied by this and added to get the spin up + spin down time (or something pretty close to it) (normally autodetected)
SetDisableInput(input) -- disable input
GetDisableInput()
SetTarget(target) -- enable targeting
GetTarget()
SetAvoid(avoid) -- enable avoidance
GetAvoid()
SetServerDirectory(dir) -- set the server directory (oups ..Get version missing)

There are a few more but most of them aren't supposed to be called from the outside.
Configuration should be done before calling Init(). Some settings can be set at runtime though.
All except the Set/Get functions return the current setting when called without arguments.

The server can now have its tolerances adjusted using the gt (gate icons) and et (exit icon) parameter.
Example: lua robotserver.lua gt=10 et=0, which is the default.
There's a second batch file now called robotserver-ht.bat that sets the tolerance for exit points to 5. That may work better under windows, but I didn't test it.

I didn't test everything. So not sure if it all works. (probably not :P)