posted                       

These are the release notes for Well of Souls Version A89.

---------------
CHANGES FOR THIS RELEASE

* COMPATIBILITY: Excellent! - But you will only be able to play with other A89 users.

* TROPHIES CAN BE GIVEN

It works a bit like giving gold. First you open your trophy bag and right-click on a slot containing something you would like to give away.

The popup menu now includes a GIVE option.

After selecting that, the cursor will change to the new 'trophy' cursor and you can left click on someone in the scene to give them ONE of the selected trophy.

Sorry, I lack the ability to give them the entire stack at once, isn't that stupid?

But to make it slightly easier, I leave the cursor active so you can give one after another.

To clear the cursor, you can: close the trophy bag, select some other cursor, or empty out the slot in question.

The item given event will have an itemId of -1, and a new cookie 'trophyGiven' with the trophy id.



* NEW TROPHY BAG BEHAVIOUR

If you hold the SHIFT key down while dragging trophies from one slot to another, it will move only ONE, and not the full stack. You can only use this to drag to an empty slot, or a slot which already contains the same sort of thing. Amongst other things, this is how you pull a few off the stack to sell less than the full amount.


* NEW MIX RECENT ACTIVITY METER

The dialog with the list of MIX servers on it, now has a little activity meter that lights up when you select a server (before you connect to it). This shows you how many people are on the server NOW (redundant), how many have visited in the last 20 minutes, the last hour, and the last day.

The idea here is to let you see that even though a server may be empty RIGHT THIS SECOND, that it is actually a pretty active place and maybe it would be worth your time chilling in it for a minute, rather than just jumping to the server with too many people in it

Honestly, I put this in more for Arcadia (which shares the same code), but I think it has some usefulness in WoS as well.


* New TNL METER.

I added a little horizontal meter just under the chat splitter bar. (It shows only if you have the splitter pulled up enough to show the server name bar, which I notice a lot of peopler don't seem to do. In fact, screen shots NEVER seem to include the server name, which troubles me for some reason. Do people even know about the splitter? Do people ever resize the window?)

ANYWAY, it's a meter showing how far along you are in the XP to your next level. And, just to be COOL, I made the newly-earned XP glow for a second or two.


* INTEGRATED UNZIPPER

I merged the Arcadia unzipper into WoS, so that most players no longer will need to install WinZip to download and install new worlds.

World Developers will STILL need to install winZIP to use the /publish command which I HIGHLY RECOMMEND USING. Plus the world patching is easiest with winzip as well, IMHO.

Anyway, I tried all the existing worlds and didn't find any problems, so hopefully my unzipper doesn't have any serious flaws in it.


* SPECIAL SURPRISE FOR PREVIOUSLY BANNED PLAYERS

I won't ruin the surprise. But it will be an unpleasant one, I am pleased to announce. It's not too late to get your act together when playing online.


* NEW CONFIG.INI ENTRY - configNoGivingGP

World Dev's can optionally make GP ungivable in their world (I mean player to player GP giving), see evergreen config.ini for details


* NEW COOKIE - #<num.hostTotalPP>

This shows the total PP earned by the scene host for the life of that character. Hopefully this will be used for complimenting hard-working players and not some sort of "I caught you auto-clicking your way to PP" hack detector.


* CAN NO LONGER CHARM PETS

I have mixed feelings about this, since the concept of trying to charm an opponent's pet away from them, has a certain.. charm. But it didn't work really anyway and it led to oddness like charming your own pet in battle.

To be clear, you can still (occasionally) charm MONSTERS... just not monsters who have already been tamed into being someone's PET.


* MULTIPLE MONSTERS CAN DROP THE SAME TROPHY


A89 allows you to have up to 10 monsters drop the same trophy (but all with the same probability).

So in the column where you used to put the single monster ID, you can now use the dotted arguments, as in:

"12.76.23.199"

Meaning this trophy can be dropped by monsters 12, 76, 23, or 199


* NEW PATH POSSIBILITIES FOR SPELL CASTING


In A89:

; C Accumulation of magic around caster, before it 'launches'
; 0 - accumulate over caster
; 1 - accumulate within caster
; 2 - accumulate under caster
; 3 - at level of caster, but 128pixels towards target
; 4 - at level of caster, but 128pixels away from target
; 5 - at level of caster, but halfway between caster and target


* TROPHY 'SELL' MENU NOW USES LOCAL WORD FOR 'GP'

Sorry I missed that before. It will not say what you have in your config.ini file


* LEVEL UP MESSAGES INCLUDE NOTE OF HP/MP GAINS

*** Hesacon is now a level 100 Pundit ***
Your HP rose by 29 points.
Your MP rose by 20 points.


* SERVER VARIABLES (at last)

Note that I am not calling these server cookies any more. I appreciate how everyone thinks this is simple stuff, but it's not However, I think I give you a PRETTY good illusion of simplicity.

Here is how it works from the point of view of a world developer:

1.) New Quest Command: SET_SERVER_VAR used like this:

SET_SERVER_VAR categoryName, variableName, value

This then stores the value, on the current MIX server, in a file just for the current world, in a section of that categoryName, with a variable Name as shown.

If you were to look on the MIX server itself, you would see a file added like this:

directoryMixIsIn\mixVariableCache\Evergreen.ini

And inside that file you would see:

[categoryName]
variableName=value

2.) New Quest Command: GET_SERVER_VAR

You use this one like this:

GET_SERVER_VAR cookieName, categoryName, variableName

(note: this is like the SET command where the cookie name is NOT wrapped in #<> unless you are using some form of cookie indirection.

You need the cookie to 'hold' the value once it is fetched from the server. After it is fetched, you use the cookie itself as normal. But the cookie is NOT the server variable, it is just the last fetched copy of the server variable. You need to use the GET_SERVER_VAR command again if you want to see what the current variable value is.

Now, the MIX server is probably running on a distant PC, so the GET_SERVER_VAR command is not instantaneous. It is a bit like the WAIT command in that the script will jam up at that point, waiting for the value to be fetched. In fact, it will time out after a few seconds and just return a value of "" so that the script is not jammed forever.

3.) Changes are published to all players on the server.

What this means is that if I do a SET_SERVER_VAR on my PC (that is to say, I host a scene who does that as part of its script), not only does it set the variable on the server itself, but it informs all other players on that server that the value in question has changed.

This allows them to keep their own local copy of the variable up to date, since:

4.) Variables are cached on each client.

What this means is that after you do a GET_SERVER_VAR to pick up a variable, its value is cached locally. If you then ask again, it doesn't really ask the server, it just gives you your locally cached copy of the value.

This would normally suck, except the miracle of step 3 is that your cache is updated if someone else (or even yourself, of course) modifies that particular variable.

Barring disaster, I think this keeps everyone roughly synced up with as little packet traffic as possible. Of course, stupid World Developers who call SET_SERVER_VAR constantly will result in laggy crappy gameplay. Then again, stupid developers can already do that. Don't be stupid. Think about it: "This command will result in remote users seeing something change, therefore it sends a packet, therefore I should do it as little as possible."

5.) As cool as this is, it's still no guarantee

For example, if two players simultaneously execute SET_SERVER_VAR, there is no guarantee which one will win the race. And if you are trying to, say, increment a variable, it may not increment the amount you expected.

6.) The Mix Admin can 'opt out'

While the server variables are probably not going to eat up much disk space, and there should not be any security issues (they are limited to the 'sandbox' of the mixVariableCache folder), you may not trust me, and/or you just may not want your server acting as a public disk space (btw, we're talking short text 'values' here, not MP3 files).

If not, there is a new checkbox on MIX called "Allow Server Variables." Just uncheck that and any players on your server will be unable to set variables, and if they ask for a variable's value, they will be told it is blank.

7.) The MIX Admin can set variables which can only be READ (not written) by the players. To do this you will have to manually open mixVariableCache/worldName.ini and edit the file with a text editor.

You can add new sections and variables as you like. Any section whose name starts with "admin" can not be overwritten by players

[adminConfig]
season=spring
quest_of_the_day=23

um, 'section' and 'category' are the same thing, sorry I switched terms in the middle.

Because of the way windows works, you have to restart your MIX server after manually editing an .ini file before it will take effect.

8.) EVENTUALLY, I will probably add an event like:

onEventServerVariableChanged

and that should enable some fairly ambitious multiplayer gamelets. I don't want to do that yet since there are enough other unknowns to be worked out first. You should still be able to do some multiplayer stuff with the above. One thing to think about though is that while server variables can be limited to worlds and sections, they cannot be expressly limited by 'room' or 'scene' (and if you wrote a poker game, you would PROBABLY want to have multiple tables on the server... but maybe not.) You could simulate this by using the host sernum as the (or part of the) section name. BUt then you will accumulate never-deleting cruft in the cache.

9.) What will hackers do?

I guess I won't help out by suggesting snerty things you could do. At the end of the day, the scripting language already allows them to snert a bit, and this doesn't add TOO much variety to that. The MIX log will show who did what, so manual action can be taken.

10.) THings to be done someday

That event notification to wake your script back up when in incoming variable change is seen.

Something to discourage nuisance scripts, if needed.

Someway to let you modify admin sections if you are on the right sernum, from the right IP, or something.

11.) limitations

variable names, category names, and (to some degree) values must NOT use any weird characters. Try to keep things alphanumeric. The following characters will probably screw you up: [ ] = ,

It's really the variable and category names which mainly have to be limited. values can probably get away with including some odder characters.

I will endeavor to not crash if you disobey this, but I will not guarantee your world will work.


* NEW COMPARISON COMMANDS

code:

---

IF>=  @label
IF<=  @label

---

code:

---

 SCENE 100

    ; This scene CALLs the function foo

    N: This is the first thing you see typed
    CALL  200@foo
    N: This is the THIRD thing you see typed

 END

------------

 SCENE 200

 ; This scene contains the function "foo"

 @foo
    N: This is the SECOND thing you see typed
    RETURN
    N: You never see THIS get typed

 END

---

code:

---

   SCENE 100
      CALL 200@foo Hello, There
   END

----

   SCENE 200

   @foo
      N: OK, I say: #<arg0>, #<arg1>
      N: You should have just seen me say "Hello, There"
   END

---

code:

---

  SCENE 100

     CALL 200@whatIsYourName
     N: I believe its name is #<arg0>
  END

----

  SCENE 200

  @whatIsYourName
     RETURN Dan
  END

---

code:

---

; Save a copy of the cookies on the stack
PUSH a
PUSH b
PUSH c

; do something that damages them
SET a "Badness!"
SET b "evil!"
SET c "clueless!"

; restore their original values
POP c
POP b
POP a

---

code:

---

; swap the contents of cookies a and b
PUSH a
PUSH b
POP a     <-- puts into a what was in b
POP b     <-- puts into b what was in a

---

code:

---

@MyFunction
    PUSH temp
    SET temp, #<arg0>
    ADD temp, 3
    DIV temp, #<arg1>
    MUL temp, #<arg2>
    SUB temp, #<arg0>
    SET arg0, #<temp>
    POP temp   ; restore original value of temp
    RETURN #<arg0>

---