Forums » Community Projects
apcontrol does not work for me at all. I got it working ages ago with MPD, but now I'm trying to use it with XMMS, I have installed and enabled iNetControl, and can send commands to XMMS. The plugin loads fine, but as soon as I type /apcontrol, VO freezes!
whoa cool... I dunno it still works here. I don't see anything obvious wrong either.
How large is your playlist? maybe it takes too long to update.
Does /applaylist work?
How large is your playlist? maybe it takes too long to update.
Does /applaylist work?
The playlist I was trying to use only had about 200 tracks, and no, /applaylist does not work. (I didn't think any commands besides /apcontrol worked with XMMS)
200 tracks shouldn't be a problem ..I've fed more into it.
applaylist is the only one that works here, it's some weird timing thing. I figured out why it doesn't like the rest yesterday.. the documentation says I can disconnect at any time, but that doesn't always work. If I send EXIT instead it does.
inetctl has some other issues. It keeps freezing xmms for no reason. I wished there was some alternative. :(
I don't really know what's wrong... it shouldn't be able to hang the game.
What happens when do applaylist? Do you have the most recent versions of xmms, inetctl and the plugin? What distro? 32 or 64bit?
I'll add a verbose option, maybe that will show where exactly it hangs.
I just had a funky idea ...this thing could be tied to voice chat and lower the volume on messages! (if it worked properly!)
EDIT: argh .. now I've rebuilt inetctl and it won't let my connect with anything!
applaylist is the only one that works here, it's some weird timing thing. I figured out why it doesn't like the rest yesterday.. the documentation says I can disconnect at any time, but that doesn't always work. If I send EXIT instead it does.
inetctl has some other issues. It keeps freezing xmms for no reason. I wished there was some alternative. :(
I don't really know what's wrong... it shouldn't be able to hang the game.
What happens when do applaylist? Do you have the most recent versions of xmms, inetctl and the plugin? What distro? 32 or 64bit?
I'll add a verbose option, maybe that will show where exactly it hangs.
I just had a funky idea ...this thing could be tied to voice chat and lower the volume on messages! (if it worked properly!)
EDIT: argh .. now I've rebuilt inetctl and it won't let my connect with anything!
found the problem. It's a bug inetctl but apcontrol should probably handle the situation better.
http://sourceforge.net/tracker/index.php?func=detail&aid=1502076&group_id=56999&atid=482580
patch here
http://home.arcor.de/famscheffler/inetctl.diff
http://sourceforge.net/tracker/index.php?func=detail&aid=1502076&group_id=56999&atid=482580
patch here
http://home.arcor.de/famscheffler/inetctl.diff
apcontrol now does volume control.
It can also relay the sound ducking thing to the connected player. The feature can be enabled in the config.. it's off by default cause it adds some overhead and may have issues.
It's probably a good idea to enable software volume control in the player otherwise it will lower the games volume too ..which would make it kinda pointless. I think all 3 players support soft volume.
It shouldn't freeze the game anymore if a connected player rapidly disconnects.
Could be that I broke playlist display with vlc and ducking may not work too well with it cause it can't handle multiple connections.
treemissionlist should work properly with the tutorial now.
telnetterm should get along better with raw connections and modifiers possibly work on non linux systems ..but I didn't test that.
It can also relay the sound ducking thing to the connected player. The feature can be enabled in the config.. it's off by default cause it adds some overhead and may have issues.
It's probably a good idea to enable software volume control in the player otherwise it will lower the games volume too ..which would make it kinda pointless. I think all 3 players support soft volume.
It shouldn't freeze the game anymore if a connected player rapidly disconnects.
Could be that I broke playlist display with vlc and ducking may not work too well with it cause it can't handle multiple connections.
treemissionlist should work properly with the tutorial now.
telnetterm should get along better with raw connections and modifiers possibly work on non linux systems ..but I didn't test that.
http://kitchen.nfshost.com/ven/plugins/files/luagzip.zip
a pure lua gzip decompressor.
Not really a plugin but there's a small demo that works with ven in it. It was just a fun little project ..not sure if it's all that practical.
The deflate decoder in is based on puff.c which is some sample code that comes with zlib. Some parts are just translation of that thing from c to lua.
It uses a tweaked luabit for some of the less critical bit ops and httplib (with some fixes) for the plugin.
The package consists of 4 parts.
luainflate.lua the deflate decompressor
luagzip.lua the gzip reader on top of luainflate
luagziptest.lua a standalone script to decompress gzip files
main.lua (http_gzip()) a sample plugin that downloads a gzip file and decompresses it
Files can be fed to it in arbitrary sized chunks but performance goes down a lot with larger chunks. 1-2K seemed to the best results in my tests. Although even then it's still pretty slow. I'm getting around 30kbps in luagziptest and about a third of that with http_gzip. I think if I can avoid a few more buffer copies I could get a bit more faster but 10Kbps was my original goal so I'm pretty happy with it already.
Might be a good idea to send a checksum with files because I can't guarantee that it doesn't have bugs. It's also not using the checksum in the gzip file.
Usage
-----
luagzip:
-- load lib
luagzip = dofile("luagzip.lua")
-- create decompressor instance
gzip = luagzip.new()
-- feed the whole file or a chunk of it to the decompressor
-- return value is either an uncompressed chunk
-- or nil when the last compressed block of a file was successfully
-- decompressed.
-- on error out is nil and err is non nil
out, err = gzip:decompress(in)
luainflate:
-- pretty much the same as luagzip
luainflate = dofile("luainflate.lua")
inflate = luainflate.new()
out, err = inflate:inflate(inbuf)
-- test plugin:
http_gzip(url)
on success prints a checksum and time it took to decode
will freeze the client while decoding is in progress
luagziptest.lua:
lua luagziptest.lua <infile> <outfile>
decompresses infile to outfile
other stuff.. racecartool is now a lot more friendly to the wiki when doing recursive lookups.
a pure lua gzip decompressor.
Not really a plugin but there's a small demo that works with ven in it. It was just a fun little project ..not sure if it's all that practical.
The deflate decoder in is based on puff.c which is some sample code that comes with zlib. Some parts are just translation of that thing from c to lua.
It uses a tweaked luabit for some of the less critical bit ops and httplib (with some fixes) for the plugin.
The package consists of 4 parts.
luainflate.lua the deflate decompressor
luagzip.lua the gzip reader on top of luainflate
luagziptest.lua a standalone script to decompress gzip files
main.lua (http_gzip()) a sample plugin that downloads a gzip file and decompresses it
Files can be fed to it in arbitrary sized chunks but performance goes down a lot with larger chunks. 1-2K seemed to the best results in my tests. Although even then it's still pretty slow. I'm getting around 30kbps in luagziptest and about a third of that with http_gzip. I think if I can avoid a few more buffer copies I could get a bit more faster but 10Kbps was my original goal so I'm pretty happy with it already.
Might be a good idea to send a checksum with files because I can't guarantee that it doesn't have bugs. It's also not using the checksum in the gzip file.
Usage
-----
luagzip:
-- load lib
luagzip = dofile("luagzip.lua")
-- create decompressor instance
gzip = luagzip.new()
-- feed the whole file or a chunk of it to the decompressor
-- return value is either an uncompressed chunk
-- or nil when the last compressed block of a file was successfully
-- decompressed.
-- on error out is nil and err is non nil
out, err = gzip:decompress(in)
luainflate:
-- pretty much the same as luagzip
luainflate = dofile("luainflate.lua")
inflate = luainflate.new()
out, err = inflate:inflate(inbuf)
-- test plugin:
http_gzip(url)
on success prints a checksum and time it took to decode
will freeze the client while decoding is in progress
luagziptest.lua:
lua luagziptest.lua <infile> <outfile>
decompresses infile to outfile
other stuff.. racecartool is now a lot more friendly to the wiki when doing recursive lookups.
Added boilbot to the dullbot package.
Boilbot is a mining bot that is supposed to automatically mine all roids within radar range in a sector.
its workflow looks like this:
find and target a roid that it hasn't mined yet if nothing found quit
fly towards targeted object
mine and dump ore for a predetermined time
go to beginning
boilbot is started with /boilbot the prcess can be interrupted with another /boilbot. By default it assumes that the mining beams are mapped to the primary trigger. The bot will block input and hide radar blibs of ships and stations while it's running.
it accepts the following options:
time=n: how long to mine each roid. n is the time in seconds (default 60).
secondary: use this if the mining beams are mapped to the secondary trigger.
tertiary: use this if the mining beams are mapped to the tertiary trigger.
largeblibs: scale the targetblibs in the radar. if it turns away from the target even though it's on the left radar use this option.
example: /boilbot time=120 secondary largeblibs
limitations:
All the funky quirks of dullbot.
It requires either robotserver or jrobotserver.
It doesn't even try to avoid any roids, but if somethings in the way it will bounce around it, which can sometimes take a while. That also means that it will eventually rub itself to death, but that also takes a while cause it's never going really fast.
It's a bit slow right now.
I've only tested it with a centaur but other ships should work too.
Untested under windows
changes to the dullbot module:
when radar blibs are hidden enemy ships are now hidden too.
new functions:
SetApproachMode(distance) -- makes the bot fly towards the targeted object. distance determines how close. if distance is 0 it could be used to pick up items, but that's not very reliable ..yet.
GetApproachMode()
SetLargeBlibs(large) -- scale the radar blibs up. helps detection in approach mode
Boilbot is a mining bot that is supposed to automatically mine all roids within radar range in a sector.
its workflow looks like this:
find and target a roid that it hasn't mined yet if nothing found quit
fly towards targeted object
mine and dump ore for a predetermined time
go to beginning
boilbot is started with /boilbot the prcess can be interrupted with another /boilbot. By default it assumes that the mining beams are mapped to the primary trigger. The bot will block input and hide radar blibs of ships and stations while it's running.
it accepts the following options:
time=n: how long to mine each roid. n is the time in seconds (default 60).
secondary: use this if the mining beams are mapped to the secondary trigger.
tertiary: use this if the mining beams are mapped to the tertiary trigger.
largeblibs: scale the targetblibs in the radar. if it turns away from the target even though it's on the left radar use this option.
example: /boilbot time=120 secondary largeblibs
limitations:
All the funky quirks of dullbot.
It requires either robotserver or jrobotserver.
It doesn't even try to avoid any roids, but if somethings in the way it will bounce around it, which can sometimes take a while. That also means that it will eventually rub itself to death, but that also takes a while cause it's never going really fast.
It's a bit slow right now.
I've only tested it with a centaur but other ships should work too.
Untested under windows
changes to the dullbot module:
when radar blibs are hidden enemy ships are now hidden too.
new functions:
SetApproachMode(distance) -- makes the bot fly towards the targeted object. distance determines how close. if distance is 0 it could be used to pick up items, but that's not very reliable ..yet.
GetApproachMode()
SetLargeBlibs(large) -- scale the radar blibs up. helps detection in approach mode
Added another robotserver to dullbot.
This ones written in C and sits between the game and gl library. It grabs snapshots of the video buffer when asked to. It works kind of like those gl based screen grabbers. This way it has a lot less overhead compared to the other servers cause everything happens in memory and over raw frames.. so it doesn't have to wait till images are written to disk and en/decoded.
The bot contained in a library called libglrobotserver.so that is preloaded using LD_PRELOAD. When the lib is loaded it spawns the actual server and redefines the function that normally redraws the screen.
Usage:
The game should be started via glrobotserver.sh in the glrobotserver directory. It sets up the environment and then launches vendetta with the lib preloaded. Ingame the bot is activated with /dullbotgl or /boilbotgl. Options are the same.
Limitations:
It's linux only right now. The linker and interface to gl is different on all OSes. I could possibly avoid the call to glx ..not sure if there's way to get the size of the gl context via gl though. Everything else should be pretty portable.
It can't be started while the game is running like the other servers.
The game has to be started without the updater. Otherwise the lib would spawn two servers, for the updater and the game. I'd have to either detect which program loaded it or somehow spawn the server a different way. like when the first gl call is done or something
Bugs:
If the server somehow dies the game detaches from the terminal it was started from. Has something to with the way I spawn the server and is a bit of a hassle to work around. It's not a big issue.. I just wanted to mention it.
For everything else .. it works for me :P
The source is in glrobotserver/glrobotserver.c and can be rebuild with build.sh.
The included libreobotserver.so was built on slackware 12.1.
------
Reorganized things a bit in the dullbot module.
------
paydialog can now do multiple payments at once again.. although in a kinda clunky way.
------
EDIT: whoops ... gotta remember to use -Wall. Squished a couple of compiler warnings in glrobotserver. Most of them seemed to be harmless though.
This ones written in C and sits between the game and gl library. It grabs snapshots of the video buffer when asked to. It works kind of like those gl based screen grabbers. This way it has a lot less overhead compared to the other servers cause everything happens in memory and over raw frames.. so it doesn't have to wait till images are written to disk and en/decoded.
The bot contained in a library called libglrobotserver.so that is preloaded using LD_PRELOAD. When the lib is loaded it spawns the actual server and redefines the function that normally redraws the screen.
Usage:
The game should be started via glrobotserver.sh in the glrobotserver directory. It sets up the environment and then launches vendetta with the lib preloaded. Ingame the bot is activated with /dullbotgl or /boilbotgl. Options are the same.
Limitations:
It's linux only right now. The linker and interface to gl is different on all OSes. I could possibly avoid the call to glx ..not sure if there's way to get the size of the gl context via gl though. Everything else should be pretty portable.
It can't be started while the game is running like the other servers.
The game has to be started without the updater. Otherwise the lib would spawn two servers, for the updater and the game. I'd have to either detect which program loaded it or somehow spawn the server a different way. like when the first gl call is done or something
Bugs:
If the server somehow dies the game detaches from the terminal it was started from. Has something to with the way I spawn the server and is a bit of a hassle to work around. It's not a big issue.. I just wanted to mention it.
For everything else .. it works for me :P
The source is in glrobotserver/glrobotserver.c and can be rebuild with build.sh.
The included libreobotserver.so was built on slackware 12.1.
------
Reorganized things a bit in the dullbot module.
------
paydialog can now do multiple payments at once again.. although in a kinda clunky way.
------
EDIT: whoops ... gotta remember to use -Wall. Squished a couple of compiler warnings in glrobotserver. Most of them seemed to be harmless though.
Dullbot gives me the same error everytime it takes a screenshot
sent plugins/dullbot/objectfinder.lua: 101: attempt to read from undeclared variable: robo_print
stack traceback:
[C]: in function 'error'
vo/vo.lua:367: in function <vo/vo.lua:362>
plugins/dullbot/objectfinder.lua:101: in function <plugins/dullbot/objectfinder/lua:98>
(tail call): ?
I'm running an MacOSX
also im not sure where to place the luasocket and im lib files
and yes jrobotserver.java was running
sent plugins/dullbot/objectfinder.lua: 101: attempt to read from undeclared variable: robo_print
stack traceback:
[C]: in function 'error'
vo/vo.lua:367: in function <vo/vo.lua:362>
plugins/dullbot/objectfinder.lua:101: in function <plugins/dullbot/objectfinder/lua:98>
(tail call): ?
I'm running an MacOSX
also im not sure where to place the luasocket and im lib files
and yes jrobotserver.java was running
Oups! I've moved some stuff around and forgot to rename that thing. Should work now.
If it called robo_print in that place that means it couldn't connect to the server.
What does jrobotserver spit out when you start it?
If you start it via jrobotserver.sh all you should see is this:
$ sh jrobotserver.sh
dullbot server
hit ^C to close it
port: 44444
gate tolerance: 10
exit tolerance: 0
I think all you need to do to make the lua version work is to put socket.dylib, mime.dylib and imlib.dylib into the dullbot directory. Could be that they are called something else on Macs.
If it called robo_print in that place that means it couldn't connect to the server.
What does jrobotserver spit out when you start it?
If you start it via jrobotserver.sh all you should see is this:
$ sh jrobotserver.sh
dullbot server
hit ^C to close it
port: 44444
gate tolerance: 10
exit tolerance: 0
I think all you need to do to make the lua version work is to put socket.dylib, mime.dylib and imlib.dylib into the dullbot directory. Could be that they are called something else on Macs.
Okay! fixed the sorting issue in treemissionlist (It sometimes throws an error since the upgrade to lua 5.1.4, which made it easy to track down).
It also now makes use of the list cache thingy. Which should reduce overhead quite a bit. I don't think that it's much slower than the standard list anymore.
Some more small things that bugged me:
http://kitchen.nfshost.com/ven/plugins/files/skirmishcolors.zip
Increases the brightness of the hud skirmish info for corvus and the hive. It's normally almost unreadable in some sectors.
http://kitchen.nfshost.com/ven/plugins/files/locknearbylist.zip
Adds a toggle to the nearby ships list that temporarily locks it. In really active sectors (like during skirmishes) the list updates so often that it gets hard to pick a target or get an overview of the targets.
It also now makes use of the list cache thingy. Which should reduce overhead quite a bit. I don't think that it's much slower than the standard list anymore.
Some more small things that bugged me:
http://kitchen.nfshost.com/ven/plugins/files/skirmishcolors.zip
Increases the brightness of the hud skirmish info for corvus and the hive. It's normally almost unreadable in some sectors.
http://kitchen.nfshost.com/ven/plugins/files/locknearbylist.zip
Adds a toggle to the nearby ships list that temporarily locks it. In really active sectors (like during skirmishes) the list updates so often that it gets hard to pick a target or get an overview of the targets.
I just made treemissionlist handle the border skirmish countdown thing.
It's not updating in real time like the normal countdown, because the list refreshes every couple of seconds anyway.. so it seemed like pointless overhead.
Also kicked out some dead code.
It's not updating in real time like the normal countdown, because the list refreshes every couple of seconds anyway.. so it seemed like pointless overhead.
Also kicked out some dead code.
I can't get the javaserver to run on my PPC mac.
The pre-packaged JAR file didn't work because it was compiled with a later version of Java than sun will provide for the mac.
When I recompiled it myself, it compiled fine and ran fine, but when I try to use dullbot within the game, the following happens:
wingmac:dullbot Wing$ ./jrobotserver.sh
dullbot server
hit ^C to close it
port: 44444
gate tolerance: 10
exit tolerance: 0
Exception in thread "main" java.lang.ClassFormatError: Incompatible magic value 1347093252 in class file coordinates
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
at jrobotserver.find_icon(jrobotserver.java:132)
at jrobotserver.get_icon_position(jrobotserver.java:162)
at jrobotserver.run_robot(jrobotserver.java:223)
at jrobotserver.main(jrobotserver.java:260)
wingmac:dullbot Wing$
The pre-packaged JAR file didn't work because it was compiled with a later version of Java than sun will provide for the mac.
When I recompiled it myself, it compiled fine and ran fine, but when I try to use dullbot within the game, the following happens:
wingmac:dullbot Wing$ ./jrobotserver.sh
dullbot server
hit ^C to close it
port: 44444
gate tolerance: 10
exit tolerance: 0
Exception in thread "main" java.lang.ClassFormatError: Incompatible magic value 1347093252 in class file coordinates
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
at jrobotserver.find_icon(jrobotserver.java:132)
at jrobotserver.get_icon_position(jrobotserver.java:162)
at jrobotserver.run_robot(jrobotserver.java:223)
at jrobotserver.main(jrobotserver.java:260)
wingmac:dullbot Wing$
Whoops .. I meant to compile it for lower java versions. guess I didn't..
Did the compiler create a file called coordinates.class? I was lazy and lumped it into jrobotserver.java... maybe the older javas don't like multiple classes per file.
There's a new package up now. I've split out coordinates.java and moved the source to jrobotserver-src. makejar.sh rebuilds the jar file.
The included jar should now work with java 1.2 and up.
My crappy attempt at docking, mentioned in http://vendetta-online.com/x/msgboard/1/21231#26285, is also in there. The command to launch it is dockbot. dockbot_add_rock adds the reference rock.
But it doesn't really work. :P
There are a bunch of other tweaks .. mostly to increase accuracy.
Did the compiler create a file called coordinates.class? I was lazy and lumped it into jrobotserver.java... maybe the older javas don't like multiple classes per file.
There's a new package up now. I've split out coordinates.java and moved the source to jrobotserver-src. makejar.sh rebuilds the jar file.
The included jar should now work with java 1.2 and up.
My crappy attempt at docking, mentioned in http://vendetta-online.com/x/msgboard/1/21231#26285, is also in there. The command to launch it is dockbot. dockbot_add_rock adds the reference rock.
But it doesn't really work. :P
There are a bunch of other tweaks .. mostly to increase accuracy.
okay! .. added another bot to dullbot
Haulbot carts stuff between stations... and sometimes get's stuck on some corner and goes crazy..
To use it, it first needs to know the id's of the docking bays it's supposed to fly into. To get it to learn those park the ship in a docking bay of the source and destination and enter /dockbot_add_dock. If an asteroid is targeted while the command is issued the bot will first move to that roid before flying to the docking bay. This only has to be done once.. I think I could do that automatically but it would probably get messy.
To actually use the bot fill the ship with some cargo, select the route to the destination station and enter /haulbot "name of cargo to return" (ex: /haulbot "Carbonic Ore"). The bot should now undock, follow the route to the destination, sell the cargo and do the same in reverse with the return cargo. Then start over.
issues:
It's dreadfully slow!
It sometimes misses the docking bay. It tends to turn a bit too far when near the bay. That's a side effect of making it aim ahead of the bay. I need to add a special case for that or something.
If it misses the dock it often has trouble to find it again... and sometimes gets completely stuck
The station needs to be within radar range when the bot enters the destination sector.
It tries to get around the station but that's not 100% reliable.. so it's a good idea to pick the dock and jump entry so that the dock is within line of sight when jumping in. Adding a rock with /dockbot_add_dock that's infront of the bay should also help .. but it's not required.
It will probably break if no return cargo is specified or it doesn't exist at the destination.
I've only tested it with a centaur. Not sure if it'd hit the bay with a moth or something much lighter.
other things:
The *gl bots are gone. The bots now figure out automatically which server is running. robotserver.lua iisn't updeted yet to identify itself ..so it doesn't work at all right now. I couldn't figure out a good way to package 64bit versions of the dependencies yet. GL and java work though.
There's now a 64bit version of glrobotserver bundled. Start with glrobotserver64.sh
Removed some uselsss junk and tidied things up somewhat. It hopefully cleans up after itself better now.
Haulbot carts stuff between stations... and sometimes get's stuck on some corner and goes crazy..
To use it, it first needs to know the id's of the docking bays it's supposed to fly into. To get it to learn those park the ship in a docking bay of the source and destination and enter /dockbot_add_dock. If an asteroid is targeted while the command is issued the bot will first move to that roid before flying to the docking bay. This only has to be done once.. I think I could do that automatically but it would probably get messy.
To actually use the bot fill the ship with some cargo, select the route to the destination station and enter /haulbot "name of cargo to return" (ex: /haulbot "Carbonic Ore"). The bot should now undock, follow the route to the destination, sell the cargo and do the same in reverse with the return cargo. Then start over.
issues:
It's dreadfully slow!
It sometimes misses the docking bay. It tends to turn a bit too far when near the bay. That's a side effect of making it aim ahead of the bay. I need to add a special case for that or something.
If it misses the dock it often has trouble to find it again... and sometimes gets completely stuck
The station needs to be within radar range when the bot enters the destination sector.
It tries to get around the station but that's not 100% reliable.. so it's a good idea to pick the dock and jump entry so that the dock is within line of sight when jumping in. Adding a rock with /dockbot_add_dock that's infront of the bay should also help .. but it's not required.
It will probably break if no return cargo is specified or it doesn't exist at the destination.
I've only tested it with a centaur. Not sure if it'd hit the bay with a moth or something much lighter.
other things:
The *gl bots are gone. The bots now figure out automatically which server is running. robotserver.lua iisn't updeted yet to identify itself ..so it doesn't work at all right now. I couldn't figure out a good way to package 64bit versions of the dependencies yet. GL and java work though.
There's now a 64bit version of glrobotserver bundled. Start with glrobotserver64.sh
Removed some uselsss junk and tidied things up somewhat. It hopefully cleans up after itself better now.
Is there any chance getting apcontrol to support mocp? It would probably require some scripting for the connection to the server because it uses unix sockets instead of tcp.
Yeah .. it'd require some kind of bridge. It could pretend to be one of the other players to keep things simple.
Ok lessee if this works for you ...
http://home.arcor.de/famscheffler/ven/mocp2mpd.py
That script pretends to be an mpd server that translates messages between mpd clients and the moc server. I've only implemented the commands that are used by apcontrol ..so it probably won't work with anything else.
Set apcontrol to use mpd and the port to 6600. If moc and the script are running it should show the playlist and currently playing track.
Playback has to be initiated from mocp first. The moc client sends the playlist to the server when you hit play ..before that the server doesn't have one yet. I'd probably have to read the client config and playlist, then send it myself to get around that.
The playlist doesn't work correctly in directory mode. Would probably be useful if it'd list the directory contents in that case. But I couldn't figure out a way to detect which mode I'm in. Dunno which one you usually use.
Otherwise it should work like any other player supported.
Other stuff:
Updated treemissionlist to use the new icons and added an option to group missions by category. /treemissionlist_grouping 1 makes the list group by category and 0 by title
And because I can't count something new called shortgivemoney.
It's like givemoney but allows to abbreviate the amount
http://kitchen.nfshost.com/ven/plugins/files/shortgivemoney.zip
examples:
/sgm mr_spuck 1m - sends me 1000000 credits
/sgm mr_spuck 200k - would be 200000 credits
/sgm mr_spuck 40b - 40 billion credits
/sgm mr_spuck 1c - is one credit .. that's just for completenes
it's also additive so
/sgm mr_spuck 10k500 - is 10500
/sgm mr_spuck 10m10m10m - is 30000000
and lastly the numeric values can be left out competely
/sgm mr_spuck m - is 1000000
/sgm mr_spuck ccccc - is a really strange way to send me 5 credits
edit:
oh right .. that locknearbylist thing seems to have some issues. I gotta fix that at some point..
http://home.arcor.de/famscheffler/ven/mocp2mpd.py
That script pretends to be an mpd server that translates messages between mpd clients and the moc server. I've only implemented the commands that are used by apcontrol ..so it probably won't work with anything else.
Set apcontrol to use mpd and the port to 6600. If moc and the script are running it should show the playlist and currently playing track.
Playback has to be initiated from mocp first. The moc client sends the playlist to the server when you hit play ..before that the server doesn't have one yet. I'd probably have to read the client config and playlist, then send it myself to get around that.
The playlist doesn't work correctly in directory mode. Would probably be useful if it'd list the directory contents in that case. But I couldn't figure out a way to detect which mode I'm in. Dunno which one you usually use.
Otherwise it should work like any other player supported.
Other stuff:
Updated treemissionlist to use the new icons and added an option to group missions by category. /treemissionlist_grouping 1 makes the list group by category and 0 by title
And because I can't count something new called shortgivemoney.
It's like givemoney but allows to abbreviate the amount
http://kitchen.nfshost.com/ven/plugins/files/shortgivemoney.zip
examples:
/sgm mr_spuck 1m - sends me 1000000 credits
/sgm mr_spuck 200k - would be 200000 credits
/sgm mr_spuck 40b - 40 billion credits
/sgm mr_spuck 1c - is one credit .. that's just for completenes
it's also additive so
/sgm mr_spuck 10k500 - is 10500
/sgm mr_spuck 10m10m10m - is 30000000
and lastly the numeric values can be left out competely
/sgm mr_spuck m - is 1000000
/sgm mr_spuck ccccc - is a really strange way to send me 5 credits
edit:
oh right .. that locknearbylist thing seems to have some issues. I gotta fix that at some point..
doh ..just noticed that selecting tracks after 9 didn't work. It should now.