Av Verifier
The area and mobprog verifier are command line programs written in Ruby. They require Ruby 1.9.3 or later.
Usage
These instructions assume no prior knowledge of programming or running scripts of any kind.
With Ruby installed, extract all .rb
files in the lib
directory to the same location. I drop them at the root of my areas folder. From the console run ruby varea.rb path/to/myarea.are
for area files, and ruby vprog.rb path/to/myprog.prg
for prog files. You will either see:Parsing .\myarea.are...
No errors found.if there's nothing wrong, or something like:Parsing .\myarea.are...
Someone's been a NAUGHTY builder! 1 error, 0 warnings, 4 cosmetic issues.
Line 3768: Door lock type out of bounds 0 to 8
--> 9 9 27473if there is. The line that begins with -->
is the actual offending line from the parsed file. The vprog output is very much similar to what's shown above.
There are a few optional parameters you can feed varea and vprog.
-
nowarning
suppresses warnings. The most common warnings are for resets of objects and mobs that aren't in the area file, or calls to functions that aren't in the prog file. -
cosmetic
(varea only) displays cosmetic warnings that are suppressed by default (as you can see in the above sample). They typically consist of door or edecs with their tildes on the wrong line. -
notices
(varea only) displays notices that are suppressed by default. They typically consist of room exits leaving the area, or when a section can't be found in the file. -
showunknown
(vprog only) displays all 2-character trigger names which are not the predefined types. Naturally most prog files will have several of these, so typically only check this type of output once in a while. -
nocolor
removes all ANSI color codes from the output. Useful if you're piping output to a file or program.
Updating
I intentionally wrote the verifiers in an interpreted language so that anyone can make changes when necessary. This avoids the problem we had previously, in which we had outdated verifiers that nobody could change, which would break when they parsed newer features.
If the verifier ever throws an error or warning about a new feature, check first in avconstants.rb
and progconstants.rb
, which is where many ranges, spec_funs, and conditions are defined. Take, for example:# The three main sections. Script will flip out if it finds an
# unidentified one in the file it's checking.
SECTIONS = %w{ PROGS_MOB PROGS_ROOM PROGS_FUN }
# The known trigger types. Script will not flip out if it finds
# an unknown one, but it will throw a minor error (which is
# suppressed by default)
TRIGGERS = %w{ ER LR DO GO TI GG FO DS BO ST TE EC KS CC FA FC }from the beginning of progconstants.rb
. Hopefully it should be pretty clear how to extend those.
varea.rb
was recently refactored to make it more object oriented and easier to extend and maintain. If you discover any bugs... well, it's on GitHub. Either do your thing or contact me ingame. Also consider using the old version (available zipped on this site, or on GitHub under the
v1-public
tag). vprog.rb
will not receive the same treatment because oh my god no never.
If you need to make any changes to varea.rb
, note that the project is set up to test with
rspec
so use that. Objects and rooms don't have complete specs yet, but writing tests is not my idea of a great weekend, so I'll get to them when I get to them (and their superclass VnumSection is tested as a part of Mobiles). Also, if you need to make changes to vprog
, you're on your own, kid.
Future goals for this project include making the varea.rb
half of the verifier present a proper, consistent API so that it can be plugged into, say, an online area builder or whathaveyou. That was part of the reason behind the refactoring. It is partially in place, but not extremely robust.