There are now four new read/write string variables accessible to verge3 via vc:

trigger.onStep
trigger.afterStep
trigger.beforeEntityScript
trigger.afterEntityScript

These are global callfunction triggers. If they are blank, or if they are set to a string that isn't a vc function name, nothing happens. But if they are set to a vc function name, awesome magic happens!

If trigger.onStep is set to a vc function name, that function will be called everytime the player entity crosses a zone activation border, regardless of if a zone is about to be activated. If a zone will be activated, this function occurs right before that zone's script goes off.

If trigger.afterStep is set to a vc function name, that function will be called everytime the player entity crosses a zone activation border, regardless of if a zone is about to be activated. If a zone was activated, this function occurs right after that zone's script goes off.

Both trigger.onStep and trigger.afterStep's assigned vc functions will have access to a proper event.tx, event.ty, regardless if a zone gets activated. Note that this is a change in behavior, as event.tx and event.ty are now updated at a new point. If this breaks anyone's day, please let me know.

These two triggers are good for things like dealing with poison and tintinabar-style effects and step counters, which are more dependant on the act of walking than on any specific zone. I was brought to implement this specifically because there was no good way to deal with decrementing the "steps to battle" counter for Sully, and this seemed like an idea whose time had come.

If trigger.beforeEntityScript is set to a vc function name, that function will be called before any entity's onActivate script is called.

If trigger.afterEntityScript is set to a vc function name, that function will be called after any entity's onActivate script is called.

Both trigger.beforeEntityScript and trigger.afterEntityScript's assigned vc functions will have the proper event.tx, event.ty, and event.entity values available to them, just like the entity's onActivate script does.

These two triggers are great for handling universal pre- and post-conditions for entity onActivate events. Specifically, in Sully it was getting tiresome to have to tell the game to forbid the menu as the first line of every entity's onActivate script, and it was getting tiresome to tell the game to re-allow menus afterwards. If you forgot any of these, you basically created a gameplay bug! Awesome, eh?

Forthcoming, but not implemented yet, are similar variables for before and after any zone has been adjacently activated. I'm also looking into making a new kind of zone activation which would activate when you push against it. Imagine a closed door opening when your player pushes into it. I am eager to listen to any suggestions for both new callback triggers, and new script activation conditions.

Please, share your thoughts!

Hi there everyone. It's been pretty quiet around here lately. How are you? We should meet more often! I've brought something for you.

Things have been happening, I assure you. We've just all gotten afraid of telling anyone! Or maybe, the people who really want to talk are all talked out from Gruedorf posts. Whatever the reason, I'm breaking the silence! Over the last couple of days I made various fixes to bring the Mac OS version of the engine up to date. Then, I spent this evening putting together a new release of Sully, pulled from the SVN repository, based on McGrue's instructions. I've put them together, and I've brought it here for you to enjoy!

This isn't your grandma's Sully Chronicles. A lot of changes have happened since the Ancient Times. Most noticeable (at first) will be graphical updates pretty much everywhere. Another thing to take note of is the addition of entirely new sections of story!

I hear that all this stuff was planned all along but just never got into the earlier versions of the demo. It's very cool (and I don't just say that because I designed two of the towns and did some of the graphics :D). In any case, there are still plenty of warts -- this is very much a WIP version of the game. I hope that doesn't diminish your enjoyment of the game, though!

Click here for the Windows version.
OR
Click here for the Mac OS version.

Play! Play and have fun! Play and be inspired!

mcgrue: Saturday night I was running into php errors on something I was trying to install on the same server as verge-rpg.com. The errors were obscure and nonsensical, so I figured it was time to try a php upgrade. A long story short: a dependency chain basically bit me in the ass, and our mysqld became... somehow uninstalled (why uninstalling Exim would do this, I don't know. Le sigh.)

By 8 AM sunday morning I'd reinstated a mysqld on vrpg's server, but it was now mysql 5 instead of mysql 4. There were some underlying sql syntax changes. And by this point I was exhausted and continued to be too tired to work on it after work.

So I brought in the canadian cavalry...

Overkill: When we updated to MySQL 5, vrpg's website codebase had lots of magical error messages involving operator precedences of joins vs comma operators. It, of course, had misleading error reports too, so then it lead me to think the error was happening in a completely different file than the boards index.

Moral of this story: copy-pasting your error reports is BAD! Everything should be normal again now though.

mcgrue: I think there are a few more morals than that here, but... yeah. Anyways: the site is back up!

For those of you who like new exes, I just built a new windows executable current as of today's svn revision (200).

You can get it at: http://www.verge-rpg.com/svn/verge3/trunk/redist/verge.exe.

username: anonymous
password: anonymous

For those interested in making modifications to the verge executable, I posted instructions on how to add a new vc function over at egometry.com.

New in this revision are the final two functions of this list (but you may not have been aware of the rest of them...) :

SetCharacterWidth()



DictListKeys()



ListBuiltinFunctions()

ListBuiltinVariables()

ListBuiltinDefines()



GetPlayer()

	

GetUserSystemVcFunctionCount()

GetUserSystemVcFunctionByIndex()

So there you go. A new WIP build of the EXE. If a mac-haver would like to compile the current revision we can bottle it all up and officialize it! Please: test the crap out of it.

Man, It's way too late. Who loves ya, baby?

Okay, I'm gathering data for the next update. Here's the list of newcomers I have since the last big update:

RPGKing - DragonQuest: Abberance
Ioachim (site out of commission) http://moonwalk.3host.biz
IkimashoZ - CPhon
Eldrich - Serinor
Mordred - Spectre Engine

So if you announced you're competing and you weren't on the old list and you aren't on this list, you have slipped through the cracks! Please respond in this thread if I missed you and I'll get you in the update.

Thanks!

If there's anyone out there using the Lua bindings for Verge, here's a note about an issue that has had me tearing my hair out for the last 24 hours or so. Overkill helped me figure out what was going on here.

By default, all of the Verge stuff (its variables and its functions and whatnot) all got tossed into a table called LuaVergeRaw. This was kind of a pain to work with so one of the things that you could do was to import all of that table into the global namespace, _G. Unfortunately this had the side effect of clobbering the first-tier variables like xwin and timer. (Well, specifically, you could get their value like you were supposed up to the moment you tried to assign anything to them; after that your value of the variable and the engines became unsynced.)

In any case, Overkill and I, being the primary users of Lua in V3, had a quick chat and decided the best solution here was to just use the LuaVergeRaw table, but give it a better name. We renamed it to v3, because it's short and in keeping with Lua's style for libraries.

In any case, if you have done any LuaVerge development, be warned that the newest version in the SVN (checked in about five minutes ago) will probably break your code. Sorry about that.

(By the way, for those who follow such things: My host is currently down so this is going to have to server for my weekly Gruedorf post until it's fixed.)