|Synthetic Reality Well of Souls|
|World Developer Information - Cookies|
The cookies referred to here are neither a bakery product, nor the little notes your browser keeps about your personal activities on the web. These are cookies used in the context of the Synthetic Reality Role Playing Game "Well of Souls" and are used to hold world-specific data on behalf of characters within the game. Any normal programming language would probably call these variables (or objects, if it was bein' high-falutin'), but for some reason the work cookie appealed to me at the time. And with such capricious decisions do programmers become doomed.
Cookies are only available to a running 'scene script' (which was written by the developer of the world you are playing).
The script has limited options of what to do with cookies. Basically they can be written (saved to the character's file on disk) and read (recovered from disk), and some simple comparison and math operations may be performed with them.
Every cookie has a name, and that name usually is defined by the World Developer. If two cookies have the same name, then they aren't two cookies, they are the same cookie. So keep your names straight. For reasons it would take a scientist to explain, you need to 'wrap' the cookie name in a weird syntax to read it, but can just use its name when setting it.
So SAVING a cookie might look like this:
But READING the cookie might look like this:
It's the #< ... > which is the wrapper, and you will eventuallly get a sense for where it is needed. Anyway, it was not my intention to get into the details here. The point of this page is to document the ever-growing list of STOCK COOKIES.
For the most part cookies only exist when you SET them. (and only the scene host gets the cookie set), and you shouldn't use a cookie to do the job of a TOKEN. However, there are some cookies which the engine sets for your convenience. These are called STOCK cookies, and you should avoid making cookies of your own with the same name.
Just to repeat the important bit: unlike regular cookies which just hold some data that the World Developer made up. These STOCK cookies give you access to stuff that you might be interested in, and they can NOT be used for general data storage. They hold only what is described here. This list is the only way you know what cookie names are STOCK (i.e. defined by the game and not available to you for general use). If you innocently make a cookie with the same name, you will no doubt be confused when it doesn't seem to hold what you expected.
Most stock cookies are READ-ONLY, meaning that they tell you something you would like to know, and ignore your attempts to stick data into them. But you can write to SOME stock cookies, so pay attention (and hope I document it correctly - I put a W in the column of cookies which can be both read AND written. All cookies can be read, of course!)
Please note that if a cookie has information about a character, it is always about the HOST of the scene (only the host executes the script code)
Here is a summary of all available stock cookies:
To implement arrays and other fun things, you need a cookie which "points to" another cookie. You can achieve this goal via the asterisk (*) character.
I hope that made sense. I wrote it down better somewhere else, but for some reason I can't seem to find it. If you ever see any documentation that says to use @ instead of *, then let me know. It was a mistake to use @ (in A70) and I changed it to * for A71.
Your world may need to do a lot of scripting in the standard camp or fight scenes, based upon which map the player is on. You can do this by testing against all your map numbers or link numbers, but that quickly becomes tedious.
As of version A74, each link may have a 'camp style' number assigned to it (you do this with the LINK EDITOR... it's just a number, and the game makes no use of the number. It's up to YOU, master scene designer, to make it useful)
For example, your world may have 2 major sorts of terrain... dry and wet, or light and dark, or good and evil... You might assign camp style '1' to mean one, and '2' to mean the other (and if you have more sorts, use more numbers).
Then, using the link editor, you assign a style value to each of your links.
Then, in the scene code for the standard camp scene (for example), you simply test one cookie (#<num.closestLinkStyle) and use its value to determine anything special you do for ALL 'good' scenes or 'bad' scenes. Setting the background, weather, etc.
To some degree this is redundant to the pre-existing values in the link editor, but this one is general purpose and can mean what YOU want it to mean.
Fight Monster Info
You may want to do something special in your script depending on what monsters were just fought. There are two cookies to let you check that out.
The first one (monster.lastFightCount) tells you how many monster took part in the fight. This does not includ heroes (no matter whose side they were on) or pets (ditto), nor does it include any friendly monsters (For example when you use the FIGHT command and have a negative value for the monster id to make it fight on the side of the heroes). It's just the number of bad monsters that got added to the scene over the course of the fight. It gets cleared to 0 at the start of the next scene (even if it isn't a fight), so you can only take advantage of this cookie while still in the fight scene itself
The second one (monster.lastFightIdNN) is actually an array of cookies. Instead of typing 'N' you need a number between 1 and the lastFightCount (so if lastFightCount says there were 4 monsters, then use 1, 2, 3, and 4 to check out data about the individual monsters.
Please note that you can only see general info about the monsters and not specifically whether they got killed, who killed them, etc. This is good for handing out special rewards for killing particular sorts of monsters.
Here is a possibly silly example...
You might want to do something special on a special holiday. You can do the math yourself, of course, but the holiday cookies will help you detect certain world holidays.
#<num.holidayId> will return one of these values (the number), including '0' for 'today is not a holiday I recognize'
Sorry for the USA Bias, but what can I say? Also, the BIRTHDAY is of your WoS character, not you personally.
So, say your world has need for a
lot of tabular data.. stuff that the WoS engine doesn't
need to know about directly, but that you use in your
scripts a lot. Say you have your own skill system, or
potion making formulas or anything else which can be
defined by rows of columns of data in a table.
; This is my table of skins used in my mini-game ; ROWID, COL1=Actor#, COL2=SkinName Butter, 1, "Jumping Butter Can" Cheese, 2, "BlueCheese" ; Note, dan doesn't read these comments ; so that stuff I said about COL1 is just for me
Then, to read the table in my SCENE script, I need to do three things:
|copyright 2004-2013 (c) synthetic-reality.com|