Forums » Suggestions
Hi
I recently came back after not playing for a bit and was delighted to see two of my "must have" features implemented, namley bindings for the numeric keypad in linux and comments in scripts. Also the saved nav route thing is wonderful. I'm back to working on my menu driven script and have some questions/suggestions.
First, my wishlist, this is all scripting stuff. I don't expect these to actually be implemented, like I say it's a wishlist...
A /play command to play one of the sounds that comes with VO. Being able or play the VO menu sounds for scripted menus improves usability a fair bit.
Some kind of colour codes that can be embedded into echo statements. No says need this, I understand that ppl shouting in 17 different colours may not be desired, but in echos it makes the visibility of menus a lot better.
A /log command, like echo but writes to log only, not shown in any on-scren chat windows.
A /say_log command, accepts a player name and adds something to their log without showing it on-screen.
Increased resolution for the sleep command, or perhaps a usleep command.
The last three would be useful for interfacing with external scripts. This might be a no-no for security reasons, but it could also add a lot of functionality. External scripts can already be used with VO, I had a ruby script parsing errors.log continuously for input, and generating a vendetta script which VO read once a second. There is no evil crackerish stuff going on, everything interfaces with VO through VO script.
External scripts allow lots of groovy stuff, some very useful, some just groovy. For example you could have an in-game interface to a mining database, or auto-plot a course to avoid asteroids, or keep track of ion storms. Virtually anything that can be done with menus and a computer could be done in VO.
What can be done with this scripting power? The first thing I thought of was automatic tracking of ion storms. Any that show up in the log go into a database, in the game you pull up a list of storms in a given system. After a while the entries are deleted from the database as storms don't last for ever.
Now we get to the virtual networks bit, time for an example. Say you have two traders, both use a script for logging ion storms. It is possible for the ships to update their ion storm database from each other. Alternativly, if a channel was created for storm reports the script could monitor/report to the channel, From a RP point of view I prefer #1 as it would encourage people to talk to each other and make people rely less on OOC methods of communication for info.
I'll post a link when I have something ready, what do people think?
I recently came back after not playing for a bit and was delighted to see two of my "must have" features implemented, namley bindings for the numeric keypad in linux and comments in scripts. Also the saved nav route thing is wonderful. I'm back to working on my menu driven script and have some questions/suggestions.
First, my wishlist, this is all scripting stuff. I don't expect these to actually be implemented, like I say it's a wishlist...
A /play command to play one of the sounds that comes with VO. Being able or play the VO menu sounds for scripted menus improves usability a fair bit.
Some kind of colour codes that can be embedded into echo statements. No says need this, I understand that ppl shouting in 17 different colours may not be desired, but in echos it makes the visibility of menus a lot better.
A /log command, like echo but writes to log only, not shown in any on-scren chat windows.
A /say_log command, accepts a player name and adds something to their log without showing it on-screen.
Increased resolution for the sleep command, or perhaps a usleep command.
The last three would be useful for interfacing with external scripts. This might be a no-no for security reasons, but it could also add a lot of functionality. External scripts can already be used with VO, I had a ruby script parsing errors.log continuously for input, and generating a vendetta script which VO read once a second. There is no evil crackerish stuff going on, everything interfaces with VO through VO script.
External scripts allow lots of groovy stuff, some very useful, some just groovy. For example you could have an in-game interface to a mining database, or auto-plot a course to avoid asteroids, or keep track of ion storms. Virtually anything that can be done with menus and a computer could be done in VO.
What can be done with this scripting power? The first thing I thought of was automatic tracking of ion storms. Any that show up in the log go into a database, in the game you pull up a list of storms in a given system. After a while the entries are deleted from the database as storms don't last for ever.
Now we get to the virtual networks bit, time for an example. Say you have two traders, both use a script for logging ion storms. It is possible for the ships to update their ion storm database from each other. Alternativly, if a channel was created for storm reports the script could monitor/report to the channel, From a RP point of view I prefer #1 as it would encourage people to talk to each other and make people rely less on OOC methods of communication for info.
I'll post a link when I have something ready, what do people think?
I think it sounds kinda neat. :-)
Indeed, very cool.
However, once you're done poking around let's make an interface that the "rest" of us wannabe-scriptkiddies could use, OK?
However, once you're done poking around let's make an interface that the "rest" of us wannabe-scriptkiddies could use, OK?
Hmm. The Ion Storm database sounds like a fun idea, and one that'd take me about 20 seconds to add onto the existing VaultBot/UID-Ruby codebase (I never named the underlying engine. I should!). E-mail me. Roguelazer@gmail.com.
The interface should be fairly simple, along the lines of this: http://www.vendetta-online.com/x/msgboard/9/10126. The numeric keypad will be used for input and menus will be displayed on-screen. Things might get a little involved if you wanted to customize things, but that shouldn't be required.
the problem with an ion storm database is to make dynamically generate navroutes that avoid them. navigation in VO isn't shortest path or anything near it, it is an interesting (probably NP complete) task to map where you jump to avoid a set of marked sectors in a system.
so, what you end up with instead is to create lookup tables in every system that provide safe navroutes and use these stubs to generate a proper route between your position and your goal. these safe navroutes then ensure that you never run into a storm, which makes the storm detection pointless.
so, what you end up with instead is to create lookup tables in every system that provide safe navroutes and use these stubs to generate a proper route between your position and your goal. these safe navroutes then ensure that you never run into a storm, which makes the storm detection pointless.
I see your point, perhaps someone could ask the devs what algorithm they use for working out what sectors a ship jumps through? There are other uses for this than just ion storms so I'll keep going, but you are right about the storm database, not a huge point when u can just navigate around all rocks.
You could allready do that storm database and a storm-avoiding script. From the logs your external program can keep track of where you are. With an echo you can tell the external program where you want to go. The external program then programs the navroute for you and puts the load command in a script that gets executed automaticly.
Combine that with a simple database for storms, with a web-interface and yer done. Programming something like this in Python or Ruby is fairly simple.
Combine that with a simple database for storms, with a web-interface and yer done. Programming something like this in Python or Ruby is fairly simple.
the devs don't have a route mapping system apart from the direct, shortest, path. if they did, the cap ships wouldn't die before getting to B8. if they've solved this task, I'll be very impressed from a techincal POV, but somewhat depressed that the cappies didn't use it. :-)
also, please watch the timing conditions for doing /load on files while populating them. especially on Windows, the sleep required to time this all right is *really* hard to pull off, since the accuracy / resolution of the standard sleep on Windows is crappy.
I've mentioned my wish for a socket to talk to the VO client before, to avoid duplicate reads and to remove a lot of ugly load-loops / truncations of files.
*if* you have to pull the load version, write a multithreaded application where one thread only deals with writing and truncating the loaded file. this ensures that execution time in populating the file doesn't influence the timing issues involved.
remember, if every execution takes 0.001 seconds, after 1000 executions, you're sleeping 1 second out of sync with the original sleep in VO. during time you will probably have gotten a double load at some point as sleep doesn't have a 1s resolution anywhere, let alone on Windows. 1000 executions isn't even 17 minutes.
as for the sleep in VO, I haven't found a good way of testing its accuracy since log output / IO is also a factor. however, the load isn't threaded -- load from a blocking filehandle, like a FIFO queue and you'll see a nice effect.
another suggestion you might want to consider. to look up data from an external source, consider offering it via HTTP. most languages have nice libraries for HTTP and you don't have to expose the DB itself to the outside world, nor give everyone access to the DB proper. just mind authentification somehow, since you don't want to send the password over HTTP (HTTPS is a different matter, but HTTPS gets expensive for minute amounts of data gathered often). there are ways of doing this though, some creating thinking is advised. :-)
also, please watch the timing conditions for doing /load on files while populating them. especially on Windows, the sleep required to time this all right is *really* hard to pull off, since the accuracy / resolution of the standard sleep on Windows is crappy.
I've mentioned my wish for a socket to talk to the VO client before, to avoid duplicate reads and to remove a lot of ugly load-loops / truncations of files.
*if* you have to pull the load version, write a multithreaded application where one thread only deals with writing and truncating the loaded file. this ensures that execution time in populating the file doesn't influence the timing issues involved.
remember, if every execution takes 0.001 seconds, after 1000 executions, you're sleeping 1 second out of sync with the original sleep in VO. during time you will probably have gotten a double load at some point as sleep doesn't have a 1s resolution anywhere, let alone on Windows. 1000 executions isn't even 17 minutes.
as for the sleep in VO, I haven't found a good way of testing its accuracy since log output / IO is also a factor. however, the load isn't threaded -- load from a blocking filehandle, like a FIFO queue and you'll see a nice effect.
another suggestion you might want to consider. to look up data from an external source, consider offering it via HTTP. most languages have nice libraries for HTTP and you don't have to expose the DB itself to the outside world, nor give everyone access to the DB proper. just mind authentification somehow, since you don't want to send the password over HTTP (HTTPS is a different matter, but HTTPS gets expensive for minute amounts of data gathered often). there are ways of doing this though, some creating thinking is advised. :-)
The Noid, the issue is *how* to calculate how to avoid the storms. NP-complete problems aren't trivial to do, even with only 256 nodes, let alone in an app that doesn't get to use CPU time since you're playing a 3D FPS at the same time and want it to get all the CPU it needs. on certain platforms, priorities / nice works, on most, it doesn't.
and, if you can provide fast navroutes to avoid storms, why use the direct route at all? there are very few cases where the direct route actually saves time, even if it takes you 10 seconds to hop through an empty sector. with the last set of changes, it became more interesting to go directly, but it's still not worth it. most human-produced routes don't just make you safe from storms, they put you close to the WH when you get out from your safe route. if you're always safe and always close to the WH and the time difference is statistically in your favor why use anything else?
now, the day storms have a value or reason, we can have storm-hunters who report their data to a DB that others can pay to have access to. it's almost weird that noone has done this already. oh, wait... someone has. :-p
and, if you can provide fast navroutes to avoid storms, why use the direct route at all? there are very few cases where the direct route actually saves time, even if it takes you 10 seconds to hop through an empty sector. with the last set of changes, it became more interesting to go directly, but it's still not worth it. most human-produced routes don't just make you safe from storms, they put you close to the WH when you get out from your safe route. if you're always safe and always close to the WH and the time difference is statistically in your favor why use anything else?
now, the day storms have a value or reason, we can have storm-hunters who report their data to a DB that others can pay to have access to. it's almost weird that noone has done this already. oh, wait... someone has. :-p
A socket that could act as a VO script console would be wonderul. Getting data out is really easy (through errors.log), but getting data in is a pain and my method is an ugly hack. There are a few other ways this could be done, perhaps a command line switch for the VO client that enables script commands to be input on stdin? Getting rid of the wait would be way better than improving the timer resolution. I guess it comes down to whether the devs think this is useful, desirable and worth the effort.
As for problems with synchronizing the file, my method is as follows (when sending a script to VO):
1. Append the command 'echo "!VORS:DONE";' to the script.
2. Write the script file.
3. Wait until the done command is read back from errors.log.
3. Truncate the file.
Right now any input recievied from errors.log while waiting on a command to complete is discarded, I should really queue the input and parse it later. The sleep in the ruby script is 0.2 seconds, but as long as it's less that 0.5 it should be fine. It's working fine, but the lag caused by that 1 second delay in the VO end of it is frustrating, as is the fact it spews !VORS:DONE in my chatlog (hence my /log command request).
As for interfacing with websites and the like, it is a good idea, possible, and probably desirable. IMO such things should be thought about carefully though, I want to create something that enhances the game, I want to steer clear of anything that could be considered cheating.
My character spends his days mining rocks, hacking his flight computer, and dreaming of creating an interstellar internet.
As for problems with synchronizing the file, my method is as follows (when sending a script to VO):
1. Append the command 'echo "!VORS:DONE";' to the script.
2. Write the script file.
3. Wait until the done command is read back from errors.log.
3. Truncate the file.
Right now any input recievied from errors.log while waiting on a command to complete is discarded, I should really queue the input and parse it later. The sleep in the ruby script is 0.2 seconds, but as long as it's less that 0.5 it should be fine. It's working fine, but the lag caused by that 1 second delay in the VO end of it is frustrating, as is the fact it spews !VORS:DONE in my chatlog (hence my /log command request).
As for interfacing with websites and the like, it is a good idea, possible, and probably desirable. IMO such things should be thought about carefully though, I want to create something that enhances the game, I want to steer clear of anything that could be considered cheating.
My character spends his days mining rocks, hacking his flight computer, and dreaming of creating an interstellar internet.
You can write to errors.log? Hmm. If I change the file at all on Linux or OS X (delete things, write things, etc), Vendetta stops appending. It seems to use some sort of odd IO blocking that gives up if it loses control. Oh, and you do know that Ruby rounds off fractional sleeps to integers, right? From the pickaxe book, 2nd edition, page 529:
"sleep: Suspends the current thread for numeric seconds (which may be a Float with fractional seconds). Returns the actual number of seconds slept (rounded), which may be less than asked for"
"sleep: Suspends the current thread for numeric seconds (which may be a Float with fractional seconds). Returns the actual number of seconds slept (rounded), which may be less than asked for"
touching errors.log works to a certain degree, but not well on Windows.
I have some code done, Linux only and fairly basic right now. Please excuse the silly name, it stands for "Vendetta Online Ruby Script". Making it work on windows should just be a case of changing paths and slashes (I think, I know nothing of windows). You can get it here:
http://www.drasil.pwp.blueyonder.co.uk/downloads/games/vo/vors.tar.gz
1. Uncompress into ~/.vendetta
2. In the game use /load "vors/vors.cfg"
3. In a console: pushd ~/.vendetta/vors; ruby demo.rb; popd;
I'm not writing to errors.log, it didn't cross my mind TBH. The sleeps are just fine, ruby may round the return value of sleep to an integer, but the actual time slept for is correct.
I have been told that there are similar things available, is this redundant?
http://www.drasil.pwp.blueyonder.co.uk/downloads/games/vo/vors.tar.gz
1. Uncompress into ~/.vendetta
2. In the game use /load "vors/vors.cfg"
3. In a console: pushd ~/.vendetta/vors; ruby demo.rb; popd;
I'm not writing to errors.log, it didn't cross my mind TBH. The sleeps are just fine, ruby may round the return value of sleep to an integer, but the actual time slept for is correct.
I have been told that there are similar things available, is this redundant?
That's an interesting way to do it. I never though of using a listen style of event monitoring... Seems like it might get bogged down with heavy usage, though.
/me goes off to steal some ideas. For example, your idea of storing the current sector and system never occurred to me. 'tis brilliant! And now, 'tis stolen. It's much better than the way VaultBot tracks his current system (website, bleugh!).
/me goes off to steal some ideas. For example, your idea of storing the current sector and system never occurred to me. 'tis brilliant! And now, 'tis stolen. It's much better than the way VaultBot tracks his current system (website, bleugh!).
I think Alamar already grabs the location from "You are entering the Foo system, Sector Xyzzy" and has for a loooong time :D
Glad ur finding it useful :)
The philosophy VORS uses is to read input as it happens then act on it, it should never need to (or be able to) look back in the log for something that happened in the past. I think the listening should be fairly efficient, there is only one sleep and that's in the listen loop. My biggest worry is the way events are handled, it needs to check (at most) a regexp for each trigger that's set, and it does that every time VO adds a line to errors.log. I'll have to do something about that.
/me goes to search for Alamar
The philosophy VORS uses is to read input as it happens then act on it, it should never need to (or be able to) look back in the log for something that happened in the past. I think the listening should be fairly efficient, there is only one sleep and that's in the listen loop. My biggest worry is the way events are handled, it needs to check (at most) a regexp for each trigger that's set, and it does that every time VO adds a line to errors.log. I'll have to do something about that.
/me goes to search for Alamar
Do what I do and run the loop outside of the file reading section so that (since Vendetta only accepts input after 1s anyhow) the file reading section only gets called once per second and has a full second to act upon its input, then buffer everything and use multiple threads. :P
If it becomes a performance problem then I might give it a try. The input from errors.log is buffered already, but I'd rather not use threads if I can avoid it. I am checking the file more often than is required, but I don't think I'm taking too big a performance hit for it. top tells me it's nowhere near eating all my cpu cycles. Of course if I could see ur code I may change my mind ;)