Non-scripted (ie. wandering) entity movement is a bit sporadic. They only move one square in any direction. Can we have some way - in Maped and VC - to set the maximum number of steps an entity can wander in any direction before choosing another direction to wander (previously known as their "step" value)? Currently, wandering entities are reduced to an embarassing shuffle.

Also, a fairly serious bug that desperately needs attention:

Whenever a map is loaded, I'm getting this error:

VSP::BlitTile(), tile 64192 exceeds 520

I've never used the command "BlitTile," I don't HAVE 64192 tiles and the total is certainly not approaching 520! Yargh! Also, sometimes I don't even GET an error message if I'm regularly modifying code just before the mapswitch. VERGE just crashes at the same point, presumably for the same reason.

Some additional data on what my tileset is made up of might help: I'm drawing it on a 320x416 bitmap and copy/pasting it into the VSP via the import through clipboard command and with the method of input set to "Replace." (Importing files doesn't work for me, just generating an error). As a result, several lines of my tileset are made of blank purple (rgb 255, 0, 255) tiles. I'd think this wouldn't make a difference but its worth mentioning incase it is.

... And another one:

Passing a number instead of a font to a function like PrintCenter will crash v3 without an error message. Minor, but perhaps worth making a message for it just incase someone does it by mistake and is stuck for days wondering what's crashing their beloved game.

First off: big up to the dev team. I never would have dreamed of seeing verge so stable, powerfull, and yet simple to use. And Maped even opens v2.6 map files? Dang!

Bugs and other oddities I've noticed:
Passing unsupported characters to PrintString() crashes without saying why. Perhaps check and ignore them, or throw an error.

After a map switch, player can first appear a few tiles from where he should. I think either move codes are leftover from the old map or it is accepting/processing input before the ent/map are actually drawn. (may only be noticable if you do something slow like SetResolution() just before/after a map switch)

entity.specframe: Perhaps not a bug, but after ChangeCHR(), maybe it should attempt to use same frame of new chr, or return to normal. Maybe not.

Upon Exit("some text"); mouse not visable when over window.

SCAN_GPLUS is defined wrong, but the engine has it right, since SCAN_GPLUS - 1 works. Should be:
{"SCAN_GPLUS", "78" }

key[SCAN_ESC] = 1; stays 1 until manually set to 0, even after many UpdateControls(), etc. In one function I set it to one to escape an input loop. It returns you to the map, you walk around, talk to the trigger zone again, trigger the function, and it escapes immediately, thinking esc is still pressed. Took me forever to figure out why. Log("Flows past here."); is my friend.

v1_rpg.vc:
Perhaps RemovePlayer() should hide/destroy removed .chr.

Wishes:
HookFunction(VergeFunction, CustomFunction);
The engine would have to know that calls to VF from within CF meant the real VF.
Example:

HookFunction(PrintString, PrintStringI);


void PrintStringI(...) // (... = actual matching params)


{


if(HasSpecialChars(text)) PrintSpecial(...);


else PrintString(...);


}





// Also:





struct Enemy { int blah; }


Enemy* group = new Enemy[enemies_in_group]; // the heading does say wishes. ;)


if(Enemy) delete [] Enemy;

That's about all I can think of for now.

Keep up the great work.

[forgot a paren]

ugh. That's as discouraging as the mapload bug that goes away when you put a log() statement in the right place :/

ugh. That's as discouraging as the mapload bug that goes away when you put a log() statement in the right place :/

Yup, that's a word-for-word description of what I'm wrestling with, although it is becoming more confusing the more I mess with it. Yargh.

Ok, I have just fixed a ton of bugs, including the problem that people were having with Sully crashing at mapswitch, and the people that had HookTimer crashing. I've also fixed lots of the smaller bugs that you guys have mentioned.

I will add that the key[] behavior is intended. If you manually set a key to 1, then it will stay pressed until you either programmatically set it to 0, or until the physical key is pressed and released. Note that if the key was programmatically set to be pressed, and then the user actually pressed the key, you might not notice it by checking the key[] array, but the b1 etc 'buttons' will update, as well as hookkey (which will be implemented in the next EXE).

Overall it seems like all the 'random instability' problems are now solved and I'm quite happy about that, plus there will be some cool new features in the next version, so.. yay :D

Lastly, can you point me to the 'volume 666' bug? I've done volume fades in sully and it certainly seemed like it was working right to me. I cant find anything that would conceivably cause that in the code, and at the time being, the forums lack a search feature :/

if I try to change the entity.frame[] value, it crashes with an HVAR1 error.

I found another seemingly random bug. I was using some functions from v1_rpg.vc and when I would use FadeOut(100) at the end of my battles I would randomly get a crash with no message. I narrowed it down, and if I comment out the Render() function in there, I dont get crashes...just not a very nice fade. I use the same exact FadeOut() function other places in my code, such as at the beginning of combat, so I don't know why it works in one spot and not in another. What I ended up doing was making a copy of FadeOut() called FadeOut2() and took out render from #2, and just use that one in my end battle code. Kinda messy, but now I still have the functionality of the FadeOut() code and I dont get random crashes at the end of combat. :P

I'm not sure if this is a bug or not, but when using PrintString with a Fixed Width font, the characters on each string are spaced 2 pixels apart. Is this normal?

Oh, and my font is made to where each character is perfectly enclosed in a 7 x 7 square, so the font itself has no extra space put into it.

Alright, sent.

When Autoexec() is the last function in system.vc, and you accidently lose it's closing brace, it still runs fine, without any sort of error. A wild goose chase confirmed that it wasn't borrowing one from elsewhere.

This is a working system.vc, no #includes, no #defines:

void Autoexec()


{


int bounce = 0;


while(!lastkey && !key[SCAN_ESC])


  {


  if(bounce <= systemtime)


    {


    bounce = systemtime + 2;


    RectFill(100, 22, 150, 52, 0, screen);


    PrintString(100, 22 + (timer % 10), screen, 0, "Odd, no?");


    }


  showpage();


  }

I just thought that was really odd.
El