Where to start

When you run VERGE.EXE without "releasemode 1" in the VERGE.CFG file, it will attempt to compile the vc code. Assuming there are no errors in the code, it will then start the game in the AutoExec() function within the system vc. If you don't have an AutoExec() in your system vc code, VERGE will just exit unceremoniously, no errorbox or other message.

Before I tackle the order of events in Sully, first we're going to bring up some tips and tricks for debugging vc code that will not compile.

Debuggery!

vc is flexible, but it's sometimes cryptic. At present, the sometimes ambiguous compile-error messages would have to be my second biggest pet peeve. First I'll cover some errors you will encounter, and what they mean.

(Note that all fatal errors will have their message after something like "Exiting: system.vc(60):". That specific message means that the bad line is in the system.vc file around line 60. If you are using Textpad like Rysen (and vecna. And I.) suggest, then you just open up system.vc, press CTRL-G, enter the line number (60 in this case), hit enter, and you will be automagically transported right to that line.
...trust me, this'll become second nature before too long. )

also note: if the error message starts with "Exiting: preprocessor step:", then something went wrong with the preprocessor, which is very specific and is checked before anything else. This basically means that something went wrong wither with a #define statement or an #include statement.

And now, some common error messages:

"SomeName" is not a recognized keyword or identifier!

This means that "SomeName" is not a built-in vc function or variable, and it's not a user-defined function or variable. This is very easy to correct; You either misspelled it, or you never defined it in the first place.
No matching bracket.

This is one of the errors you'll get from that most-common of programmer's foes: the missing semicolon. with the exception of conditionals, loops, and function definitions, every line of code needs to end in a semicolon. You'll get this error if you had this:
```
void AutoExec()
{
	int caca

	ShowPage();
}
			
```
Instead of
```
void AutoExec()
{
	int caca;

	ShowPage();
}
			
```
Exiting: preprocessor step: circular dependencies on system.vc

You will recieve this error if you ever have a file either #include itself, or have two files both include each other. For instance, if you put:
```
#include "system.vc"
```
in system.vc, then the compiler would open it up, hit that line, open it up, hit that line, open it up, hit that line, etc. Into infinity. That'd be bad.
A good way to avoid this is to make all your includes in a clear order. I tend to make a master include file so I can keep track of things that might have dependancies. In Sully Simpletype, that file is "vc/includes.vc".
Exiting: Unknown HVAR0 (42) (set 3):

Whenever you see an "Unknown HVAR" error, that means one thing: you've tried to set a new value to a read-only variable! Look for a read-only system variable around the line number you've given.
To see this error in action, compile this function:
```
void AutoExec()
{
	entities = 17;	//entities is the variable that reports how
			//many entities are presently on a map.
}
		
```

I'll add more common errors and what they mean as I come across them. I really should've been compiling this list over the last few weeks, but I didn't think to. If anyone wants to contribute errors, their causes, and their solutions to this list, please email me , aim me (AIM: astradian) or leave a message about it on the forums.

General debugging techniques

Sometimes you'll find an error you just can't figure out. If it's a compile error, and you can't locate what's going wrong, you really have to localize the error. Here's two ways to do this.

You can either insert garbage above the line the error is reporting to, or comment out the offending line. Say you had the following block (the grey nubers represent line numbers, they aren't in the code):
```
41	taco = bob;
42	if( TonyRandalLives() ) {
43		bob = 17;
44	} else
45		exit( "I am a banana" );
```
And you keep getting something like Spooky Error on line 43, your first task is to identify if it's actually line 43 that's erroring, or if it's something else nearby, or if it's something else entirely. If you changed it to:
```
41	taco = bob;
42	if( TonyRandalLives() ) {
43dflkjsf
44		bob = 17;
45	} else	exit( "I am a banana" );
```
And you still get the same error, it means the error is higher up. Rinse wash and repeat until you get system.vc(some line number): "dflkjsf" is not a recognized keyword or identifier!, and then you've found the error. If you got that error right away, tho, start moving it down, like:
```
41	taco = bob;
42	if( TonyRandalLives() ) {
43		bob = 17;
44dflkjsf
45	} else	exit( "I am a banana" );
```
And if the original error appears, it means bob = 17; really was to blame, and now you know for a fact what's wrong. If instead you keep getting the "dflkjsf" is not a recognized keyword or identifier! error, well, you've not yet found the real error! Keep moving the garbage down until you find it!

This method is rather hacky, but it works fast, especially if you're good with CTRL-X and CTRL-V.
Alternately, you can just comment out whole blocks. This is a very good method if verge is completely lying about the origin of an error (which can sometimes happen with errors in other files due to #include). If you can't localize a problem, try commenting out the entire body of the current function. Then the next error message should be more forthcoming. For instance, assume this function has a mystery error reporting within it:
```
int myFunction() {

	// pretend there's a
	// whole bunch of code in
	// here
	//

	return caca;
}
```
Well, if you change that to:
```
int myFunction() {
	/*
	// pretend there's a
	// whole bunch of code in
	// here
	//

	return caca;
	*/

	return 0;
}
```
and it still errors, the new error message will be closer to where the real error is. If the error's gone, well, you at least know the real error lives inside that funciton. Then you can use method #1 to localize it. Yay for you.

«Overview«

»The V1 RPG effects library»